VPN sous Linux à travers la solution UCOPIA (accès WIFI)

juillet 9th, 2008

Votre portable est sous linux et vous voulez effectuer une connexion VPN sur un serveur de l’UFC.

Or votre accès réseau passe par du WiIFi managé par une solution de contrôle de type UCOPIA.

Le principe d’UCOPIA est simple :vous vous connectez au SSID WiFi que l’on vous a fourni puis vous ouvrez votre navigateur et un portail captif se présente à vous à la place de la page que vous vouliez voir afficher. Vous entrez alors votre login/password et vous conservez une session active tant que la fenêtre de connexion UCOPIA reste ouverte. Dès la fermeture de la page UCOPIA vous perdez immédiatement le lien réseau.

Vous avez donc modifié votre /etc/ipsec.conf (avec la gateway que vous voyez [route -n]) :
leftnexthop=192.168.138.10

Premier problème : le fichier hosts
Malheureusement dès que vous lancez le VPN, vous perdez le lien réseau. Cela vient du fait qu’une fois le lien VPN monté votre DNS devient celui de l’UFC.
Or vous avez besoin (votre navigateur) de connaître l’ip de https://controller.ucopia.mobile/secure/index.php?blablabla
Pour corriger ce problème il suffit de déclarer le host controller.ucopia.mobile dans le fichier /etc/hosts

Deuxième problème : le proxy
Si vous activez le proxy par « Adresse de configuration automatique du proxy » (proxy.pac) vous perdez le lien presque aussitôt. Pour éviter cela il suffit de cliquer sur « Configuration manuelle du proxy » (mettre proxy-www.univ-fcomte.fr 3128) et surtout d’ajouter dans « Pas de proxy pour : » le nom controller.ucopia.mobile.

Dès que cela est fait, vous n’aurez plus de problème pour faire fonctionner votre connexion VPN.

liste des serveurs VPN et des REALMS

juillet 4th, 2008

VPN1 : Besançon 194.57.91.250, realm @ufc @lifc-lab @lifc-edu, @femto, @cri, @admin-bu et @admin-presidence.
VPN2 : Montbéliard 194.57.89.97, realm @ufc
VPN3 : Belfort 194.57.89.105, realm @ufc et @iutbm (à venir @lifc-lab)

Problème serveur : patch freeradius pour prise en compte du retour des proxies

juin 13th, 2008

Lors 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

juin 13th, 2008

L’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

mai 29th, 2008

Si 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

Utilisation du FTP depuis un accès VPN

mai 27th, 2008

Lors d’un accès VPN, il vous est attribué une adresse IP privée. Ce type d’adresse vous interdit un accès direct à Internet. Vous devez utiliser ce qu’on appelle un serveur mandataire (serveur proxy) pour pouvoir « atteindre » un service réseau situé en dehors du réseau universitaire. L’utilisation du FTP pour récupérer ou déposer des ressources nécessite donc un paramètrage de votre client FTP. Les informations utiles sont disponibles à cette adresse : Les proxys de l’Université de Franche-Comté

Problème Linux : route vers le serveur VPN absente

mai 23rd, 2008

Lors de l’établissement L2TP/PPP entre le client et le serveur, L2TP change la route par défaut de la machine pour indiquer PPP à la place. ex :
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Or en effectuant cette opération le système doit aussi ajouter une route pour garantir le lien vers le serveur VPN ex :
194.57.91.250 172.21.7.254 255.255.255.255 UGH 0 0 0 eth1
dans cet exemple le serveur VPN est 194.57.91.250 et la passerelle par défaut 172.21.7.254 sur l’interface eth1.

Si cette route est absente le lien entre le client et le serveur est immédiatement mis en défaut et la connexion se coupe au bout de quelques minutes => aucun échange avec quiconque n’est possible sans cette route.

Solution : relancer ipsec. Cette opération doit être également effectuée après chaque changement (up/down) d’interface.

Gestion des proxies sous Firefox

mai 23rd, 2008

Lorsque vous êtes connecté à un réseau à travers l’un des serveurs VPN universitaires, vous allez certainement vous retrouver dans un réseau de classe privée. Vos accès Internet devront donc impérativement passer par les serveurs mandataires (Proxy) de l’UFC. Sous IE, il est possible de gérer un serveur proxy par connexion du fait de l’intégration avancée du navigateur avec le système. Pour plus d’informations, consultez l’article Problème Windows : IE7 et proxy.

Sous Firefox, la bascule entre les accès directs à Internet et l’utilisation obligatoire d’un proxy peut devenir irritante. L’installation du plugin FoxyProxy peut vous rendre bien des services.

Ce plugin vous permettra de sélectionner très facilement l’utilisation de tel ou tel serveur proxy ou bien sûr l’accès direct sans aucun mandataire.

Connexion VPN depuis Mac OS X Leopard

mai 22nd, 2008

Nous vous informons que le système Mac OS X Leopard est compatible avec l’architecture VPN universitaire.

Actuellement 3 machines fonctionnant avec ce système d’exploitation sont en cours de tests.

La documentation décrivant la création d’une connexion VPN sur Leopard est disponible ici.

installation d’un serveur VPN : ajout d’un REALM

mai 21st, 2008

Ajout 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
}