Jusqu’à présent lorsque vous êtes connectés en VPN sur l’UFC, vous ne pouvez pas naviguer en même temps sur Internet sans configurer le proxy.
Du coup certains services sont difficilement accessible (Visio/SSH/…).
Nous avons mis en place une solution pour que les usagers du VPN dans le realm @ufc puisse avoir accès à l’extérieur sans pour autant configurer un serveur mandataire.
Il s’agit du serveur NAT qui est pour le moment en phase de tests.
Si vous avez un retour à ce sujet n’hésitez pas à contacter vpn-master at univ-fcomte.fr
Archive for the ‘informations techniques’ Category
VPN et accès Internet
mercredi, décembre 17th, 2014windows + WIFI SSID ufc-vpn + problème MTU
mardi, novembre 25th, 2014Sous windows 7 en étant sur le Wifi (ssid ufc-vpn), il est possible d’avoir un souci de MTU.
C’est Gérard Asensio qui nous remonte un problème d’accès à un serveur de jeton et sa solution :
netsh interface ipv4>show interface
Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
14 30 1500 connected Connexion réseau sans fil
17 5 1500 disconnected Connexion réseau sans fil 2 <-- SSID ufc-vpn
13 5 1500 disconnected Connexion au réseau local
19 30 1300 connected Connexion au réseau local* 4 <---- connexion vpn
Pour que le jeton de licence passe, il faut un mtu de 1300 sur les interfaces physiques utilisables par le VPN ( wifi ou filaire ) :
netsh interface ipv4>set subinterface "Connexion réseau sans fil" mtu=1300 store=persistent
Ok.
netsh interface ipv4>set subinterface "Connexion au réseau local" mtu=1300 store=persistent
Ok.
netsh interface ipv4>show interface
Idx Mét MTU État Nom
--- ---------- ---------- ------------ ---------------------------
1 50 4294967295 connected Loopback Pseudo-Interface 1
14 30 1300 connected Connexion réseau sans fil
17 5 1500 disconnected Connexion réseau sans fil 2 <-- SSID ufc-vpn
13 5 1300 disconnected Connexion au réseau local
19 30 1380 connected Connexion au réseau local* 4 <---- connexion vpn
Remettre un interface en mtu 1500 :
netsh interface ipv4>set subinterface "Connexion réseau sans fil 2" mtu=1500 store=persistent
Ok.
netsh interface ipv4>set subinterface "Connexion au réseau local* 4" mtu=1500 store=persistent
Ok.
Problème VISTA : la connexion ne fonctionne pas, pas de message d’erreur
mardi, octobre 20th, 2009Sous VISTA si le petit patch de la base de registre est mal appliqué (ou la machine n’est pas rebooté), il est possible que la connexion VPN échoue sans aucun message d’erreur.
Néanmoins dans les logs du serveur VPN nous aurons :
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0xd3e37be6 <0xb8baa9ac xfrm=AES_128-HMAC_SHA1 NATD=172.20.10.58:4500 DPD=none}
received Delete SA(0x7e993ed9) payload: deleting IPSEC State #61676
received and ignored informational message
Un log de connexion réussi :
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
STATE_QUICK_R2: IPsec SA established {ESP=>0x1a850fb1 <0x72559a9e xfrm=AES_128-HMAC_SHA1 NATD=172.21.7.183:4500 DPD=none}
GNU Linux Magazine France
mardi, mai 19th, 2009Le premier d’une série de quatre articles consacrés à la mise en oeuvre de notre solution VPN pour l’UFC a été publié dans le numéro 116 de GNU Linux Magazine France (GLMF).
Linux : outils
mardi, avril 28th, 2009Dans la boite à outils que propose Linux nous pouvons trouver :
iwconfig
dhclient
iwconfig permet de voir la configuration d’une interface WIFI …
iwconfig eth1
eth1 IEEE 802.11b ESSID:"ufc-personnels" Nickname:"ipw2100"
...
… ou de la reconfigurer :
iwconfig eth1 essid ufc-vpn
iwconfig eth1
eth1 IEEE 802.11b ESSID:"ufc-vpn" Nickname:"ipw2100"
...
et l’outils dhclient vous permet de récupérer via DHCP une adresse IP :
dhclient
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth1/00:04:23:96:c2:09
Sending on LPF/eth1/00:04:23:96:c2:09
Listening on LPF/eth0/00:06:1b:d8:c4:cb
Sending on LPF/eth0/00:06:1b:d8:c4:cb
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 172.21.7.254
DHCPREQUEST on eth1 to 255.255.255.255 port 67
DHCPACK from 172.21.7.254
bound to 172.21.7.231 -- renewal in 5416 seconds.
problème serveur : les utilisateurs ont un problème de routage asymétrique
mardi, janvier 6th, 2009Si les utilisateurs ont un problème de route asymétrique entre l’envoie d’un paquet et sa réception ce qui entraîne une rupture de connexion de la part du FireWall, il faut commencer par regarder la configuration des interfaces car c’est à cet endroit que nous effectuons un routage.
Pour rappel, le FireWall divise en quatre grandes classes l’ensemble des classe IP de l’UFC (chacune à sa VRF).
Sur le FW, plusieurs de ces classes sont réunis et il faut faire extrêmement attention à ne pas créer sur la machine VPN un routage inter-classe qui entraînera pour le moins un dysfonctionnement pour l’utilisateur (au pire un dysfonctionnement d’une partie du réseau de l’UFC).
Avec le code suivant :
auto eth0.168
iface eth0.168 inet static
address 172.20.16.220
netmask 255.255.255.0
network 172.20.16.0
broadcast 172.20.16.255
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
up ip rule add fwmark 18 table admin.pres
down ip rule del fwmark 18
down ip route del table admin.pres
Nous avons deux règles très importantes :
la première :
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
qui implique une route par défaut pour tous les utilisateurs VPN du tag 18 (admin.pres).
la seconde :
up ip rule add fwmark 18 table admin.pres
car c’est par elle que l’on affecte au client le tag 18.
Si le code dans le fichier /etc/network/interfaces ressemble à
up ip route add default via 172.20.16.254 dev eth0.168 table admin.pres
ip up rule add fwmark 18 table admin.pres
Tous les clients de ce réseaux ne seront pas affecté au tag 18 et donc tout leur trafic transitera par l’interface de routage par défaut de la machine qui est sans aucun doute dans une VRF distincte et donc entraînera un dysfonctionnement des connexion de ces clients vers l’extérieur de leur réseau de connexion.
Problème serveur : patch freeradius pour prise en compte du retour des proxies
vendredi, juin 13th, 2008Lors de l’utilisation d’un proxy par freeradius celui-ci, et quelle que soit la réponse du proxy, retourne toujours « OK » dans l’authentification. Ce problème a été solutionné par Jean-Michel Caricand qui a proposé un patch pour freeradius :
*** freeradius-1.1.3/src/main/radiusd.c Tue May 16 18:26:07 2006 --- /root/FREERADIUS/freeradius-1.1.3/src/main/radiusd.c Sat Jan 26 11:04:06 2008 *************** *** 1585,1590 **** --- 1585,1595 ---- int rcode; rcode = proxy_receive(request); switch (rcode) { + case RLM_MODULE_REJECT: + DEBUG2("Request %d rejected in proxy_receive.", request->number); + request_reject(request); + goto finished_request; + break; default: /* Don't Do Anything */ break; case RLM_MODULE_FAIL:
Problème serveur : récupération sur radius de l’IP de l’utilisateur
vendredi, juin 13th, 2008L’architecture du service VPN (station de travail -> VPN1/2/3/… -> RADIUS -> LDAP/RADIUS/… ) pose le problème suivant : le client RADIUS est le serveur VPN. De ce fait, RADIUS reçoit par défaut l’adresse IP du NAS (machine VPN) alors qu’il serait intéressant d’obtenir également l’adresse IP du client réel, c’est-à-dire, la station de travail.
Sur le serveur VPN, le démon XL2TP lance le service PPP qui permet à l’utilisateur de transmettre des informations, notamment login/mot de passe. Le service PPP, inclut dans ses sources une partie RADIUSCLIENT (les binaires radiusclient1 que l’on charge sur le serveur VPN sont donc inutiles) qui adresse au serveur RADIUS via le protocole RADIUS les informations reçues par le serveur VPN.
Or nous avons besoin pour certaines applications du VPN de connaître (reconnaître) l’adresse IP de l’utilisateur (client final à ne pas confondre avec le client du serveur RADIUS) pour l’autoriser ou non à établir une connexion.
Or les arguments transmis par le VPN au serveur RADIUS sont les suivants :
Service-Type = Framed-User Framed-Protocol = PPP User-Name = "utilisateur@realm" User-Password = "mot_de_passe" NAS-IP-Address = IP_serveur_VPN NAS-Port = 1
Le serveur RADIUS n’a donc pas d’information sur l’IP de l’utilisateur.
Jean-Michel Caricand a créé et appliqué un patch de quelques lignes pour transmettre cette information.
En effet, dans le fonctionnement de XL2TP (L2TP) sur le serveur VPN, nous pouvons transmettre des attributs statiques à l’aide de l’argument « ipparam ». Si cet argument est transmis, l’attribut qui suit est également transmis. On retrouve cela dans les fichiers de configuration avec le plus souvent une chaîne de caractères (par exemple pour éviter les récursions sur L2TP).
Notre idée est simple : introduire après l’argument ipparam l’adresse IP de l’utilisateur.
cela nous donne le patch :
--- xl2tpd-1.1.12.orig/control.c 2007-10-20 06:22:55.000000000 +0200 +++ xl2tpd-1.1.12/control.c 2008-06-12 15:01:16.000000000 +0200 @@ -954,6 +954,14 @@ int control_finish (struct tunnel *t, st } if (c->lns->debug) po = add_opt (po, "debug"); + + po = add_opt (po, "ipparam"); + po = add_opt (po, "%s", IPADDY (t->peer.sin_addr)); + + l2tp_log (LOG_DEBUG, + "Use ipparam option with %s value\n", + IPADDY (t->peer.sin_addr)); + if (c->lns->pppoptfile[0]) { po = add_opt (po, "file");
maintenant, nous avons bien une information supplémentaire très facile à traiter :
Service-Type = Framed-User Framed-Protocol = PPP User-Name = "utilisateur@realm" User-Password = "motdepasse" Calling-Station-Id = "IP_utilisateur" NAS-IP-Address = IP_serveur_VPN NAS-Port = 1
RADIUS : NAS-IP-Address et fichier /etc/hosts
jeudi, mai 29th, 2008Si votre fichier /etc/hosts
contient
10.0.0.1 vpn3.univ-fcomte.fr vpn3
et que l’IP véritable de vpn3 soit 194.57.89.97
et que RADIUS est bien configuré pour 194.57.89.97
La requête RADIUS venant de vpn » sera bien accepter, mais il y aura un problème d’authentification si on vérifie le NAS-IP-address
paquet recu par le serveur RADIUS
rad_recv: Access-Request packet from host 194.57.89.105:32779, id=171, length=76
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "test@ufc"
User-Password = "monpassword"
NAS-IP-Address = 10.0.0.1
NAS-Port = 0
au lieu de :
rad_recv: Access-Request packet from host 194.57.89.105:32779, id=171, length=76
Service-Type = Framed-User
Framed-Protocol = PPP
User-Name = "test@ufc"
User-Password = "monpassword"
NAS-IP-Address = 194.57.89.105
NAS-Port = 0
installation d’un serveur VPN : ajout d’un REALM
mercredi, mai 21st, 2008Ajout d’un REALM « le-realm » sur un réseau « ttt.ttt.ttt.nnn 255.255.255.ZZZ », vlan XXX
creation du vlan sur le commutateur CISCO
conf t
vlan XXX
name blabla
exit
int vlanXXX
desc blabla
ip vrf forwarding FW_YYYYY
ip address ttt.ttt.ttt.ttt 255.255.255.ZZZ
no shutdown
exit
interface GigabitEthernet3/29
switchport trunk allowed vlan add XXX
interface GigabitEthernet3/38
switchport trunk allowed vlan add XXX
sur le serveur VPN
emacs /etc/network/interfaces
auto eth0.XXX
iface eth0.XXX inet static
address ttt.ttt.ttt.ttu
netmask 255.255.255.ZZZ
network ttt.ttt.ttt.0
broadcast ttt.ttt.ttt.ttv
up ip route add default via ttt.ttt.ttt.ttt dev eth0.XXX table le.realm
up ip rule add fwmark MMM table le-realm
down ip rule del fwmark MMM
down ip route del table le.realm
emacs /etc/iproute2/rt_tables
10 femto.ext
11 lifc.lab
12 lifc.edu
13 ufc.generic
MMM le.realm
modification de la base de données realmacl
add realm
add network
=> choix du nas
=> tranche ip
=> marque iptable
sur le serveur RADIUS (exemple avec le realm ufc-pub sur 194.57.81.0/24 coupé en trois parties) :
/etc/raddb/radiusd.conf
realm ufc-pub {
format = suffix
delimiter = "@"
ignore_default = no
ignore_null = no
}
ippool ufc_pub_pool {
name = ufc_pub_pool
range-start = 194.57.81.1
range-stop = 194.57.81.10
netmask = 255.255.255.0
cache-size = 800
session-db = ${raddbdir}/db-ufc_pub_pool.ippool
ip-index = ${raddbdir}/db-ufc_pub_pool.ipindex
override = no
maximum-timeout = 0
}
ippool ufc_pub_pool1 {
name = ufc_pub_pool1
range-start = 194.57.81.11
range-stop = 194.57.81.251
netmask = 255.255.255.0
cache-size = 800
session-db = ${raddbdir}/db-ufc_pub_pool1.ippool
ip-index = ${raddbdir}/db-ufc_pub_pool1.ipindex
override = no
maximum-timeout = 0
}
...
}
authorize {
ufc-pub
}
accounting {
ufc_pub_pool
ufc_pub_pool1
}
post-auth {
ufc_pub_pool
ufc_pub_pool1
}
créer et attribuer à radiusd.radiusd les fichier ${raddbdir}/db-ufc_pub_pool.ippool
et ${raddbdir}/db-ufc_pub_pool.ipindex
.
dans le fichier /etc/raddb/users
on attribue les méthodes d’authentification, d’autorisation et les pool pour le DHCP :
DEFAULT Realm == "ufc-pub", NAS-IP-Address == 194.57.91.251, Pool-Name := "ufc_pub_pool", Auth-Type = "LDAP_UFC", Autz-Type = "LDAP_UFC"
Fall-Through = No
DEFAULT Realm == "ufc-pub", NAS-IP-Address == 194.57.91.250, Pool-Name := "ufc_pub_pool1", Auth-Type = "LDAP_UFC", Autz-Type = "LDAP_UFC"
Fall-Through = No
DEFAULT Realm == "ufc-pub", NAS-IP-Address == 194.57.89.65, Pool-Name := "ufc_pub_pool2", Auth-Type = "LDAP_UFC", Autz-Type = "LDAP_UFC"
Fall-Through = No
Ne pas oublier le fichier /etc/raddb/clients.conf
:
client 194.57.91.250 {
secret = blabla
shortname = test-vpn
nastype = other
}
client 194.57.91.251 {
secret = blabla
shortname = vpn1
nastype = other
}
client 194.57.89.65 {
secret = blabla
shortname = vpn2
nastype = other
}
comme nous avons un identificateur de realm il faut aussi (même si ce realm est géré en local sur ce radius) configurer le fichier /etc/raddb/proxy.conf
:
realm ufc-pub {
type = radius
authhost = LOCAL
accthost = LOCAL
# strip
}