IPv6 global sur son LAN

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 rares sur le vaste internet, et l'usage d'IPv4 est encore le plus souvent 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 264 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 264 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 ?

Voilà beaucoup de questions auxquelles il faudra répondre pour résoudre le problème.

IPv4 et IPv6 ensemble

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 depuis longtemps, ce n'est pas un problème pour moi, un routeur NAT avec IPTables, je maîtrise parfaitement. 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îrise) 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 transparent pour IPv6. Un petit dessin ?

machin ipv4 + ipv6

Le moyen simple pour que notre « machin » soit transparent au niveau IP est qu'il traite les paquets sur la couche inférieure, à savoir la couche Ethernet. Ce sont les ponts qui savent faire ce genre de choses.

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. Nous verrons que GNU/Linux sait faire un pont intelligent.

IPv4 par routage NAT

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.

IPv6 par pontage Ethernet

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

Avantages

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.

Inconvénients

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.

Un pont avec GNU/Linux

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

topologie de la manip

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.

Les outils nécessaires

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.

Construire le pont

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.

Passer le pont

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.

Vérifications de routine

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

Couper les ponts IPv4

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

Sur le « machin »

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

une IPv4 dynamique pour eth0

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.

Une IPv4 fixe pour eth1

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

Un masquerade pour eth0

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

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

Activer le routage

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

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

Vérifications

~# 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

Sur la station de travail

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.

Fignolage

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.

Automatiser le 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.

Quelques vérifications

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.

Dernière modification: le 18/12/2011 à 20:25
   
 
Cette création est mise à disposition sous un contrat Creative Commons. Creative Commons License