{"id":26,"date":"2008-04-14T17:27:59","date_gmt":"2008-04-14T15:27:59","guid":{"rendered":"https:\/\/vpn.univ-fcomte.fr\/?p=26"},"modified":"2008-04-21T17:40:22","modified_gmt":"2008-04-21T15:40:22","slug":"configuration-serveurs-radius-et-iptables","status":"publish","type":"post","link":"https:\/\/vpn.univ-fcomte.fr\/?p=26","title":{"rendered":"Configuration serveurs : RADIUS et iptables"},"content":{"rendered":"

Le serveur RADIUS assure le AAA (Authorization<\/em>, Authentication<\/em> et Accounting<\/em>). Pour ce faire, le service RADIUS recoit des informations du serveur IPSEC \u00e0 travers la couche L2TP\/PPP. C’est effectivement par ce biais que le client peut \u00e9mettre une demande d’authentification suppl\u00e9mentaire au seul certificat.<\/p>\n

sur le serveur IPSEC, nous avons dans \/etc\/options.l2tpd.lns<\/small><\/code> qui est appel\u00e9 par xl2tpd (pppoptfile = \/etc\/ppp\/options.l2tpd.lns)<\/small><\/code> les instructions suivantes :
\nplugin radius.so
\nplugin radattr.so<\/small><\/code>
\nqui suffisent \u00e0 utiliser un serveur RADIUS depuis L2TP.
\nLe fichier \/etc\/radiusclient.conf<\/small><\/code> donne :
\nauthserver \t\"serveur radius\"
\nacctserver \t\"serveur radius\"
\n<\/small><\/code>
\nLe reste des options \u00e9tant des d\u00e9finitions standards, tels les dictionnaires
\ndictionary \t\/etc\/radiusclient\/dictionary<\/small><\/code>
\ndans lequel on retrouve :
\nINCLUDE \/etc\/radiusclient\/dictionary.rfc2868
\nINCLUDE \/etc\/radiusclient\/dictionary.microsoft
\nINCLUDE \/etc\/radiusclient\/dict.perso<\/small><\/code>
\nLe dictionnaire de la RFC 2868 est r\u00e9cup\u00e9r\u00e9 sur une machine sur laquelle se trouve un serveur RADIUS, mais il faut modifier certains type : \u00ab\u00a0integer has_tag\u00a0\u00bb devient \u00ab\u00a0integer\u00a0\u00bb et \u00ab\u00a0string has_tag\u00a0\u00bb devient \u00ab\u00a0string\u00a0\u00bb. 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\u00e9but et de fin de dictionnaire comme BEGIN-VENDOR <\/small><\/code> et END-VENDOR <\/small><\/code>.
\nLe dictionnaire de la RFC 2668 nous permet de manipuler les VLANs (Tunnel-Type 13<\/small><\/code> et Tunnel-Medium-Type IEEE-802<\/small><\/code> et la valeur du VLAN par le champ Tunnel-Private-Group-Id<\/small><\/code>). Sans ces champs, il est impossible de d\u00e9finir les VLANs.<\/p>\n

Cette approche \u00e0 toute son utilit\u00e9 si nous voulions r\u00e9cup\u00e9rer un num\u00e9ro de VLAN depuis le serveur LDAP de l’UFC ou dans un fichier local (ou base de donn\u00e9es). Or, notre approche du probl\u00e8me est l\u00e9gerement diff\u00e9rente puisque nous n’utilisons pas de pr\u00e9d\u00e9finition de VLAN pour un utilisateur, mais plut\u00f4t une d\u00e9finition de REALM permettant pour un m\u00eame utilisateur d’acc\u00e9der \u00e0 diff\u00e9rents VLANs.<\/p>\n

Le serveur IPSEC est pr\u00eat \u00e0 se servir du serveur RADIUS et les informations que nous r\u00e9cup\u00e9rons sont :
\nnom de l’utilisateur, le realm, une date d’expiration, le r\u00e9seau, la marque iptables, les indications de validit\u00e9 du compte et du realm.
\nSi le RADIUS du projet VPN est chain\u00e9 \u00e0 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\u00e9e doit correspondre au r\u00e9seau.
\nLa marque iptables poss\u00e8de toute une histoire. Sur le serveur IPSEC, nous avons deux cartes r\u00e9seaux. La premi\u00e8re d\u00e9finie le r\u00e9seau de connexion du serveur au monde ext\u00e9rieur et un route -n<\/small><\/code> nous donne :
\n0.0.0.0 194.57.91.254 0.0.0.0 UG 0 0 0 eth1<\/small><\/code>
\nLa seconde est configur\u00e9 en mode trunk<\/em> et poss\u00e8de tous les VLANs rattach\u00e9s au VPN. De fait, cette interface poss\u00e8de des sous-interfaces sur des VLANs (ex :
\neth0.410 Lien encap:Ethernet HWaddr 00:B0:D0:68:72:BD
\ninet adr:172.20.252.253 Bcast:172.20.252.255 Masque:255.255.255.0<\/small><\/code>)
\nMais il s’est pos\u00e9 un probl\u00e8me important ; d\u00e8s la fin de la premi\u00e8re connexion, les connexions suivantes n’\u00e9taient plus rout\u00e9es correctement. Pour corriger ce probl\u00e8me, nous avons d\u00e9fini un routage s\u00e9lectif par marquage des paquets suivant leur origine.
\nauto eth0.410
\niface eth0.410 inet static
\naddress 172.20.252.253
\nnetmask 255.255.255.0
\nnetwork 172.20.252.0
\nbroadcast 172.20.252.255
\nup ip route add default via 172.20.254 dev eth0.410 table ufc.generic
\nup ip rule add fwmark 13 table ufc.generic
\ndown ip rule del fwmark 13
\ndown ip route del table ufc.generic<\/small><\/code>
\nEt on marque les paquets \u00e0 l’initialisation de la session PPP faite par le client suivant le REALM demand\u00e9 et accept\u00e9.
\nAvec l’ex\u00e9cutable perl \/etc\/ppp\/ip-up.d\/vpn-connect<\/small><\/code>, nous cr\u00e9ons un fichier \/var\/run\/radattr.pppXX qui contient les informations retourn\u00e9es par RADIUS (ex :
\nFramed-IP-Address 172.20.128.37
\nFramed-IP-Netmask 255.255.255.0
\nUfc-Iptables-Mark 12<\/small><\/code>)
\nLors de la deconnexion, c’est le fichier \/etc\/ppp\/ip-down.d\/vpn-disconnect<\/small><\/code> qui est ex\u00e9cut\u00e9.
\nNous avons ainsi les logs de l’ex\u00e9cution des scripts :
\nApr 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<\/small><\/code>
\nApr 10 16:37:40 test-vpn vpn-disconnect: iptables -D PREROUTING -s 172.20.128.37 -i ppp0 -j MARK --set-mark 0xc<\/small><\/code>
\nSur le serveur, il ne faut pas oublier de d\u00e9finir les valeurs donn\u00e9es dans le fichier \/etc\/network\/interfaces<\/small><\/code> ; cela s’effectue en ajoutant les valeurs dans \/etc\/iproute2\/rt_tables<\/small><\/code> :
\n10 femto.ext
\n11 lifc.lab
\n12 lifc.edu
\n13 ufc.generic<\/small><\/code><\/p>\n

Ainsi le traffic PPP du client est marqu\u00e9 correctement et est rout\u00e9 en utilisant le routeur du VLANs sur lequel il est raccord\u00e9.<\/p>\n","protected":false},"excerpt":{"rendered":"

Le serveur RADIUS assure le AAA (Authorization, Authentication et Accounting). Pour ce faire, le service RADIUS recoit des informations du serveur IPSEC \u00e0 travers la couche L2TP\/PPP. C’est effectivement par ce biais que le client peut \u00e9mettre une demande d’authentification suppl\u00e9mentaire au seul certificat. sur le serveur IPSEC, nous avons dans \/etc\/options.l2tpd.lns qui est appel\u00e9 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[58,57,54,55,28,56,14],"class_list":["post-26","post","type-post","status-publish","format-standard","hentry","category-informations-techniques","tag-ip-downd","tag-ip-upd","tag-iptables","tag-mangle","tag-radius","tag-rt_tables","tag-serveur"],"_links":{"self":[{"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=\/wp\/v2\/posts\/26","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=26"}],"version-history":[{"count":0,"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=\/wp\/v2\/posts\/26\/revisions"}],"wp:attachment":[{"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=26"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=26"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vpn.univ-fcomte.fr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=26"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}