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 :

  1. l'abonné initie une session PPP via les équipements de l'opérateur de collecte
  2. 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)
  3. la requête est transmise au radius du membre concerné puis retournée jusqu'au LAC
  4. Le LAC propage le tunnel L2TP vers le LNS spécifié.
  5. le LNS reçoit la demande d'établissement du tunnel L2TP et authentifie l'abonné via son radius.
  6. 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

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).

Réseau d'interconnexion grenode membre

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.

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.

  • Rézine : vlan 220, 172.16.220.0/24
  • Illyse : vlan 221, 172.16.221.0/24
  • Ilico : vlan 222, 172.16.222.0/24

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.

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

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.

Sous Debian : l2tpns

Rézine utilise l2tpns http://git.sameswireless.fr/l2tpns.git

Sous FreeBSD : mpd5

Illyse utilise MPD5 sous FreeBSD pour se faire livrer la collecte Grenode.

Un début de documentation est disponible ici : 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 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.

Il est possible pour cela 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.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 = "secret",
      Fall-Through = No

Les IP 91.216.110.41/32, 91.216.110.60/32 devront être annoncés en BGP par le membre.

Redondance de l'infrastructure de Grenode

Pour l'instant, les machines ajut et attrape se trouvent pour l'instant toutes les deux à Vénisieux, elles participent aux mêmes vlan de livraisons.

É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

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 = yes permet d'avoir plus de détails pour faire du support
    • auth_badpass = yes permet 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.

Redondance du lien L2 avec FDN

Pour conserver la collecte ADSL lorsque le L2 avec FDN est en panne, un lien de collecte alternatif a été mis en place. Il s'agit d'un tunnel GRE/IPsec entre ?ajut et ?chaloupe chez gitoyen, à travers Internet. ?chaloupe est elle-même connectée aux LNS de FDN, sur le même L2 de livraison de collecte qu'ajut et attrape.

        +-----+---------------------------+
Rézine--|eth1 |    ajut (grenode)         |                  -------
        +-----+                           | Grenode       --/       \--
Illyse--|eth2 |                     +-----+              /             \
        +-----+                     | eth0|==============|   Internet  |
 Ilico--|eth7 |                     +-----+ 91.216.110.99\             /
        +-----+     +------+              | VLAN 200      --\       /--
        |           | eth4 |              |                  ---++--
        +-----------+---+--+--------------+                     ||
        80.67.161.43/29 |                                       ||
                        |    COLLECTE               COLLECTE    ||
                        |    (nominal)              (backup)    ||
                        |                                       ||
                        | VLAN 117                              || Tunnel
               Rezopole +                                       || GRE/IPsec
                        |                                       ||
                        | Traduction VLAN                       ||
                  Liazo +                                       ||
                        | VLAN 21                               ||
                        |                                       ||
                        |                                       ||
                        |          +---------------------+      ||
                        |          | chaloupe (gitoyen)  |      ||
Gitoyen                 |          |               +-----+      || Gitoyen
                        |          |               | eth0|------++
                        |          +-----+         +-----+ 80.67.163.60
                        +----------|eth1 |               | VLAN 41
                        |          +-----+---------------+
                        |          80.67.161.45/29
                        |VLAN 21
                  +-----+-----+
                  |           |
  80.67.161.41/29 |           | 80.67.161.42/29
      +-----------+-+       +-+-----------+
      |             |       |             |
FDN   | LNS01 (FDN) |       | LNS02 (FDN) |
      |             |       |             |
      +-------------+       +-------------+

Attrape n'est pas représentée sur ce schéma, elle a le même rôle qu'ajut.

Les sessions BGP sont établies comme suit, pour la collecte nominale :

  • LNS01 FDN - ajut
  • LNS02 FDN - ajut
  • LNS01 FDN - attrape
  • LNS02 FDN - attrape

Pour le lien de collecte de backup :

  • LNS01 FDN - chaloupe
  • LNS02 FDN - chaloupe
  • chaloupe - ajut (iBGP, sur tunnel GRE/IPsec)
  • chaloupe - attrape (iBGP, sur tunnel GRE/IPsec)