Parmi les options permettant à un FAI local de fournir des accès à ses adhérents, il existe la possibilité de mutualiser les infrastructures dont dispose FDN, pour terminer des accès ADSL.

Trois modes sont envisageables :

• collecte en “marque blanche” : les lignes sont facturées au FAI associatif à un tarif revendeur, dégageant un espace économique lui permettant d'assurer son fonctionnement. Les accès utilisent des logins « FDN » et utilisent le pool d'adresse IP et la connectivité de FDN.
• routage vers la connectivité du FAI local : les frais refacturés correspondent uniquement aux couts de collecte, le trafic, pour sortir vers Internet est envoyé vers un routeur du FAI local, qui dispose de ses propres IPs et de se propre connectivité.
• terminaison sur un LNS du FAI local : les connexions sont transférées telles que reçues, dans un tunnel L2TP entre FDN et le FAI associatif. Il termine alors les accès comme il le souhaite, sur ses propres adresses, et sa propre connectivité. cette option n'est pas immédiatement réalisable, techniquement parlant

C'est la façon la plus simple et la plus immédiate. FDN revend en gros (ie plusieurs lignes facturées à une seule association) des accès, qui sont techniquement similaires aux lignes en propre de FDN.

Sur ce schéma, le réseau de collecte (première boite bleue) est simplifié. Pour un peu plus de détail voir schema_fai et schema_collecte_routage_fdn.

On y voit que l'authentification, utilisant le protocole Radius, est proxysé, au départ de l'opérateur de collecte, puis Nerim, puis enfin FDN, qui va vérifier que le nom d'utilisateur et le mot de passe sont corrects, et déterminer quelle adresse IP est distribuée à l'utilisateur. On peut aussi trouver, dans la réponse, des informations concernant un bloc d'IPs, v4 ou v6, à router sur cet accès.

La demande Radius nous arrive finalement du LNS, dans un paquet Access-Request comme celui-ci :

Packet-Type = Access-Request
Mon May 16 12:21:27 2011
      User-Name = "dominique.rousseau@fdn.nerim"
      User-Password = "XXXX"
      NAS-Port = 142
      Service-Type = Framed-User
      Framed-Protocol = PPP
      Called-Station-Id = "8888"
      NAS-IP-Address = 62.4.16.41
      Client-IP-Address = 80.67.161.141
      Huntgroup-Name = "fdn"

Les seuls attributs qui nous intéressent vraiment sont User-Name et User-Password, le reste, on en fait rien (mais on pourrait :).

Le serveur Radius répond avec un paquet Access-Accept (ou Reject si les identifiants ne sont pas bons) :

Packet-Type = Access-Accept
Mon May 16 12:21:27 2011
      Framed-IP-Address = 80.67.176.2
      Framed-IP-Netmask = 255.255.255.255
      Service-Type := Framed-User
      Framed-Protocol := PPP
      Framed-Routing := None
      Idle-Timeout := 86400

On peut avoir de façon optionelle des attributs Framed-Route (pour attribuer une route ipv4 : subnet/mask) ou Framed-IPv6-Route (pour une route ipv6, même format)

Dans la section L2TP (du réseau opérateur jusqu'à FDN), on trouve plusieurs connexions PPP, provenant de plusieurs connectés ([1], [2], etc.).

Le bloc Internet correspond à Gitoyen + sa conenctivité.

Dans le cas d'un FAI qui dispose de sa propre connectivité vers Internet, et de ses propres blocs d'IPs, le schéma donne ça :

Cette fois ci, on trouve les connectés de FDN (toujours en jaune), et les connectés de FaiA, en rouge.

Ils empruntent le même réseau de collecte opérateur, ainsi que chez Nerim.

La différence se fait une fois arrivé chez FDN. On trouve ici un lien (un simple cable reliant le switch de FDN et celui de FaiA, un Lan2Lan vers “loin”, etc.) qui relie FDN et FaiA.

Et celà à deux niveaux :

• l'authentification va être proxysée une fois de plus, du serveur Radius d'FDN vers celui de FaiA. Le transfert se fera sur la base d'un sous realm (royaume).
• le trafic sortant est envoyé vers le routeur de FaiA. Le trafic entrant arrive naturellement vers son réseau, et il transmet aux routeurs d'FDN.

Pour les requetes Radius, elles auront une forme sur laquelle les 2 se sont mis d'accord, par exemple :

User-Name = "gerard.dugenou/faia@fdn.nerim"

Dans ce cas, le serveur Radius d'FDN sera configuré de telle façon qu'il saura qu'il doit transmettre la requete Radius vers un autre serveur.

Le Radius de FaiA répondra, lui, avec un paquet contenant, par exemple :

Framed-IP-Address = 91.224.148.5

Si on reprend le schéma en se concentrant sur l'interconnexion de FDN et FaiA, ça donne :

On va supposer que FaiA va distribuer des adresses IPs faisant partie de 91.224.148.0/26.

Côté FDN, on va faire du routage en fonction de l'adresse IP source (les paquets ont pour origine une adresse IP dans 91.224.148..0/26, et pour destination « n-importe-où-sur-internet ». Sous Linux, avec iproute2, ça donnerait quelque chose qui reseemble à ça :

ip rule add from 91.224.148.0/26 table faia
ip route add default table faia via 80.67.161.242

Ces règles ont pour effet de :

• créer une nouvelle table de routage nommée faia. On définit qu'on doit utiliser cette table, plutot que la table par défaut, lorsque l'ip source est dans 91.224.148.0/26.
• on définit que la route par défaut, dans cette table est de passer par 80.67.161.242

Une fois transmis à 80.67.161.242 (routeur de FaiA), c'est à lui de se débrouiller, et d'utiliser ses propres règles de routage pour atteindre la destination.

Dans l'autre sens, FaiA est le point d'entrée annoncé à tout l'internet pour gérer 91.224.148.0/24 (ie un sur-réseau de 91.224.148.0/26). Il va donc devoir acheminer les paquets à destination de 91.224.148.0/26 vers le routeur d'FDN. Une seule règle de routage suffit pour faire celà :

ip route add 91.224.148.0/26 via 80.67.161.241

pas réalisable pour l'instant