Il était une fois...

La Freebox «Révolution»

 Les 8 sous-réseaux Avec ses 23 sous-réseaux /64 (Pourquoi pas 24 tant qu'on y était ?)…

Cette page, accessible dans Freebox OS à partir du mode avancé des paramètres de la Freebox, au chapitre «Configuration IPv6» permet de définir un «next hop» pour chaque sous-réseau supplémentaire. L'adresse indiquée est de type lien local et correspond à l'interface du routeur situé dans le sous-réseau de base (le premier de la liste). Il faut naturellement ajouter un ou plusieurs routeurs dans notre structure.

Nous allons exploiter deux sous-réseaux supplémentaires.

La manip pour les Geeks

Voici ce que nous allons faire: usine Pourquoi pour les Geeks ?

Parce-qu'à priori, un tel montage ne devrait pas vraiment être utile au particulier et que le professionnel disposera probablement d'autre chose qu'une Freebox pour se connecter à l'internet. Donc la seule véritable utilité de ce montage est d'aider à comprendre comment tout ceci fonctionne. Merci tout de même aux concepteurs de la Freebox de nous permettre ce genre d'amusement.

  • dans le sous-réseau de base, directement servi par la Freebox, nous avons:
    • un serveur «ns1» qui nous sert de DNS-qui-ne-ment-pas pour nos recherches récursives et qui peut éventuellement gérer des domaines ou sous-domaines intranet. Il a aussi quelques autres fonctions, mais qui ne nous intéressent pas ici;
    • un «routeur1» qui a un pied dans le sous-réseau de base et un pied dans chaque sous-réseau supplémentaire;
    • ce qu'il peut y avoir de plus dans ce sous-réseau ne concerne pas cette étude;
  • dans chaque sous-réseau supplémentaire, nous placerons une machine, surtout pour vérifier que notre routeur interne est bien construit.

Sur la Freebox

Il faut indiquer le routeur suivant (next hop) qui sera utilisé pour chaque sous-réseau que l'on désire exploiter, ici 2a01:e35:2f35:d1::/64 et 2a01:e35:2f35:d2::/64. Il doit être identifié par l'adresse de lien local dont il dispose dans le sous-réseau servi par la Freebox 2a01:e35:2f35:d0::/64.

Dans notre cas, comme c'est le même routeur qui va se taper le travail, le «next-hop» est le même dans les deux cas.

Du côté de la Freebox, il n'y a rien de plus à faire.

Sur le routeur

Le routeur est une machine Debian Jessie et là, pour faire quelque chose qui aille bien, il va y avoir un peu de travail. Comme c'est ici IPv6 qui nous intéresse, nous n'aurons pas à nous occuper d'une quelconque configuration IPv4.

Sois un routeur !

En v6 comme en v4, le kernel ne routera pas par défaut. Il faut agir en dé-commentant dans /etc/sysctl.conf la ligne:

net.ipv6.conf.all.forwarding=1

et rendre actif tout de suite:

sysctl -p

Les interfaces Ethernet

Nous considérons ceci:

  • eth0 sur 2a01:e35:2f35:d0::/54 en configuration automatique sans état (auto-configuration);
  • eth1 sur 2a01:e35:2f35:d1::/64 en configuration manuelle, avec l'adresse 2a01:e35:2f35:d1::1/64;
  • eth2 sur 2a01:e35:2f35:d2::/64 en configuration manuelle, avec l'adresse 2a01:e35:2f35:d2::1/64.

En ce qui concerne les adresses de lien local, il n'y a pas de mystère, elle seront auto-configurées dans fe80::/64 avec un jeton calculé en mode EUI-64.

Ceci nous donne le fichier /etc/network/interfaces suivant:

auto lo
iface lo inet loopback

iface eth0 inet6 auto

auto eth1
iface eth1 inet6 static
	address 2a01:e35:2f35:d1::1/64

auto eth2
iface eth2 inet6 static
        address 2a01:e35:2f35:d2::1/64

Après démarrage du routeur nous devons avoir sur les interfaces:

ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:3e:0d:fd:42  
          adr inet6: fe80::216:3eff:fe0d:fd42/64 Scope:Lien
          adr inet6: 2a01:e35:2f35:d0:216:3eff:fe0d:fd42/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2510 errors:0 dropped:0 overruns:0 frame:0
          TX packets:157 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:285413 (278.7 KiB)  TX bytes:12180 (11.8 KiB)

eth1      Link encap:Ethernet  HWaddr 00:16:3e:0d:fd:41  
          adr inet6: fe80::216:3eff:fe0d:fd41/64 Scope:Lien
          adr inet6: 2a01:e35:2f35:d1::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:73 errors:0 dropped:0 overruns:0 frame:0
          TX packets:266 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:10893 (10.6 KiB)  TX bytes:45488 (44.4 KiB)

eth2      Link encap:Ethernet  HWaddr 00:16:3e:0d:fd:40  
          adr inet6: fe80::216:3eff:fe0d:fd40/64 Scope:Lien
          adr inet6: 2a01:e35:2f35:d2::1/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:79 errors:0 dropped:0 overruns:0 frame:0
          TX packets:266 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:11361 (11.0 KiB)  TX bytes:45676 (44.6 KiB)

lo        Link encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:56 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:3582 (3.4 KiB)  TX bytes:3582 (3.4 KiB)
et si l'on recherche les routes:
ip -6 route ls
2a01:e35:2f35:d0::/64 dev eth0  proto kernel  metric 256  expires 86091sec mtu 1480
2a01:e35:2f35:d1::/64 dev eth1  proto kernel  metric 256 
2a01:e35:2f35:d2::/64 dev eth2  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1480
fe80::/64 dev eth1  proto kernel  metric 256 
fe80::/64 dev eth2  proto kernel  metric 256 
default via fe80::1e7e:e5ff:fe26:5451 dev eth0  proto ra  metric 1024  expires 1491sec hoplimit 64
La route par défaut pointe sur l'adresse de lien local de la Freebox. C'est normal, nous savons que ce sont ICMP6 et NDP les responsables et la Freebox qui envoie les bonnes réponses.

Le problème c'est qu'il faudra s'arranger pour que tout ceci fonctionne aussi sur les deux autres sous-réseaux. De ce côté là c'est notre routeur qui va devoir fournir les bonnes réponses.

Un proxy DNS

C'est certes du luxe, puisque nous avons déjà un serveur DNS qui nous donne entière satisfaction, mais tout de même, sa présence nous rendra la vie un peu plus simple, surtout si nous désirons installer par la suite un pare-feu sur notre routeur.

dnsmasq fera l'affaire et nous allons lui dire d'interroger notre serveur ns1. Dans un tel cas, le fichier /etc/dnsmasq.conf sera d'une extrême simplicité, ne contenant qu'une seule ligne:

server=2a01:e35:2f35:d0:22cf:30ff:feb5:efe9

Après avoir relancé le service, il devrait être opérationnel.

Le «Router ADVertisement Daemon»

Il s'agit de la pièce principale, celle qui va permettre à notre routeur d’envoyer les bonnes répondes aux requêtes ICMP6 des futurs clients. Il faut installer le paquet «radvd» dont la description est tout-à-fait explicite:

Description :

Démon d'information de routeur IPv6 a beaucoup plus de capacité pour l'auto-configuration que IPv4. Mais pour que cette auto-configuration fonctionne sur les hôtes d'un réseau, les routeurs du réseau local doivent exécuter un programme qui répond aux requêtes d'auto-configuration émises par les hôtes.

Sur Linux, ce programme est appelé radvd, qui signifie « Router ADVertisement Daemon », démon d'information de routeur. Ce démon écoute les sollicitations de routeurs (RS, « router solicitations ») et répond par des informations de routeur (RA, « routeur advertisement »). De plus, des RA non sollicitées sont émises de temps en temps.

L'installer, c'est facile ; le configurer est un peu plus complexe. Voici le fichier une fois mis au point:

interface eth1 {
       AdvSendAdvert on;
       MaxRtrAdvInterval 60; 
       prefix 2a01:e35:2f35:d1::/64
       {
               AdvAutonomous on;
       };

       	RDNSS 2a01:e35:2f35:d1::1 2a01:e35:2f35:d0:22cf:30ff:feb5:efe9
       	{
               	AdvRDNSSLifetime 120;
       	};

       	DNSSL mondomaine.local
       	{
               	AdvDNSSLLifetime 120;
       	};

};

interface eth2 {
       AdvSendAdvert on;
       MaxRtrAdvInterval 60;
       prefix 2a01:e35:2f35:d2::/64
       {
               AdvAutonomous on;
       };

        RDNSS 2a01:e35:2f35:d2::1 2a01:e35:2f35:d0:22cf:30ff:feb5:efe9
        {
                AdvRDNSSLifetime 120;
        };

        DNSSL mondomaine.local
        {
                AdvDNSSLLifetime 120;
        };

};
La première chose à constater, c'est que les paragraphes concernant les deux interfaces eth1 et eth2 sont structurellement identiques. Reste à en déchiffrer la syntaxe:

  • AdvSendAdvert indique si oui ou non le routeur doit envoyer des annonces et répondre aux sollicitations;
  • MaxRtrAdvInterval indique la durée maximale entre deux annonces multicast non sollicitées;
  • prefix là c'est facile: c'est le préfixe annoncé pour le sous-réseau concerné;
    • AdvAutonomous indique si l'auto-configuration est autorisée ou pas (utile dans le cas où l'on utiliserait des configurations «stateful» manuelles ou par DHCP);
  • RDNSS annonce d'une ou plusieurs adresses de serveurs DNS récursifs;
    • AdvRDNSSLifetime indique la durée pendant laquelle on peut utiliser le ou les serveurs annoncés;
  • DNSSL annonce le ou les noms de domaines à utiliser par défaut dans les recherches DNS, si le domaine n'est pas indiqué dans la requête;
    • AdvDNSSLLifetime indique la durée pendant laquelle on peut utiliser le ou les noms de domaine annoncés.

Nous aurions en réalité pu écrire un fichier plus simple, AdvAutonomous étant à on par défaut, MaxRtrAdvInterval étant initialisé par défaut à 600 secondes (ce qui est peut-être beaucoup), AdvRDNSSLifetime et AdvDNSSLLifetime étant par défaut initialisés à 2 x MaxRtrAdvInterval.

Du côté du routeur, tout est normalement en ordre. Il faut juste s'assurer que le service radvd est bien actif et en fonctionnement:

service radvd status

Les clients

pour tester le tout, nous ajoutons deux nouveaux nœuds comme ceci: Montage final Les nœuds host1 et host2 sont des machines Debian Jessie, sans configuration particulière, leur fichier /etc/network/interfaces contient ceci:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet6 auto

Divination

Nous connaissons:

  • l'adresse MAC de chacun de ces nœuds;
  • le préfixe IPv6 normalement attribué à chacun d'eux.

Nous allons deviner leurs adresses IPv6.

Pour host1

Dispose de l'adresse MAC 00:16:3e:28:5c:d2 que nous allons convertir au format EUI-64:

ipv6calc --action geneui64 --in mac  --out eui64 00:16:3e:28:5c:d2
216:3eff:fe28:5cd2
Le préfixe de sons sous-réseau étant 2a01:e35:2f35:d1::/64, bous pouvons en conclure que:

  • son adresse de «scope link» sera fe80::216:3eff:fe28:5cd2;
  • son adresse de «scope global» auto-configurée sera 2a01:e35:2f35:d1:216:3eff:fe28:5cd2.

Pour host2

  • adresse MAC : 00:16:3e:f4:67:75;
  • convertie EUI-64 : 216:3eff:fef4:6775;
  • préfixe : 2a01:e35:2f35:d2::/64.

Donc:

  • adresse «link» : fe80::216:3eff:fef4:6775;
  • adresse globale : 2a01:e35:2f35:d2:216:3eff:fef4:6775.

Vérifications

Sur host1

Pour les adresses:

ifconfig eth0

eth0      Link encap:Ethernet  HWaddr 00:16:3e:28:5c:d2  
          adr inet6: 2a01:e35:2f35:d1:216:3eff:fe28:5cd2/64 Scope:Global
          adr inet6: fe80::216:3eff:fe28:5cd2/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:103 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:17433 (17.0 KiB)  TX bytes:806 (806.0 B)

Pour les routes:

ip -6 route ls

2a01:e35:2f35:d1::/64 dev eth0  proto kernel  metric 256  expires 86379sec
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::216:3eff:fe0d:fd41 dev eth0  proto ra  metric 1024  expires 159sec hoplimit 64
Comme d'habitude, la route par défaut est indiquée par une adresse de scope «link».

Et tout ceci est obtenu par la découverte du voisinage qui est automatiquement menée au démarrage du nœud, mais que l'on peut forcer manuellement:

rdisc6 eth0

Solicitation de ff02::2 (ff02::2) sur eth0...

Limite de saut (TTL)      :           64 (      0x40)
Conf. d’adresse par DHCP  :          Non
Autres réglages par DHCP  :          Non
Préférence du routeur     :        moyen
Durée de vie du routeur   :          180 (0x000000b4) secondes
Temps d’atteinte          :  non indiqué (0x00000000)
Temps de retransmission   :  non indiqué (0x00000000)
 Préfixe                  : 2a01:e35:2f35:d1::/64
  Durée de validité       :        86400 (0x00015180) secondes
  Durée de préférence     :        14400 (0x00003840) secondes
 Serveur DNS récursif     : 2a01:e35:2f35:d1::1
 Serveur DNS récursif     : 2a01:e35:2f35:d0:22cf:30ff:feb5:efe9
  Validité des serveurs   :          120 (0x00000078) secondes
 Adresse source de lien   : 00:16:3E:0D:FD:41
 de fe80::216:3eff:fe0d:fd41

Sur host2

Pas la peine de tout détailler, si ça fonctionne pour host1, ça fonctionne aussi pour host2. Il va tout de même apparaître comme un défaut dans les recherches DNS:

host irp.nain-t.net
;; connection timed out; no servers could be reached
La résolution ne se fait pas, aucun serveur ne peut-être atteint ! Pourtant nous savons que NBD fait son travail et annonce deux serveurs DNS

Sachant que sur Debian, les serveurs DNS sont référencés dans le fichier /etc/resolv.conf, nous pouvons constater que son contenu est vide ou inadapté. Quelque chose quelque-part ne fait pas son travail sur host2 puisque l'on sait que routeur1 annonce bien les DNS.

En réalité, il manque probablement le service spécialisé qui doit récupérer l'annonce DNS et la consigner dans /etc/resolv.conf.

Le service "rdnssd"

aptitude show rdnssd

Paquet : rdnssd                                         
État: non installé
Version : 1.0.1-1+b1
Priorité : optionnel
Section : net
Responsable : Rémi Denis-Courmont 
Architecture : amd64
Taille décompressée : 111 k
Dépend: libc6 (>= 2.4)
Pré-dépend: adduser
Recommande: resolvconf
Suggère: ndisc6
Description : IPv6 recursive DNS server discovery daemon
 rdnssd autoconfigures recursive DNS servers on IPv6 networks using ICMPv6 Neighbor Discovery (RFC 5006), and can update the DNS
 resolvers configuration (/etc/resolv.conf) accordingly.

C'est exactement ce qu'il nous faut et ce n'est pas installé. Ce paquet recommande resolvconf qui n'est pas forcément utile. Pour montrer ici qu'il ne l'est pas :

aptitude install -R rdnssd

Bien entendu, il faut s'arranger pour joindre le dépôt Debian indiqué dans /etc/apt/sources.list sans disposer d'une résolution de nom facilement fonctionnelle. Cette page s'adressant à des geeks, je ne vais pas leur faire l'injure de leur dire comment faire.

Après résolution de la résolution des noms et installation du paquet, un:

rdisc6 eth0

devrait permettre à rdnssd de mettre à jour le resolv.conf

Et ça marche ?

Ping depuis host1 sur host2:

ping6 -c2 2a01:e35:2f35:d2:216:3eff:fef4:6775

PING 2a01:e35:2f35:d2:216:3eff:fef4:6775(2a01:e35:2f35:d2:216:3eff:fef4:6775) 56 data bytes
64 bytes from 2a01:e35:2f35:d1:216:3eff:fef4:6775: icmp_seq=1 ttl=63 time=0.272 ms
64 bytes from 2a01:e35:2f35:d1:216:3eff:fef4:6775: icmp_seq=2 ttl=63 time=0.057 ms

--- 2a01:e35:2f35:d2:216:3eff:fef4:6775 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.057/0.164/0.272/0.108 ms
Résolution d'un nom:
host orange.kame.net

orange.kame.net has address 203.178.141.194
orange.kame.net has IPv6 address 2001:200:dff:fff1:216:3eff:feb1:44d7
Itinéraire:
tcptraceroute6 orange.kame.net

traceroute vers orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) de 2a01:e35:2f35:d1:216:3eff:fe28:5cd2, port 80, du port 64543, 30 sauts max, 60 octets/paquet
 1  2a01:e35:2f35:d1::1 (2a01:e35:2f35:d1::1)  0.004 ms  0.025 ms  0.041 ms 
 2  2a01:e35:2f35:d0::1 (2a01:e35:2f35:d0::1)  0.288 ms  0.164 ms  0.172 ms 
 3  2a01:e00:18::1d (2a01:e00:18::1d)  37.031 ms  37.057 ms  36.868 ms 
 4  2a01:e00:18::e (2a01:e00:18::e)  36.112 ms  35.897 ms  36.726 ms 
 5  be4204.ccr21.par04.atlas.cogentco.com (2001:978:2:1b::49:1)  37.531 ms  36.080 ms  35.438 ms 
 6  2001:978:3::42 (2001:978:3::42)  37.024 ms  36.371 ms  34.800 ms 
 7  ae-5.r02.parsfr02.fr.bb.gin.ntt.net (2001:728:0:2000::32)  37.324 ms  35.706 ms  35.623 ms 
 8  ae-5.r22.amstnl02.nl.bb.gin.ntt.net (2001:728:0:2000::1e5)  47.771 ms  46.928 ms  47.206 ms 
 9  ae-3.r25.tokyjp05.jp.bb.gin.ntt.net (2001:728:0:2000::85)  297.523 ms  297.033 ms  296.494 ms 
10  ae-2.r01.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:2000::206)  302.882 ms  301.637 ms  300.998 ms 
11  ge-0-7-0-18.r01.tokyjp01.jp.ce.gin.ntt.net (2001:218:2000:5000::82)  294.050 ms  293.501 ms  293.277 ms 
12  ve44.foundry6.otemachi.wide.ad.jp (2001:200:0:10::141)  285.159 ms  285.239 ms  284.193 ms 
13  2001:200:dff:fff1:216:3eff:feb1:44d7 (2001:200:dff:fff1:216:3eff:feb1:44d7)  287.541 ms [ouvert]  286.328 ms  285.843 ms

  1. c'est notre routeur;
  2. c'est la Freebox.

Tout est en ordre.

Conclusion

Tous laisse penser que l'utilisateur «résidentiel» disposera dans un avenir plus ou moins proche d'un nombre d'adresses IP publiques pouvant aller jusqu'à 268 réparties dans jusqu'à 16 sous réseaux de 264 adresses chacun.

En attendant, il faut continuer à maintenir les configurations IPv4 et leur parfois multiples translations d'adresses.

Le filtrage de paquets IPv6 n'a pas été abordé, mais il est bien sûr fonctionnel et se manipule avec la commande ip6tables qui est incluse dans le paquet iptables.