Tout ceci est bien amusant, mais comment exploiter au mieux ce monde IPv6 sur son LAN, car IPv6 ne se suffit pas à lui-même pour l'instant. Les ressources IPv6 sont encore trop rares sur le vaste internet, et l'usage d'IPv4 est encore largement nécessaire ;

1. Comment les choses peuvent-elles se passer si l'on fait cohabiter sur le même hôte une pile IPv4 et une pile IPv6 ?

1. Je n'ai qu'une IPv4 publique et 2⁶⁴ IPv6 globales. Comment gérer ça sur mon LAN ?

1. Je voudrais bien utiliser l'auto-configuration. Je n'ai donc pas besoin de DHCPv6 ?

1. Mais si j'ai bien compris, il faut 64 bits pour le jeton si je veux faire de l'auto-configuration. Comme le préfixe fourni par Free et un préfixe de 64 bits, 64+64=128, je ne peux donc pas créer de sous-résaux, malgré mes 2⁶⁴ adresses possibles ?

1. Si je ne peux créer de sous-réseaux, je ne peux utiliser un routeur IPv6 entre ma Freebox et mon LAN ?

Les réponses apportées ici ont été développées à une époque déjà reculée, avec une Freebox v4 configurée en «bridge» mais tout ceci reste d'actualité si l'on continue à utiliser sa Freebox dans ce mode. La Freebox V6 (révolution) apporte quelques suppléments intéressants dont la possibilité d'utiliser jusqu'à 8 sous-réseaux /64 et donc de pouvoir utiliser un routeur IPv6 personnel. L'intérêt n'est évident que pour les bricoleurs fous, à priori. Le jour où il sera nécessaire de connecter 2⁶⁷ nœuds sur son réseau personnel, il faudra peut-être reconsidérer la question. Dans un contexte de réseau d'entreprise, en revanche la possibilité devient bien intéressante.

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)

Nous l'avons déjà évoqué, ce tunnel permet de passer de l'IPv6 dans de l'IPv4, de façon quasi transparente, nous n'en sommes pas encore à un internet «full-ipv6».

La conséquence de cette méthode n'est pas si évidente que ça, mais elle mérite d'être assimilée correctement : la Freebox, même placée en mode «bridge», ce qui est effectif pour l'IPv4 reste tout de même en mode «routeur» pour l'IPv6. Elle continue en effet de maintenir le bout du tunnel 6rd.

Nous avons donc une «chose» qui agit comme un pont en IPv4, mais comme un routeur en IPv6.

C'est tout à fait possible. Depuis déjà pas mal de temps GNU/Linux installe par défaut les deux piles, et c'est IPv6 qui est prioritaire. Nous pourrons vérifier que, dans le cas où une ressource de l'internet dispose d'une adresse IPv6 et d'une adresse IPv4, c'est IPv6 qui sera employé.

Maintenant, il reste le problème qu'en IPv4, je n'ai qu'une seule adresse publique à ma disposition pour tout mon LAN et je dois donc obligatoirement faire du NAT. Je sais faire, ce n'est pas un problème pour moi de monter un routeur NAT avec IPTables. En revanche, j'ai bien compris que mes configurations IPv6 vont se faire à partir des informations que le routeur IPv6 (dont je n'ai pas du tout la maîtrise) m'envoie via des messages ICMPv6. Un «switch» ? pourquoi pas, mais alors, adieu IPv4 qui a besoin d'un routeur.

Il faudrait que mon «machin à deux pattes» que je place entre ma Freebox et le switch de mon LAN agisse comme un routeur NAT pour IPv4 et soit un pont pour IPv6. Exactement l'inverse de ce que fait la Freebox. Un petit dessin ?

Nous avons de la chance, GNU/Linux sait parfaitement faire le pont et sait donc résoudre notre problème, à la condition que nous soyons capables de lui expliquer qu'il ne doit le faire que pour les trames Ethernet qui transportent de l'IPv6 et surtout pas de l'IPv4, il n'y aurait plus de routage NAT IPv4 sinon.

Avec un bon modem ADSL tout simple et un petit PC avec deux interfaces Ethernet, nous pourrions sans doute réaliser le bout du tunnel 6rd et obtenir la connectivité IPv4 et IPv6 en se passant de la Freebox. Pour la téléphonie et le multimédia, ce serait une autre paire de manches. Donc dans le contexte «passerelle résidentielle», nous conserverons la Freebox, d'autant que nous verrons ce qu'apporte la «Révolution».

Ce n'est pas une nouveauté. Nous disposons d'un réseau local, par exemple 192.168.0.0/24, avec son DHCP, son DNS cache et son routeur NAT, qui dispose d'une interface dans notre réseau local (par exemple 192.168.0.1) et une autre patte dans le réseau du fournisseur d'accès (par exemple 82.243.80.13).

Pour que tout ceci fonctionne en harmonie, Netfilter fait du masquage d'adresse, il faut écrire plein de règles IPtables bien senties, ce qui permet d'en profiter pour que notre routeur serve aussi de pare-feu.

Si nous désirons abriter un serveur dans notre LAN, qui soit visible depuis l'internet, c'est un peu plus compliqué. Il faut faire sur le routeur du « prerouting » C'est-à-dire qu'il va falloir, toujours avec Netfilter/IPTables, indiquer que les requêtes entrant sur le routeur par le port qui correspond au service que nous voulons exposer (par exemple le port 80 pour http) devra être redirigé vers l'adresse IP locale de notre serveur sur le LAN. Il ne faut pas être manchot de l'iptables, mais ça se fait assez bien.

Bien entendu, ce genre d'ouverture augmente considérablement les risques d'intrusion sur votre LAN et il vaudrait mieux dans un tel cas disposer d'un routeur NAT à trois pattes, avec une DMZ pour y placer les machines exposées. Ceci complique encore un peu la configuration Netfilter/IPTables, mais ça reste toujours réalisable si l'on est un artiste du filtrage.

Lorsque nous utilisons sur les stations de notre LAN des applications qui sont à la fois client et serveur (ceci peut arriver dans certains protocoles apparentés au « peer to peer »), la configuration IPtables peut alors devenir à la fois un casse-tête et une passoire.

Mais comme le haut débit existe déjà depuis le début du siècle, nous avons largement eu le temps de nous familiariser avec toutes ces subtilités.

De ceci, nous avons moins l'habitude et il convient peut-être ici de faire un point sur cette nouvelle situation.

Toutes les stations de notre LAN vont avoir une adresse IPv6 publique. Plus besoin de NAT, plus besoin de « PREROUTING » tout ceci est terminé. Chacune de nos stations sera désormais directement accessible (sauf précautions particulières) depuis l'internet.

Si nous disposons d'un nom de domaine, il sera relativement facile de configurer un DNS capable de résoudre publiquement les adresses de tous nos hôtes locaux. Nous allons enfin pouvoir jouer comme les grands.

Oui mais, et la sécurité dans tout ça ? Jouer comme les grands c'est bien, mais il faut en avoir les compétences. La gestion de la sécurité devra se faire à plusieurs niveaux, chacun des hôtes du réseau local (qui n'est par le fait plus du tout un réseau local, mais bel et bien un morceau de l'internet) devra faire l'objet d'une attention toute particulière.

Iptables a son équivalent IPv6 et se nomme de façon originale : ip6tables, qui nous permettra de réaliser notre filtrage en IPv6, de façon tout à fait analogue à ce que nous savons faire en IPv4.

Réaliser une telle chose n'étant pas courante, nous allons détailler quelque peu. La station que nous avons connectée à notre « Freebox » est maintenant munie de deux interfaces :

• eth0 est sur la Freebox ;
• eth1 est connectée à un switch qui accueillera les hôtes de notre « LAN ».

C'est cette station qui va jouer le rôle de «machin ».

Machin reçoit pour eth0 une IPv4 et une IPv6 de la part de notre fournisseur :

~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          inet adr:82.243.80.13  Bcast:82.243.80.255  Masque:255.255.255.0
          adr inet6: 2a01:5d8:52f3:500d:205:5dff:fedf:fe35/64 Scope:Global
          adr inet6: fe80::205:5dff:fedf:fe35/64 Scope:Lien
...

C'est bien, mais dans un premier temps, nous voulons juste en faire un pont Ethernet tout simple.

Nous sommes sur une Debian « testing ». Il nous faut les paquets :

• bridge-utils.
  Description : « Utilities for configuring the Linux Ethernet bridge This package contains utilities for configuring the Linux Ethernet bridge in Linux 2.4 or later. The Linux Ethernet bridge can be used for connecting multiple Ethernet devices together. The connecting is fully transparent: hosts connected to one Ethernet device see hosts connected to the other Ethernet devices directly. »
  Le pont Ethernet de Linux peut être utilisé pour connecter plusieurs interfaces Ethernet ensemble. La connexion est complètement transparente : les hôtes connectés à une interface voient directement les hôtes connextés aux autres interfaces ;

• ebtables.
  Description : Ethernet bridge frame table administration Ebtables is used to set up, maintain, and inspect the tables of Ethernet frame rules in the Linux kernel. It is analogous to iptables, but operates at the MAC layer rather than the IP layer.
  Ebtales est à la couche Ethernet ce qu'iptables est à la couche IP.

Un aptitude install bridge-utils ebtables fera l'affaire.

Bon gros avertissement…

Toute la manipulation qui suit est faite localement sur le machin. Si vous devez la faire à distance, voyez d'abord cette page de mise en garde sur les pertes de contrôle IP. Vous voilà prévenus.

Pour bien comprendre à quel point IP n'est pas nécessaire pour le bon fonctionnement d'un pont Ethernet, nous allons nous passer de toute configuration IP.

~# ifdown eth0
Internet Systems Consortium DHCP Client V3.1.0
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:05:5d:df:fe:35
Sending on   LPF/eth0/00:05:5d:df:fe:35
Sending on   Socket/fallback
DHCPRELEASE on eth0 to 82.243.80.254 port 67

Puis, nous activons eth0 et eth1, mais sans les configurer :

~# ifconfig eth0 up
~# ifconfig eth1 up
~# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          adr inet6: fe80::205:5dff:fedf:fe35/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...
eth1      Link encap:Ethernet  HWaddr 00:05:5d:e1:f7:ac  
          adr inet6: fe80::205:5dff:fee1:f7ac/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

Nous n'avons sur nos deux interfaces qu'une adresse IPv6 de type lien local. Nous allons maintenant utiliser brctl pour construire le pont :

~# brctl addbr br0
~# brctl addif br0 eth0
~# brctl addif br0 eth1

~# ts2b7:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.00055ddffe35	no		eth0
							eth1

Nous avons bien un pont br0. Un pont, ça dispose au moins de deux bouts, ils sont ici eth0 et eth1. Si tout se passe comme nous le souhaitons, les paquets ethernet devraient passer ce pont selon les règles en usage sur ce type d'équipement.

Nous allons maintenant activer ce pont :

ifconfig br0 up

Vérifions la configuration IP de tout ceci :

~# ifconfig
br0       Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          adr inet6: fe80::205:5dff:fedf:fe35/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

eth0      Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          adr inet6: fe80::205:5dff:fedf:fe35/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

eth1      Link encap:Ethernet  HWaddr 00:05:5d:e1:f7:ac  
          adr inet6: fe80::205:5dff:fee1:f7ac/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

Nous n'avons que des IPv6 lien local. Notez que br0 apparaît comme une interface à part entière, avec l'adresse MAC de l'interface eth0. Pour qu'il n'y ait absolument aucune ambigüité dans cette manip, nous allons jusqu'à supprimer ces adresses IPv6 locales :

~# ip -6 addr del fe80::205:5dff:fedf:fe35/64 dev br0
~# ip -6 addr del fe80::205:5dff:fedf:fe35/64 dev eth0
~# ip -6 addr del fe80::205:5dff:fee1:f7ac/64 dev eth1

Ce qui nous donne maintenant :

~# ifconfig
br0       Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

eth0      Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

eth1      Link encap:Ethernet  HWaddr 00:05:5d:e1:f7:ac  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

Plus aucune trace d'IP, v4 comme v6.

Il suffit de passer le pont
C'est tout de suite l'aventure
Laisse-moi tenir ton jupon
J't'emmèn' visiter la nature…

Bref, nous démarrons la station. Une station toute simple, avec une distribution Ubuntu des familles. Sitôt fini le démarrage, empressons-nous de consulter la configuration réseau :

~$ ifconfig
eth0      Lien encap:Ethernet  HWaddr 00:0C:6E:AD:B6:99  
          inet adr:82.243.80.13  Bcast:82.243.80.255  Masque:255.255.255.0
          adr inet6: 2a01:5d8:52f3:500d:20c:6eff:fead:b699/64 Scope:Global
          adr inet6: fe80::20c:6eff:fead:b699/64 Scope:Lien
...

Ca marche, nous avons notre IPv4 publique et aussi nos deux IPv6. Si nous avons une IPv4 publique sur eth0 c'est bien que la couche IPv4 de notre station n'a pas « vu » le « machin » non ?

Voyons la table de routage IPv4 :

~$ route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
82.243.80.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         82.243.80.254   0.0.0.0         UG    100    0        0 eth0

Ça se confirme, pour IPv4, le « machin » n'intervient pas dans les routes.

Et les routes IPv6 ?

~$ route -A inet6
Table de routage IPv6 du noyau
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
::1/128                                     ::                                      U     0      4        1 lo      
2a01:5d8:52f3:500d:20c:6eff:fead:b699/128   ::                                      U     0      152       1 lo      
2a01:5d8:52f3:500d::/64                     ::                                      UA    256    0        0 eth0    
fe80::20c:6eff:fead:b699/128                ::                                      U     0      3        1 lo      
fe80::/64                                   ::                                      U     256    0        0 eth0    
ff00::/8                                    ::                                      U     256    0        0 eth0    
::/0                                        fe80::207:cbff:fe1f:f5a                 UGDA  1024   74       0 eth0    

Là encore, le « machin » n'est pas visible.

Un petit traceroute IPv4 vers www.kame.net ?

~$ sudo traceroute www.kame.net
traceroute to www.kame.net (203.178.141.194), 64 hops max, 40 byte packets
 1  82.243.80.254 (82.243.80.254)  37 ms  37 ms  37 ms
 2  213.228.20.254 (213.228.20.254)  44 ms *  37 ms
...
23  orange.kame.net (203.178.141.194)  308 ms  308 ms  308 ms

Le « hop » 1 est bien la passerelle par défaut du fournisseur d'accès. Il n'y a plus de doutes à avoir pour IPv4.

Et pour ipV6 ?

~/.ssh$ sudo traceroute6 www.kame.net
traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2a01:5d8:52f3:500d:20c:6eff:fead:b699, 30 hops max, 16 byte packets
 1  2a01:5d8:52f3:500d::1 (2a01:5d8:52f3:500d::1)  1.549 ms  0.594 ms  0.575 ms
 2  2a01:5d8:e000:9d1::4 (2a01:5d8:e000:9d1::4)  51.501 ms  48.268 ms  48.146 ms
...
24  orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085)  336.759 ms  337.563 ms  336.053 ms

Là encore, le « hop » 1 correspond bien à la passerelle du fournisseur. Plus de doutes non plus pour IPv6.

Nous avons rempli la première partie du contrat, le « Machin » est complètement invisible, aussi bien en IPv4 qu'en IPv6. L'est-il aussi au niveau Ethernet ? Des ponts, il y en a plein les switch et ces derniers sont bien invisibles au niveau Ethernet. Vérifions tout de même.

Un 'tit coup de rdisc6 :

~$ 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   :         1800 (0x00000708) secondes
Temps d'atteinte          :  non indiqué (0x00000000)
Temps de retransmission   :  non indiqué (0x00000000)
 Préfixe                  : 2a01:5d8:52f3:500d::/64
  Durée de validité       :        86400 (0x00015180) secondes
  Durée de préférence     :        86400 (0x00015180) secondes
 Recursive DNS server     : 2a01:5d8:e0ff::2
 Recursive DNS server     : 2a01:5d8:e0ff::1
  DNS servers lifetime    :          600 (0x00000258) secondes
 MTU                      :         1480 octets (valide)
 Adresse source de lien   : 00:07:CB:1F:0F:5A
 de fe80::207:cbff:fe1f:f5a

OK, le routeur IPv6 habituel.

~$ ping6 -c 3 fe80::207:cbff:fe1f:f5a%eth0
PING fe80::207:cbff:fe1f:f5a%eth0(fe80::207:cbff:fe1f:f5a) 56 data bytes
64 bytes from fe80::207:cbff:fe1f:f5a: icmp_seq=1 ttl=64 time=1.73 ms
64 bytes from fe80::207:cbff:fe1f:f5a: icmp_seq=2 ttl=64 time=0.701 ms
64 bytes from fe80::207:cbff:fe1f:f5a: icmp_seq=3 ttl=64 time=0.699 ms

--- fe80::207:cbff:fe1f:f5a%eth0 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.699/1.044/1.732/0.486 ms

~$ ip -6 neigh show
fe80::207:cbff:fe1f:f5a dev eth0 lladdr 00:07:cb:1f:0f:5a router DELAY

Le voisinage, c'est bien le routeur du fournisseur d'accès et pas notre pont, preuve que c'est un pont

Nous allons maintenant réaliser un pont qui ne fonctionnera que pour IPv6. Mais avant, prenons quelques précautions, car il n'y aura plus de connectivité IPv4 pour notre station de travail.

DNS Free (IPv4) :

option domain-name-servers 212.27.54.252,212.27.53.252;

(information prise dans les logs du client dhcp).

Commençons par couper le pont IPv4 au moyen d'ebtables :

~# ebtables -t broute -A BROUTING -p ! ipv6 -j DROP

A ce niveau, notre station de travail ne dispose plus d'IPv4. Il nous faut maintenant configurer le « machin » en routeur NAT IPv4. C'est une formalité.

Bien que notre IPv4 soit fixe, la configuration est tout de même récupérée par DHCP :

~# dhclient eth0
Internet Systems Consortium DHCP Client V3.1.0
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:05:5d:df:fe:35
Sending on   LPF/eth0/00:05:5d:df:fe:35
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPOFFER from 82.243.80.254
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 82.243.80.254
bound to  82.243.80.13 -- renewal in 604800 seconds.

Nous allons nous faire un petit 192.168.254.0/24 pour changer un peu de la routine:

~# ip addr add 192.168.254.1/24 dev eth1

Nous faisons du NAT sur tout ce qui sort par eth0 :

~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

(Ne pas oublier ce détail, si l'on souhaite garder sa chevelure intacte…)

echo 1 > /proc/sys/net/ipv4/ip_forward

~# ifconfig
br0       Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

eth0      Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          inet adr:82.243.80.13  Bcast:82.243.80.255  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

eth1      Link encap:Ethernet  HWaddr 00:05:5d:e1:f7:ac  
          inet adr:192.168.254.1  Bcast:0.0.0.0  Masque:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
...

Tout à l'air normal.

~# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
82.243.80.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         82.243.80.254   0.0.0.0         UG    0      0        0 eth0

Tout à l'air normal aussi. Notre routeur NAT IPv4 devrait être opérationnel

Commençons par désactiver eth0

:~$ sudo ifdown eth0

Réactivation de eth0, mais sans configuration :

:~$ sudo ifconfig eth0 up

Ajout d'une adresse IPv4 compatible avec celle que nous avons mis sur eth1 du « Machin » :

~$ sudo ip addr add 192.168.254.2/24 dev eth0

Ajout d'une route par défaut qui pointe sur « Machin » :

~$ sudo ip route add default via 192.168.254.1 dev eth0

Vérifications d'usage :

:~$ route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.254.1   0.0.0.0         UG    0      0        0 eth0

Si nous désirons être efficaces, il faut maintenant renseigner le système sur les DNS à consulter pour la résolution des noms. Editons /etc/resolv.conf pour qu'il ressemble à ceci :

~$ cat /etc/resolv.conf
nameserver 212.27.54.252
nameserver 212.27.53.252

Et voyons si ça roule :

~$ ping -c 1 www.kame.net
PING www.kame.net (203.178.141.194) 56(84) bytes of data.
64 bytes from orange.kame.net (203.178.141.194): icmp_seq=1 ttl=43 time=313 ms

--- www.kame.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 313.359/313.359/313.359/0.000 ms


~$ ping6 -c 1 www.kame.net
PING www.kame.net(orange.kame.net) 56 data bytes
64 bytes from orange.kame.net: icmp_seq=1 ttl=47 time=340 ms

--- www.kame.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 340.627/340.627/340.627/0.000 ms

Ça roule. En IPv4 comme en IPv6, nous pouvons faire ping sur la tortue. Je vous laisse vérifier par vous-même, avec des traceroute biens sentis, que le « Machin » est vu comme un routeur en IPv4 et comme rien du tout en IPv6.

Bien entendu, il reste quelques opérations cosmétiques à réaliser :

• faire un peu de filtrage sanitaire en IPv4 sur le Machin ;
• installer un DNS cache pour que nos clients du LAN n'aient pas à connaître les DNS du fournisseur d'accès ;
• installer un DHCP sur le LAN pour que nos clients se configurent automatiquement en IPv4 ;
• et surtout, automatiser tout ça pour que nous ne soyons pas obligé de ressortir nos notes au prochain reboot du Machin.

Les trois premiers points, voilà longtemps que nous savons faire. Voyons plutôt comment automatiser la configuration du Machin.

La suite s'adresse principalement aux (heureux) utilisateurs de Debian et dérivées. En effet la configuration du réseau est assez particulière sur ces distributions et très différente de la façon de faire sur les « Red-Hat like » ou autres « Slackware / Gentoo / Suse like ».

Debian utilise un fichier /etc/network/interfaces et plusieurs répertoires contenant des scripts à exécuter en « pre-up, up, down et post-down ». Le paquet « bridge-utils » a déjà installé les scripts /etc/network/if-pre-up.d/bridge et /etc/network/if-post-down.d/bridge aux-quels il est inutile et même déconseillé de toucher. Tout va pouvoir se faire à partir du fichier /etc/network/interfaces :

auto br0
iface br0 inet manual
        bridge_ports eth0 eth1
        bridge_maxwait 0
        pre-up ebtables -t broute -A BROUTING -p ! ipv6 -j DROP
        down ebtables -t broute -F

auto eth0
iface eth0 inet dhcp
	up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
	down iptables -t nat -F

auto eth1
iface eth1 inet static
 address 192.168.254.1
 netmask 255.255.255.0

1. iface br0 inet manual indique que l'interface br0 sera configurée par les scripts ifupdown ;
2. bridge_ports eth0 eth1 et bridge_maxwait 0 sont des directives qui seront utilisées par ces scripts pour configurer le pont ;
3. pre-up ebtables -t broute -A BROUTING -p ! ipv6 -j DROP (fondamental) permettra d'interdire le pont au trafic IPv4, lorsque le pont est activé ;
4. down ebtables -t broute -F remettra les choses à plat en ce qui concerne les tables du pont lorsque ce dernier est désactivé.

Ce n'est pas dans mes habitudes, mais si vous souhaitez avoir plus d'informations sur les directives de configuration des interfaces réseau sous Debian, je vous dirai man interfaces (Lorsque l'on veut jouer avec IPv6, il faut savoir donner de sa personne).

En ce qui concerne l'interface eth0, la ligne up iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE est tout à fait minimaliste, nous sommes là pour vérifier que ça fonctionne. Dans la pratique, il faudra ici invoquer un script qui écrive de vraies règles de filtrage IPv4.

De même, il faudra éventuellement réfléchir à des règles ebtables et IP6tables pour protéger au moins notre machin contre d'éventuelles attaques IPv6.

Voyons la configuration IP des divers composants :

~# ifconfig
br0       Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          adr inet6: 2a01:5d8:52f3:500d:205:5dff:fedf:fe35/64 Scope:Global
          adr inet6: fe80::205:5dff:fedf:fe35/64 Scope:Lien
...

eth0      Link encap:Ethernet  HWaddr 00:05:5d:df:fe:35  
          inet adr::82.243.80.13  Bcast::82.243.80.255  Masque:255.255.255.0
          adr inet6: fe80::205:5dff:fedf:fe35/64 Scope:Lien
...

eth1      Link encap:Ethernet  HWaddr 00:05:5d:e1:f7:ac  
          inet adr:192.168.254.1  Bcast:192.168.254.255  Masque:255.255.255.0
          adr inet6: fe80::205:5dff:fee1:f7ac/64 Scope:Lien
...

L'adresse globale IPv6 sur br0 n'est pas fondamentale si le machin ne doit pas lui-même accéder à l'internet par IPv6. Eth0 et eth1 disposent de leurs adresses IPv4 convenablement, les adresses IPv6 sont totalement inutiles ici, mais ne sont pas gênantes.

Les routes IPv4 :

~# ip route ls
82.243.80.0/24 dev eth0  proto kernel  scope link  src 82.243.80.13 
192.168.254.0/24 dev eth1  proto kernel  scope link  src 192.168.254.1 
default via 82.243.80.254 dev eth0 

Tout ceci est parfait. Les routes IPv6 maintenant :

~# ip -6 route ls
2a01:5d8:52f3:500d::/64 dev br0  proto kernel  metric 256  expires 85974sec mtu 1480 advmss 1420 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  expires 21332903sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth1  metric 256  expires 21332903sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev br0  metric 256  expires 21332903sec mtu 1480 advmss 1420 hoplimit 4294967295
default via fe80::207:cbff:fe1f:f5a dev br0  proto kernel  metric 1024  expires 1369sec mtu 1480 advmss 1440 hoplimit 64

Notez encore une fois que ceci n'est pas nécessaire si le machin ne doit pas lui-même accéder à l'internet en IPv6.

Vérification des « ebtables » :

~# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 1, policy: ACCEPT
-p ! IPv6 -j DROP 

C'est bon.

Et IPtables (IPv4) ?

~# iptables-save
# Generated by iptables-save v1.4.0 on Tue May  6 14:59:45 2008
*nat
:PREROUTING ACCEPT [738:380896]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [127:9544]
-A POSTROUTING -o eth0 -j MASQUERADE

Impeccable.

Attention toutefois, un ifdown br0 fera tomber toutes les interfaces et pas seulement br0. Il faudrait sans doute étudier le script /etc/network/if-post-down.d/bridge du paquetage bridge-utils ou créer un script /etc/network/if-down.d/bridge spécifique pour améliorer ce comportement.