Cette page décrit en détail l'architecture de collecte xDSL mutualisée au sein de Grenode. Il s'agit de fournir à ses membres différents opérateurs de collecte (pour l'instant FDN et Liazo).
Prérequis :
- L2TP: Layer 2 Transport Protocol
- RADIUS: Authentication, Authorization and Accounting
Fonctionnement de la collecte
Principe général
La mutualisation des collectes xDSL se passe sur les machines ?ajut et ?attrape. D'un point de vue réseau, ces deux machines se retrouvent entre les [LNS] des membres de Grenode et les [LAC] des fournisseurs de collecte. Elles font tourner un proxy radius (freeradius) et un daemon de routage dynamique (bird).
[LNS]: L2TP Network Server : équipement terminant des tunnels PPP.
[LAC]: L2TP Access Concentrator : équipement relayant des tunnels PPP.
Grenode annonce via radius l'adresse des LNS des membres devant terminer les tunnels L2TP. Grenode ne dispose donc pas de LAC. En contrepartie, les LAC des fournisseurs de collecte doivent connaître la route pour atteindre chaque LNS des membres de Grenode et inversement. Cela est fait via du routage dynamique entre ajut/attrape, les LAC et les LNS des membres de Grenode.
Grenode
LAC01 LNS01
LAC02 ---+--- ajut ------+--- LNS02
fournisseur | | membre
RAD01 ---+--- attrape ---+--- RAD01
RAD02 RAD02
Plus tard, il est possible que nous ayons à installer des LAC sur ajut et attrape. Pour l'instant ce n'est pas le cas.
Schéma réseau simplifié
Le schéma réseau simplifié pour un membre est le suivant. Chaque ligne horizontale représente un réseau de niveau 2, et une croix indique que la ou les machines ont une interface dans ce réseau.
LACs ATTRAPE LNSs
machines FOURNISSEUR AJUT MEMBRE
Collecte Fourniseur ----X----------X--------------
Collecte Membre ---------------X---------X----
Réseau Membre -------------------------X----
En réalité, cela peut être plus compliqué, par exemple, la collecte via Liazo dispose de trois vlan : un pour les échanges RADIUS, un pour les tunnels dit best effort, un pour les tunnels dit premium (voix par exemple).
Autre exemple, le membre peut mettre son LNS où il veut (tant qu'il est joignable) via le réseau de collecte du membre.
Processus lors du login d'un abonné ADSL
Lorsqu'un abonné xDSL d'un des membres de Grenode se connecte, le processus est le suivant :
- l'abonné initie une session PPP via les équipements de l'opérateur de collecte
- le LAC de l'opérateur de collecte interroge son radius qui y son tour intéroge le serveur radius de Grenode pour déterminer quelles sont les informations de terminaison du tunnel (nottament l'adresse du LNS du membre et le mot de passe à utiliser)
- la requête est transmise au radius du membre concerné puis retournée jusqu'au LAC
- Le LAC propage le tunnel L2TP vers le LNS spécifié.
- le LNS reçoit la demande d'établissement du tunnel L2TP et authentifie l'abonné via son radius.
- La session PPP de l'abonné est montée.
En schéma ça donne :
--- ABONNÉ --- --- FOURNISSEUR --- --- GRENODE --- --- MEMBRE ---
MODEM PROXY PROXY
ROUTEUR LAC RADIUS RADIUS RADIUS LNS
· (1) · · · · ·
o------------->| · · · ·
· | (2) · · · ·
· o---------->| · · ·
· · o------------->| (3) · ·
· · · o------------>| ·
· · · · | ·
· · · |<------------o ·
· · |<-------------o · ·
· |<----------o · ·
· | · ·
· | (4) · ·
· o------------------------------------------------->|
· · · |
· · |<--------o
· · | (5) ·
· · o-------->|
· · |
· |<-------------------------------------------------|
|<-------------o ·
| · ·
| · (6) ·
o--------------o------------------------------------------------->|
|<-------------o--------------------------------------------------|
Proxy Radius
La section précédente met en évidence plusieurs proxy Radius, dont le comportement est basé sur le login de l'abonné. Par exemple pour FDN, le login a pour forme générale "toto!rzn%gnd@fdn.nerim", qu'il faut lire de droite à gauche : il s'agit d'une collecte Nerim, qui transmet à FDN, qui transmet à Grenode (gnd), qui transmet à Rézine (rzn).
- le serveur Radius de FDN se comporte en proxy seulement pour les login du type "%gnd@fdn.nerim", et transmet les demandes au serveur de Grenode
- le serveur Radius de Grenode se comporte uniquement en proxy, en se basant sur la deuxième partie du login (pour un login du type "toto!rzn%gnd@fdn.nerim", matche sur "rzn", trigramme qui correspond à Rézine)
Royaumes actuellement utilisés pour la collete FDN :
- Rézine : user!rzn%gnd@fdn.nerim
- Illyse : user!ils%gnd@fdn.nerim
- Ilico : user!ilc%gnd@fdn.nerim
Royaumes actuellement utilisés pour collecte Ielo-Liazo :
- Rézine : user@rzn.gnd.dslnet.fr
- Illyse : user@ils.gnd.dslnet.fr
- Ilico : user@ilc.gnd.dslnet.fr
Annonce des LNS des membres aux LAC
Il est nécessaire que les LAC des fournisseurs sachent comment joindre les LNS des membres à travers l'infrastructure de collecte. Pour cela, BGP est utilisé : ajut et attrape établissent des sessions BGP avec le membre d'un côté, et avec les fournisseurs de collecte de l'autre. Ainsi, le membre peut annoncer ses propres adresses IP de LNS au fournisseur de collecte via Grenode.
Documentation chez d'autres membres de la Fédération FDN
- tetaneutral : http://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/ADSL#Collecte-L2TP
- Sames Wireless : http://www.sameswireless.fr/samesimg/lns_sames.png
- PClight : https://www.ffdn.org/wiki/doku.php?id=documentation:adslmpd5
Redondance de la collecte
Le principe de la redondance est simple :
- utilisation de plusieurs machines pour répliquer les services (proxy radius, routage)
- utilisation de plusieurs chemins réseaux pour répliquer la connectivité
BGP est utilisé pour faire coller tout ça ensemble.
Redondance de l'infrastructure de Grenode
Ajut et attrape se trouvent dans des datacenters différents, à Vénissieux et Grenoble respectivement. Chacune est reliée à une porte de collecte Liazo distincte.
Ces deux machines participent toutes les deux aux VLAN de livraison des membres, ceux-ci étant propagés entre Vénissieux et Grenoble.
Ainsi, on a une double redondance gérée avec BGP :
############## ############
# Vénissieux # # Grenoble #
############## ############
Fournisseur Fournisseur
=========== ===========
| |
| |
| |
|BGP BGP|
| |
| |
| |
==== =======
ajut attrape
==== =======
|\_ _/|
| `\_ BGP BGP _/` |
| `\_ _/` |
| `\_ _/` |
| _X_ |
| _/ \_ |
|BGP _/` `\_ BGP|
| _/` `\_ |
|/` `\|
==== = Membre = ====
LNS1 LNS2
==== ====
|\_ _/|
| ` ` |
... ...
Redondance des LNS du membre
Le membre peut mettre en place plusieurs LNS. L'interconnexion étant réalisée grâce à BGP, il suffit d'établir de nouvelles sessions BGP avec ?ajut et ?attrape.
Si le membre utilise une configuration en cluster anycast, la configuration Radius ne change pas : une seule IP LNS est renvoyée par le FAI via Radius.
En revanche, si le membre utilise des LNS avec des IP différentes, il est possible de renvoyer plusieurs LNS dans les routes radius :
rzn.gnd.dslnet.fr Auth-Type = Accept
Service-Type = Outbound-User,
Tunnel-Type:1 = 3,
Tunnel-Medium-Type:1 = 1,
Tunnel-Server-Endpoint:1 = 91.216.110.XX,
Tunnel-Assignment-ID:1 = 91.216.110.XX,
Tunnel-Preference:1 = 10,
Tunnel-Client-Auth-Id:1 = LAC,
Tunnel-Server-Auth-Id:1 = "col1-membre.grenode.net",
Tunnel-Type:2 = 3,
Tunnel-Medium-Type:2 = 1,
Tunnel-Server-Endpoint:2 = 91.216.110.YY,
Tunnel-Assignment-ID:2 = 91.216.110.YY,
Tunnel-Preference:2 = 10,
Tunnel-Client-Auth-Id:2 = LAC,
Tunnel-Server-Auth-Id:2 = "col2-membre.grenode.net",
Tunnel-Password = "secret",
Fall-Through = No
Les IP 91.216.110.XX/32 et 91.216.110.YY/32 devront être annoncés en BGP par le membre.
Ajout d'un membre de Grenode
Cette partie suppose que le membre utilise Debian, mais devrait être applicable à d'autres systèmes (freeradius et bird fonctionnent normalement sous BSD).
Le membre doit avoir au moins une machine pour faire tourner un LNS, un radius et un daemon de routage dynamique. Il s'agira typiquement d'une machine virtuelle sur ?tillac.
Les IP des LNS pour le membre sont fournies par Grenode (ip en /32).
- Rézine : 91.216.110.41, 91.216.110.60
- Illyse : 91.216.110.42
- Ilico : 91.216.110.43
Ces préfixes /32 doivent être annoncées par le membre en BGP.
Réseau d'interconnexion grenode membre
La livraison entre ajut/attrape et les LNS du membres se fait sur un vlan dédié
avec un range d'ip privée 172.16.<vlan>.0/24. Cf Livraisons IP bgp.
Radius
Coté grenode
/etc/freeradius/users:
rzn.gnd.dslnet.fr Proxy-To-Realm := 'rzn.gnd.dslnet.fr'
/etc/freeradius/proxy.conf:
- une section
home_server_pool - une ou plusieures sections
home_server - une ou plusieures sections
realm
Coté membre
Il faut autoriser les radius de Grenode à questionner le radius du membre et configurer les bons mots de passe. Adresses possibles pour les radius :
- 91.216.110.108
- 91.216.110.107
D'autre part, le radius du membre devra renvoyer une ip de livraison de Grenode
dans l'attribut Tunnel-End-Point ainsi que le mot de passe à utiliser par le
LAC (Tunnel-Password) pour établir une session avec le LNS du membre.
Exemple d'une requête et d'une réponse radius valide fait avec radtest sur ajut, pour Rézine :
ajut$ radtest test!rzn%gnd@fdn.nerim user_password localhost 12345 <secret>
Sending Access-Request of id 186 to 127.0.0.1 port 1812
User-Name = "test!rzn%gnd@fdn.nerim"
User-Password = "user_password"
NAS-IP-Address = 91.216.110.99
NAS-Port = 0
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=186, length=132
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-Routing = None
Framed-Compression = Van-Jacobson-TCP-IP
Acct-Interim-Interval = 5
Idle-Timeout = 86400
Tunnel-Type:1 = L2TP
Tunnel-Medium-Type:1 = IPv4
Tunnel-Password:1 = "lns_secret"
Tunnel-Server-Endpoint:1 = "91.216.110.41"
Tunnel-Assignment-Id:1 = "rezine_lns01"
Framed-IP-Netmask = 255.255.255.255
Framed-IP-Address = 193.33.56.63
D'autre part, pour Liazo, la requête faite par le LAC ne contient que le royaume en considérant que les logins sont de la forme user@royaume. Il faut donc une entrée de la sorte dans le radius du membre :
rzn.gnd.dslnet.fr Auth-Type = Accept
Service-Type = Outbound-User,
Tunnel-Type:1 = 3,
Tunnel-Medium-Type:1 = 1,
Tunnel-Server-Endpoint:1 = 91.216.110.41,
Tunnel-Assignment-ID:1 = 91.216.110.41,
Tunnel-Preference:1 = 10,
Tunnel-Client-Auth-Id:1 = LAC,
Tunnel-Server-Auth-Id:1 = "col1-rezine.grenode.net",
Tunnel-Type:2 = 3,
Tunnel-Medium-Type:2 = 1,
Tunnel-Server-Endpoint:2 = 91.216.110.60,
Tunnel-Assignment-ID:2 = 91.216.110.60,
Tunnel-Preference:2 = 10,
Tunnel-Client-Auth-Id:2 = LAC,
Tunnel-Server-Auth-Id:2 = "col2-rezine.grenode.net",
Tunnel-Password = "lns_secret",
Fall-Through = No
Où 91.216.110.41 et 91.216.110.60 sont les adresses des LNS du membre.
Pour tester :
ajut$ radtest rzn.gnd.dslnet.fr cisco localhost 12345 <secret>
Ce qui donne :
Sending Access-Request of id 114 to 127.0.0.1 port 1812
User-Name = "rzn.gnd.dslnet.fr"
User-Password = "cisco"
NAS-IP-Address = 91.216.110.99
NAS-Port = 12345
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=114, length=149
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-Routing = Broadcast-Listen
Framed-Compression = Van-Jacobson-TCP-IP
Acct-Interim-Interval = 5
Tunnel-Type:0 = L2TP
Tunnel-Medium-Type:0 = IPv4
Tunnel-Server-Endpoint:0 = "91.216.110.41"
Tunnel-Assignment-Id:0 = "91.216.110.41"
Tunnel-Preference:0 = 10
Tunnel-Client-Auth-Id:0 = "LAC"
Tunnel-Server-Auth-Id:0 = "col1-rezine.grenode.net"
Tunnel-Password:0 = "lns_secret"
BGP
Coté Grenode
Conf bird sur ajut/attrape :
function is_rezine() {
return (
(net ~ 193.33.56.0/23 && net.len >= 28)
|| (net ~ 91.216.110.41/32)
|| (net ~ 91.216.110.60/32)
);
}
protocol direct rezine_direct {
interface "eth1";
}
protocol bgp rezine_phloeme {
description "Connexion LNS rezine phloeme";
local as 65300;
neighbor 172.16.220.41 as 65303;
import where is_rezine();
export where is_collecte();
}
Avec :
- 172.16.220.41 est l'ip d'interconnexion du coté du membre
- 65303 est le numéro d'as local de rézine
- eth1 est l'interface de livraison du membre
Coté membre
Si vous utilisez bird :
protocol kernel {
learn;
persist;
scan time 20;
import all;
export all;
device routes yes;
}
protocol device {
scan time 10;
}
protocol bgp grenode_ajut {
description "Session ajut";
local as 65303;
multihop;
neighbor 172.16.220.99 as 65300;
export all;
import all;
}
protocol bgp grenode_attrape {
description "Session ajut";
local as 65303;
multihop;
neighbor 172.16.220.100 as 65300;
export all;
import all;
}
L2TP
Les LNS doivent accepter les connexions avec le secret partagé diffusé par le radius du membre dans l'attribut Tunnel-Password.
Par ailleurs, le LNS doit être configuré avec le même hostname que celui envoyé à Liazo dans l'attribut Tunnel-Server-Auth-Id. Sinon, l'établissement du tunnel échouera.
Sous FreeBSD : mpd5
Illyse utilisait MPD5 sous FreeBSD pour se faire livrer la collecte Grenode.
Cependant, MPD5 ne supporte pas IPv6 (DHCPv6-PD), donc Illyse est également passé à l2tpns.
Un début de documentation ancienne est disponible ici : https://www.ffdn.org/wiki/doku.php?id=documentation:adslmpd5
Sous Debian : l2tpns
Rézine, Ilico et Illyse utilisent désormais l2tpns, tout comme FDN. Le support IPv6 a été rajouté dans l2tpns par Fernando de Sames Wireless.
Le projet est désormais maintenu par des membres de la FFDN : https://code.ffdn.org/l2tpns/l2tpns
Tant que l2tpns n'est pas revenu dans Debian, le mieux est d'utiliser les paquets Debian maintenus par Fendo : http://package.sameswifi.fr/. La version Stretch marche bien sous Buster.
Configuration l2tpns basique
Voir man startup-config et le fichier de configuration fourni en exemple.
Voilà un exemple de configuration basique :
# Debugging level
set debug 2
# Log file: comment out to use stderr, use "syslog:facility" for syslog
set log_file "/var/log/l2tpns"
# Write pid to this file
set pid_file "/var/run/l2tpns.pid"
# Shared secret with LAC (envoye au fournisseur via le proxy radius de Grenode)
set l2tp_secret "v3rys3cr3t"
# Must be the same value as the Tunnel-Server-Auth-Id Radius attribute sent to Liazo
set multi_hostname "col-membre.grenode.net"
# l2tp overhead in l2tpns is 6 but l2tp overhead of Ielo-Liazo is 8
set l2tp_mtu 1498
# dns
set primary_dns XX.XX.XX.XX
set secondary_dns YY.YY.YY.YY
set primary_ipv6_dns 2001:db8:42::53
set secondary_ipv6_dns 2001:db8:100::53
# radius: l2tpns will authenticate users through this server.
set primary_radius le.radius.fai.membre
set primary_radius_port 1812
set radius_secret "s3cur3p4ssw0rd"
set radius_authtypes "chap,pap"
set radius_accounting no
# cli
set cli_bind_address 127.0.0.1
# Gateway address given to clients (anything would work)
set peer_address XX.XX.XX.XX
# IPv6 address prefix (/64): only used to assign an address to the client
# router, DHCPv6 Prefix Delegation is used for the actual prefix assigned
# to the client network.
set ipv6_prefix 2001:db8:1000:42::0
set dhcp6_server_duid 43215
set ppp_keepalive yes
# service fail if empty...
set accounting_dir "/var/log/l2tpns_accounting"
Configuration l2tpns en cluster anycast
l2tpns a un système de "cluster" qui peut être utilisé pour partager la charge sur plusieurs serveurs (pas très utile pour nous), mais aussi pour créer une redondance.
La configuration présentée ici est une configuration "anycast" : une unique adresse IP de terminaison des tunnels L2TP est annoncée à Grenode (puis Liazo) par les deux serveurs l2tpns. Par ailleurs, côté FAI, les IP des abonnés sont également annoncées en anycast par les deux serveurs l2tpns.
Le schéma suivant résume l'architecture, avec IP_LNS identique des deux côtés :
+++++++++++++++++++++++++++
+ Grenode +
+++++++++++++++++++++++++++
. . . .
| _/ \_ |
|BGP _/` `\_ BGP|
| _/` `\_ |
IP_LNS |/` `\| IP_LNS
======== ========
LNS1 FAI <- clustering -> LNS2 FAI
======== ========
\_ _/
`\_ BGP ou OSPF _/`
`. .`
+++++++++
+ FAI +
+++++++++
L'anycast permet de faire du routage au plus court dans le cas nominal, et de basculer tout le trafic sur un seul serveur en cas de panne ou de maintenance. Par ailleurs, le clustering assure que toutes les sessions abonnés sont synchronisées entre les LNS.
Ainsi :
pour le trafic descendant (du FAI vers l'abonné), le reste du réseau du FAI peut envoyer le trafic à LNS1 ou LNS2 de façon indifférente. Dans les deux cas, l2tpns encapsulera le paquet abonné dans le bon tunnel L2TP avec le bon numéro de session, et enverra le paquet L2TP ainsi encapsulé à Grenode puis Liazo (avec comme IP source l'adresse anycast
IP_LNS)pour le trafic montant (de l'abonné vers le FAI), Liazo/Grenode peut envoyer le trafic encapsulé à LNS1 ou LNS2 de façon indifférente. Dans les deux cas, l2tpns décapsulera le paquet L2TP et enverra le paquet de l'abonné vers le reste du réseau du FAI.
Pour que ça fonctionne, il est évidemment nécessaire de synchroniser l'état des deux daemons l2tpns, et c'est précisément ce que permet le clustering l2tpns.
Dans un cluster, il y a une instance l2tpns "primaire" et une ou plusieurs instances l2tpns "secondaires". Toutes les instances l2tpns jouent le même rôle lorsqu'il s'agit de transmettre du trafic abonné, mais il y a une différence lors de l'ouverture de connexion :
- Liazo envoie la demande d'ouverture de connexion indifférement à LNS1 ou LNS2 (c'est du anycast)
- si ça arrive sur le l2tpns primaire, il traite cette demande (Radius, etc) et envoie l'information aux l2tpns secondaires
- si ça arrive sur un l2tpns secondaire, celui-ci transmet simplement la demande au l2tpns primaire
Configuration
En terme de configuration, il faut un canal de communication entre les deux l2tpns
pour le clustering. Aucun traffic abonné ne passera sur ce canal. l2tpns utilise
du multicast pour le clustering : si c'est trop compliqué à faire marcher, on peut
très bien encapsuler ce trafic dans un simple tunnel GRE :
auto l2tpnscluster
iface l2tpnscluster inet static
address 10.42.42.XX/24
pre-up ip tunnel add $IFACE mode gre local 172.16.<VLAN>.XX remote 172.16.<VLAN>.YY ttl 10
up ip link set mtu 1450 dev $IFACE
post-down ip tunnel del $IFACE
L'activation du cluster se fait en 3 lignes dans /etc/l2tpns/startup-config,
identiques sur les 2 machines :
# Must match Tunnel-Server-Auth-Id and be the same on both machines
set multi_hostname "col-membre.grenode.net"
# Anycast IP address to configure on tun0 and announce to Grenode/Liazo
set bind_address "91.216.110.XX"
# Interface on which we synchronise with the other member of the cluster
set cluster_interface "l2tpnscluster"
L'adresse IP à mettre dans bind_address est l'adresse anycast IP_LNS du schéma.
Attention : il ne faut surtout pas configurer cette IP IP_LNS sur une interface
de la machine, contrairement à ce que le bind pourrait laisser croire ! C'est l2tpns
lui-même qui rajoutera cette adresse IP sur une interface (tun0 en l'occurrence).
Ainsi, si l2tpns crashe ou s'éteint, cette adresse IP disparaît de la machine, et
on cesse de l'annoncer en BGP à Grenode/Liazo. C'est une condition nécessaire dans toute
architecture anycast, sinon on se retrouverait à recevoir du trafic alors que le service
n'est pas disponible.
Script d'init
Attention, le script d'init Debian a un bug : il éteint l2tpns avec le signal
SIGQUIT, ce qui coupe toutes les sessions utilisateurs. Pas pratique pour
un cluster où un autre l2tpns est censé prendre le relais...
Le mieux est de prendre le service systemd ici https://code.ffdn.org/l2tpns/l2tpns/-/blob/master/scripts/l2tpns.service, il sera utilisé en priorité à la place du script d'init Debian :
# cp l2tpns.service /etc/systemd/system/l2tpns.service
# systemctl daemon-reload
# systemctl status l2tpns
# systemctl restart l2tpns
# systemctl enable l2tpns
Ce problème devrait être corrigé dans la version ré-introduite dans Debian.
Configuration Bird
La configuration Bird BGP entre le membre et Grenode est identique à la configuration normale. Bien vérifier que chaque LNS annonce l'unique IP LNS à ajut et attrape.
En revanche, côté FAI, l'anycast risque de ne pas fonctionner de base. En effet, Bird récupère les routes vers les abonnés depuis le protocole kernel (puisque l2tpns les insère dans le kernel) pour pouvoir les propager en OSPF ou BGP au reste du réseau FAI. Mais ces routes ont une priorité ("preference") très faible, elle sont notamment moins prioritaires que les routes apprises par OSPF ou BGP.
En pratique, un des deux LNS va réussir à annoncer le premier une route abonné dans OSPF/BGP, et l'autre LNS, apprenant cette route, la prendra en compte et n'annoncera donc pas lui-même la route vers l'abonné.
Pour résoudre ce problème il faut augmenter la priorité des routes apprises depuis le noyau :
protocol kernel {
learn;
scan time 5;
import filter {
# By default, kernel routes have very low preference (10).
# Routes from a local l2tpns instance should have higher preference than OSPF.
if krt_source = 42 then {
# We assign the same preference as static routes.
preference = 200;
}
accept;
};
export all;
}
On matche sur le proto 42 utilisé par l2tpns (cf. ip route show). Attention, ça pourrait
changer un jour.
Tests
Vérifier dans les logs que les deux l2tpns arrivent bien à se voir, et que l'un passe en primaire et l'autre en secondaire.
Ensuite, essayer d'éteindre un des deux l2tpns. Le trafic devrait basculer quasi-instantanément sur l'autre, avec seulement 1 à 2 secondes de coupure. En relançant l2tpns, il devrait se resynchroniser à partir de celui qui était encore allumé.
Éléments de configuration détaillés
Ielo-Liazo
Deux fois trois VLAN d'inteconnexions (cf Plan du réseau) :
- Radius
- Best effort
- Premium
Un sessions BGP par VLAN
- Radius : ne doit être annoncé que les radius en /32
- Best effort : ne doit être annnocé que les LNS en /32
- Premium : ne doit être annoncé que les LNS en /32 (pas les même que best effort)
La requête radius du LAC de Liazo est de la forme :
Access-Request packet from host 178.20.54.69 port 43234, id=17, length=134
User-Name = "rzn.gnd.dslnet.fr"
User-Password = "cisco"
Connect-Info = "4294320195/0"
NAS-Port-Type = ISDN
NAS-Port = 20307
NAS-Port-Id = "Uniq-Sess-ID197"
Service-Type = Outbound-User
NAS-IP-Address = 178.20.54.8
Message-Authenticator = 0xd01153408a89fafdecda67451bf7ff04
Proxy-State = 0x3338
Radius
Sur ajut et attrape sont installés le logiciel freeradius qui agit en proxy radius. Le but est d'accepter les requêtes venant d'un autre radius (typiquement, celui du fournisseur) pour les faire suivre vers les radius/lns des FAIs. Les requêtes reçues sont dispatchées selon leur royaume.
- pour FDN : login!
fai%gnd@fdn.nerim - pour Liazo : login@
fai.gnd.dslnet.fr
Où fai est le trigrame du membre.
/etc/default/freeradius
On laisse les options dans /etc/default/freeradius vides.
radiusd.conf
On laisse globalement les paramètres par défaut.
Les réglages changés :
- dans la section log :
auth = yespermet d'avoir plus de détails pour faire du supportauth_badpass = yespermet de repérer les doigts palmés
- la section instantiate est commentée, comme chez FDN
proxy.conf
La section proxy server reste presque vide. Il faut juste laisser :
default_fallback = no
Pour éviter de faire suivre des requêtes pour un FAI vers un autre si un serveur radius tombe.
La configuration est ensuite éclatée dans un fichier pour chaque FAI, spécifiant :
- un
home_server_pool - un ou plusieurs
home_server - un realm
Le principe du truc, c'est de définir une forme de login dans le realm. Pour ce
realm, on donne un home_server_pool (qui correspond à un FAI), et chaque FAI
peut définir un ou plusieurs home_server, qui sont les serveurs radius des FAIs.
Ces fichiers sont mis dans le répertoire fais puis inclus dans la
configuration principale dans le fichier proxy.conf. Dans ce fichier, on
inclus aussi un realm LOCAL et un realm NULL.
Attention, tous les fichiers du répertoire fais sont automatiquement inclus
dans la configuration ; si un nouveau FAI rejoint Grenode, il suffira donc de
créer son fichier de configuration dans ce répertoire.
clients.conf
On ajoute un client par machine censée demander des infos au radius ; à Grenode, ça donne :
# configuration des clients
client localhost {
ipaddr = 127.0.0.1
secret = secretpartage
require_message_authenticator = no
nastype = other # localhost isn't usually a NAS...
}
# vador - radius fdn
client 80.67.169.40 {
# secret and password are mapped through the "secrets" file.
secret = secretpartage
shortname = fdn
nastype = other
}
Si on a un jour d'autres fournisseurs de collecte, il faudra certainement ajouter leur radius dans ce fichier.
Les modules
On inclus tous les modules via la directive :
$INCLUDE ${confdir}/modules/
Module realm
Le module realm permet de définir les différentes méthode de découpage pour les royaumes.