Le serveur RADIUS assure le AAA (Authorization, Authentication et Accounting). Pour ce faire, le service RADIUS recoit des informations du serveur IPSEC à travers la couche L2TP/PPP. C’est effectivement par ce biais que le client peut émettre une demande d’authentification supplémentaire au seul certificat.
sur le serveur IPSEC, nous avons dans /etc/options.l2tpd.lns qui est appelé par xl2tpd (pppoptfile = /etc/ppp/options.l2tpd.lns) les instructions suivantes :
plugin radius.so
plugin radattr.so
qui suffisent à utiliser un serveur RADIUS depuis L2TP.
Le fichier /etc/radiusclient.conf donne :
authserver "serveur radius"
acctserver "serveur radius"
Le reste des options étant des définitions standards, tels les dictionnaires
dictionary /etc/radiusclient/dictionary
dans lequel on retrouve :
INCLUDE /etc/radiusclient/dictionary.rfc2868
INCLUDE /etc/radiusclient/dictionary.microsoft
INCLUDE /etc/radiusclient/dict.perso
Le dictionnaire de la RFC 2868 est récupéré sur une machine sur laquelle se trouve un serveur RADIUS, mais il faut modifier certains type : “integer has_tag” devient “integer” et “string has_tag” devient “string”. Sans ces modifications, une erreur apparait dans les logs au lancement de l2tp. Il faut aussi enlever de ces fichiers dictionnaire les lignes de début et de fin de dictionnaire comme BEGIN-VENDOR et END-VENDOR .
Le dictionnaire de la RFC 2668 nous permet de manipuler les VLANs (Tunnel-Type 13 et Tunnel-Medium-Type IEEE-802 et la valeur du VLAN par le champ Tunnel-Private-Group-Id). Sans ces champs, il est impossible de définir les VLANs.
Cette approche à toute son utilité si nous voulions récupérer un numéro de VLAN depuis le serveur LDAP de l’UFC ou dans un fichier local (ou base de données). Or, notre approche du problème est légerement différente puisque nous n’utilisons pas de prédéfinition de VLAN pour un utilisateur, mais plutôt une définition de REALM permettant pour un même utilisateur d’accéder à différents VLANs.
Le serveur IPSEC est prêt à se servir du serveur RADIUS et les informations que nous récupérons sont :
nom de l’utilisateur, le realm, une date d’expiration, le réseau, la marque iptables, les indications de validité du compte et du realm.
Si le RADIUS du projet VPN est chainé à un RADIUS local de laboratoire, celui-ci peut renvoyer une valeur pour l’adresse IP du client, le RADIUS de laboratoire effectuant l’aspect DHCP. La valeur de l’IP ainsi retournée doit correspondre au réseau.
La marque iptables possède toute une histoire. Sur le serveur IPSEC, nous avons deux cartes réseaux. La première définie le réseau de connexion du serveur au monde extérieur et un route -n nous donne :
0.0.0.0 194.57.91.254 0.0.0.0 UG 0 0 0 eth1
La seconde est configuré en mode trunk et possède tous les VLANs rattachés au VPN. De fait, cette interface possède des sous-interfaces sur des VLANs (ex :
eth0.410 Lien encap:Ethernet HWaddr 00:B0:D0:68:72:BD
inet adr:172.20.252.253 Bcast:172.20.252.255 Masque:255.255.255.0)
Mais il s’est posé un problème important ; dès la fin de la première connexion, les connexions suivantes n’étaient plus routées correctement. Pour corriger ce problème, nous avons défini un routage sélectif par marquage des paquets suivant leur origine.
auto eth0.410
iface eth0.410 inet static
address 172.20.252.253
netmask 255.255.255.0
network 172.20.252.0
broadcast 172.20.252.255
up ip route add default via 172.20.254 dev eth0.410 table ufc.generic
up ip rule add fwmark 13 table ufc.generic
down ip rule del fwmark 13
down ip route del table ufc.generic
Et on marque les paquets à l’initialisation de la session PPP faite par le client suivant le REALM demandé et accepté.
Avec l’exécutable perl /etc/ppp/ip-up.d/vpn-connect, nous créons un fichier /var/run/radattr.pppXX qui contient les informations retournées par RADIUS (ex :
Framed-IP-Address 172.20.128.37
Framed-IP-Netmask 255.255.255.0
Ufc-Iptables-Mark 12)
Lors de la deconnexion, c’est le fichier /etc/ppp/ip-down.d/vpn-disconnect qui est exécuté.
Nous avons ainsi les logs de l’exécution des scripts :
Apr 10 16:37:35 test-vpn vpn-connect: /sbin/iptables -t mangle -A PREROUTING -s 172.20.128.37 -i ppp0 -j MARK --set-mark 12
Apr 10 16:37:40 test-vpn vpn-disconnect: iptables -D PREROUTING -s 172.20.128.37 -i ppp0 -j MARK --set-mark 0xc
Sur le serveur, il ne faut pas oublier de définir les valeurs données dans le fichier /etc/network/interfaces ; cela s’effectue en ajoutant les valeurs dans /etc/iproute2/rt_tables :
10 femto.ext
11 lifc.lab
12 lifc.edu
13 ufc.generic
Ainsi le traffic PPP du client est marqué correctement et est routé en utilisant le routeur du VLANs sur lequel il est raccordé.
