Partenaires

CNRS

Rechercher

Sur ce site

Sur le Web du CNRS


Accueil du site > Expériences > Délégation Régionale Aquitaine-Limousin > Mise en place d’IPv6 à la Délégation du CNRS

Mise en place d’IPv6 à la Délégation du CNRS

par Roland Dirlewanger - 8 mai 2006

Sommaire




Introduction

Réaumur, le réseau du campus universitaire de Talence, Pessac, Gradignan a officiellement ouvert le service IPv6 au lendemain du séminaire RAISIN du 27 avril 2006 consacré à la présentation d'IPv6 par Jean-Denis Portelli.

A la Délegation du CNRS, nous avons souhaité nous inscrire dans la démarche de déploiement d'IPv6 sur le campus. Nous avons demandé et obtenu une adresse IPv6 routable dès le 28 avril. Le système d'exploitation de notre commutateur-routeur ne disposant pas actuellement de pile IPv6, nous avons donc utilisé une machine Linux Fedora Core 4 multi-interfaces déjà existante et configurée en routeur filtrant IPv4.

Dans cet article, nous présentons les différentes opérations qui ont abouti à la mise en place d'IPv6 pour le serveur de messagerie et DNS et le serveur WWW. L'article s'articule autour de deux parties. La première décrit l'architecture physique et logique visée ainsi que les modifications de la configuration de la machine Linux pour en faire un routeur filtrant IPv6.

La deuxième partie décrit la mise en place d'IPv6 sur nos serveurs de messagerie, DNS et WWW. Le lecteur qui n'administre pas de routeur et pour lequel le service IPv6 est fourni par le réseau de campus pour passer directement à cette partie.

1. Mise en place d'un routeur filtrant IPv6

1.1 Architecture physique

Le réseau physique du réseau de la Délégation s'articule autour d'un commutateur 10/100/1000 de niveau 2 et 3. Plusieurs VLAN sont configurés sur ce routeur. Les deux principaux sont le réseau principal de la Délégation et le réseau d'hébergement de services aux laboratoires. La Délégation dispose de deux accès vers l'extérieur : Réaumur pour le trafic IP généraliste, SIres pour le trafic IP lié au système d'information du CNRS. Le routage inter-VLAN est effectué par la couche 3 du commutateur.




La figure ci-dessus représente l'architecture physique du réseau. Afin de ne pas surcharger inutilement le schéma, la pile de commutateurs et la liaison interétage ont été omises.

Pour la mise en place d'IPv6, seule l'interface eth2 de la machine Linux a été connectée, les deux autres étant déjà fonctionnelles.

1.2 Architecture logique IPv6

La figure ci-dessous montre l'architecture logique cible visée pour IPv6. Afin de ne pas surcharger inutilement le schéma, les adresses et les éléments actifs IPv4 ont été omis. De même, seuls les serveurs de messagerie, DNS et WWW concernés par la migration IPv6 ont été représentés




L'interface eth1 est l'interface de sortie vers le réseau Réaumur. L'interface eth2 est configurée en lien « trunk » pour accéder à tous les VLAN du réseau. Le paquetage vconfig sera utilisé pour configurer autant d'interfaces virtuelles qu'il y a de VLAN.

1.3 Configuration du routeur filtrant IPv6

1.3.1 Les ip6tables

On peut raisonnablement supposer que le risque d'intrusion via le protocole IPv6 est infime aujourd'hui.Néanmoins, les règles les plus élémentaires de prudence recommandent que l'on mette en place le filtrage avant même de commencer à configurer le routage sur les diverses interface de la machine.

Nous avons implémenté une politique de sécurité basée sur le principe que « tout ce qui n'est pas explicitement autorisé est interdit ». Nous n'autorisons donc que le trafic de ICMPv6, les connexions TCP sortantes et les connexions TCP destinées au serveurs de messagerie, DNS et mél.

Le fichier /etc/sysconfig/ip6tables contient les lignes suivantes :

*filter
:FORWARD DROP [14:1275]
:INPUT DROP [0:0]
:OUTPUT ACCEPT [700:60680]
-A FORWARD -s ::1/128 -d ::/0 -j DROP
-A FORWARD -s ::/0 -d ::/0 -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A FORWARD -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
-A FORWARD -s 2001:660:6101:20::/59 -d ::/0 -o eth1 -j ACCEPT
-A FORWARD -s 2001:660:6101:21::/64 -d ::/0 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:21::1/128 -p tcp -m tcp --dport 25 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:21::1/128 -p tcp -m tcp --dport 53 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:21::1/128 -p udp -m udp --dport 53 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:21::2/128 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:21::2/128 -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:23::1/128 -p tcp -m tcp --dport 25 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:23::1/128 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:23::1/128 -p tcp -m tcp --dport 110 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:23::1/128 -p tcp -m tcp --dport 143 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:23::1/128 -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:23::1/128 -p tcp -m tcp --dport 993 -j ACCEPT
-A FORWARD -s ::/0 -d 2001:660:6101:23::1/128 -p tcp -m tcp --dport 995 -j ACCEPT
-A FORWARD -s ::/0 -d ::/0 -j LOG
-A INPUT -s ::1/128 -d ::/0 -j DROP
-A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A INPUT -s 2001:660:6101:21::/64 -d ::/0 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -j LOG
COMMIT



Il est chargé par la commande « ip6tables-restore < /etc/sysconfig/ip6tables ».

1.3.2 La route par défaut

La route par défaut est définie dans le fichier /etc/sysconfig/network. On y indique également le le fait que la machine va être configurée en tant que routeur et qu'elle ne fait pas d'autoconfiguration.

# configuration IPv4
NETWORKING=yes
...

# configuration IPv6
NETWORKING_IPV6=yes
IPV6_DEFAULTGW=2001:660:6101:20:FF::0
IPV6_DEFAULTDEV=eth1
IPV6FORWARDING=yes
IPV6_AUTOCONF=no

1.3.3 Les interfaces

Au départ du projet, il était prévu d'utiliser pour IPv6 les deux interfaces actives, eth0 et eth1, déjà configurées pour IPv4. Or, l'interface eth0 est utilisée en mode « pont » pour OpenVPN. Lors de la création du pont (interface bridge br0), les scripts de configuration d'OpenVPN gèrent correctement l'adresse IPv4 mais ne gèrent pas ou gèrent mal l'adresse IPv6. Pour cette raison, il a été décidé de n'utiliser ni l'interface eth0, ni l'interface br0 pour IPv6.

L'interface eth1 est utilisée simultanément par la pile IPv4 et IPv6. Elle est configurée via le fichier /etc/sysconfig/network-scripts/ifcfg-eth1 de la façon suivante :

DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet

# Configuration IPv4
...

# Configuration IPv6
IPV6INIT=yes
IPV6ADDR=2001:660:6101:20:FF::1/64
IPV6_AUTOCONF=no
IPV6_ROUTER=yes



Pour prendre en compte les modifications, on relance la couche réseau de la machine par la commande « service network restart ». Dès cet instant, il est possible de communiquer avec le routeur de Réaumur par la commande « ping6 2001:660:6101:20:FF::0 ».

# ping6 -n 2001:660:6101:20:FF::
PING 2001:660:6101:20:FF::(2001:660:6101:20:ff::) 56 data bytes
64 bytes from 2001:660:6101:20:ff::: icmp_seq=0 ttl=64 time=2.22 ms
64 bytes from 2001:660:6101:20:ff::: icmp_seq=1 ttl=64 time=0.501 ms
64 bytes from 2001:660:6101:20:ff::: icmp_seq=2 ttl=64 time=0.560 ms



Un « ping6 » vers des machines extérieures au réseau Réaumur fonctionne également :

# ping6 -n www.ipv6.bieringer.de
PING www.ipv6.bieringer.de(2001:7b0:1101:1::37:6) 56 data bytes
64 bytes from 2001:7b0:1101:1::37:6: icmp_seq=0 ttl=52 time=54.3 ms
64 bytes from 2001:7b0:1101:1::37:6: icmp_seq=1 ttl=52 time=51.9 ms
64 bytes from 2001:7b0:1101:1::37:6: icmp_seq=2 ttl=52 time=49.0 ms



L'interface eth2 est configurée en mode « trunk » et gère actuellement deux VLAN (72 et 111). Cette configuration nécessite l'utilisation du paquetage RPM vconfig. L'interface eth2 est configurée via le fichier /etc/sysconfig/network-scripts/ifcfg-eth2 de la façon suivante :

DEVICE=eth2
ONBOOT=yes
TYPE=Ethernet



L'interface dans chaque VLAN est configurée dans un fichier /etc/sysconfig/network-scripts/ifcfg-eth2.no_du_VLAN. Le fichier ifcfg-eth2.72 contient :

DEVICE=eth2.72
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
VLAN=yes

# Configuration IPv6
IPV6INIT=yes
IPV6ADDR=2001:660:6101:21:FF::1/64
IPV6_AUTOCONF=no
IPV6_ROUTER=yes



Le fichier ifcfg-eth2.111 contient :

DEVICE=eth2.111
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
VLAN=yes

# Configuration IPv6
IPV6INIT=yes
IPV6ADDR=2001:660:6101:23:FF::1/64
IPV6_AUTOCONF=no
IPV6_ROUTER=yes

1.3.4 L'autoconfiguration

Le service « radvd » permet à une machine Linux de publier sur les divers réseaux auxquels elle est raccordée le préfix IPv6 de chacun d'eux et une route par défaut. Pour mettre en oeuvre ce service, il faut installer le paquetage RPM radvd et créer son fichier de configuration. Nous avons utilisé le fichier /etc/radvd.conf suivant :

interface eth2.72
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix 2001:660:6101:21::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};

};

interface eth2.111
{
AdvSendAdvert on;
MinRtrAdvInterval 30;
MaxRtrAdvInterval 100;
prefix 2001:660:6101:23::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};



Le service démarre par la commande « service radvd start ». Notez que lorsque vous aurez lancé votre commande, toutes les machines Linux avec un noyau récent obtiendront une adresse IPv6 routable. Spontanément, un serveur DNS commencera à émettre des requêtes en IPv6 et un serveur de messagerie transmettra des messages en IPv6. Il est donc prudent de vérifier depuis un tel client que le routeur est correctement installé. On peut par exemple tenter d'accéder à http://ipv6.reaumur.fr qui indiquera si la communication a eu lieu en IPv6 ou en IPv4.

2. La configuration des serveurs

2.1 Le serveur DNS et le serveur de messagerie

Le serveur camus.dr15.cnrs.fr est le serveur DNS et le serveur de messagerie pour la Délégation. Grâce à l'autoconfiguration d'IPv6, il a acquis une adresse IPv6. En observant le trafic sur son interface Ethernet, nous avons pu constaté qu'il émettait des requêtes DNS en IPv6 vers les serveurs de certains domaines.

Il est recommandé d'utiliser pour les serveurs des adresses simples et donc, de désactiver l'autoconfiguration. Pour ce faire, le fichier /etc/sysconfig/network a été modifié comme suit :

# Configuration IPv4
NETWORKING=yes
...

# Configuration IPv6
NETWORKING_IPV6=yes
IPV6_DEFAULTGW=2001:660:6101:21:FF::1



Le fichier /etc/sysconfig/network-scripts/ifcgf-eth0 a été modifié comme suit :

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static

# Configuration IPv4
...

# Configuration IPv6
IPV6INIT=yes
IPV6ADDR=2001:660:6101:21::1/64
IPV6_AUTOCONF=no



Le service réseau a été relancé par la commande « service network restart ». La configuration a été vérifiée par un « ping6 ipv6.reaumur.net ».

# ping6 ipv6.reaumur.net
PING ipv6.reaumur.net(2001:660:6101:1::10) 56 data bytes
64 bytes from 2001:660:6101:1::10: icmp_seq=0 ttl=62 time=1.42 ms
64 bytes from 2001:660:6101:1::10: icmp_seq=1 ttl=62 time=0.508 ms
64 bytes from 2001:660:6101:1::10: icmp_seq=2 ttl=62 time=0.432 ms



A ce moment de l'installation vient la question de la déclaration de l'adresse IPv6 pour camus. Au niveau de la messagerie, il est prudent d'effectuer quelques tests pour savoir si le serveur SMTP va, d'une part, correctement relayer les messages des clients IPv6 du réseau de la Délégation sans leur appliquer les listes grises et, d'autre part, accepter les messages des serveurs IPv6 externes. Nous avons donc opté pour créer une entrée camus-ipv6 avec un enregistrement AAAA dans la zone dr15.cnrs.fr.

La même stratégie a été employée pour le serveur WWW et le routeur. En revanche, pour la machine loti, l'enregistrement AAAA a été directement ajouté à l'entrée existante. Les enregistrements suivants ont donc été créés dans la zone dr15.cnrs.fr :

camus-ipv6   IN AAAA    2001:660:6101:21::1
kafka-ipv6 IN AAAA 2001:660:6101:21::2
loti IN AAAA 2001:660:6101:21::81
ionesco-ipv6 IN AAAA 2001:660:6101:21:FF::1



Par ailleurs, nous avons mis en place il y a quelques semaines les recommandations visant à configurer les serveurs DNS afin qu'il ne soient pas des relais ouverts. Le fichier named.conf du DNS a donc dû être modifié comme suit afin d'autoriser les requêtes et la récursion à partir de notre plage d'adresse IPv6 :

options {
...
allow-recursion {
...
::1/128; /* adresse locale IPv6 */
2001:660:6101:20::/59; /* réseaux IPv6 de la DR */
};
allow-query {
...
::1/128; /* adresse locale IPv6 */
2001:660:6101:20::/59; /* réseaux IPv6 de la DR */
};
};



La zone pour la déclaration inverse a été créée. Elle porte le doux nom de « 1.2.0.0.1.0.1.6.0.6.6.0.1.0.0.2.ip6.arpa ». Il n'est pas très facile de le taper sans erreur. La commande « dig -x 2001:660:6101:21::1 » s'est avérée très précieuse. Elle renvoie les 32 chiffres séparés par des points qui composent l'adresse. Les 16 premiers correspondent à l'adresse inverse de la machine dans la zone, les 16 suivants et le suffixe ip6.arpa correspond au nom de la zone. Le contenu de la zone est donc le suivant :

$TTL    172800
@ IN SOA camus.dr15.cnrs.fr. rd.dr15.cnrs.fr. (
2006050202
21600
3600
3600000
3600)

IN NS camus.dr15.cnrs.fr.
IN NS bxnms.u-bordeaux.fr.

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR camus-ipv6.dr15.cnrs.fr.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR kafka-ipv6.dr15.cnrs.fr.
1.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR loti.dr15.cnrs.fr.
1.0.0.0.0.0.0.0.0.0.0.0.f.f.0.0 IN PTR ionesco-ipv6.dr15.cnrs.fr.



Des tests avec la commande « dig -x » suivie des trois adresses IPv6 ci-dessus ont permis de valider les modifications.

La configuration du client de messagerie sur loti (Thunderbird/Linux Fedora Core 4) a été modifiée afin d'utiliser camus-ipv6 comme serveur IMAP et comme serveur SMTP. Aucun dysfonctionnement n'a été observé : postfix, le serveur SMTP, et dovecot, le serveur IMAP/POP3 configurent par défaut l'écoute sur l'adresse IPv6.

Après 24h de fonctionnement, l'entrée camus-ipv6 a été supprimée de la zone dr15.cnrs.fr et l'enregistrement AAAA correspondant a été rajouté à l'entrée camus.

2.2 Le serveur WWW

Le serveur WWW est Apache 2.0. La configuration est très dépendante de chaque site. En pratique, les seules modifications à apporter dans le fichier de configuration concernent les serveurs virtuels par nom. C'est une fonctionnalité que nous utilisons, donc les modification ci-dessous se sont avérées nécessaires.

Dans le fichier /etc/httpd/conf/httpd.conf, la ligne suivante a été ajoutée :

NameVirtualHost [2001:660:6101:21::2]:80



Ensuite, pour chaque serveur virtuel par nom, son adresse IPv6 entre crochets suivie du numéro de port on été rajoutés :

<VirtualHost 147.210.72.200:80 [2001:660:6101:21::2]:80>
...
</VirtualHost>



Rappelons qu'à cette étape, l'adresse IPv6 est associée à kafka-ipv6.dr15.cnrs.fr et non pas à kafka.dr15.cnrs.fr. En outre, tous les aliases (enregistrement CNAME du DNS) des serveurs virtuels par nom poitent vers kafka. Il est donc difficile de tester la solution avec un navigateur. Nous avons donc utilisé la commande « wget » de la façon suivante pour chacun des serveurs virtuels :

wget -O /tmp/out --header="Host: www.serveur.virtuel.fr" http://kafka-ipv6.dr15.cnrs.fr/



Une visualisation par la commande « more » a montré que les résultats étaient ceux attendus. Après 24h de fonctionnement, l'entrée kafka-ipv6 a été supprimée de la zone dr15.cnrs.fr et l'enregistrement AAAA correspondant a été rajouté à l'entrée kafka.

Conclusion

Notre objectif était de migrer la messagerie et le WWW vers IPv6. Cette opération s'est avérée relativement simple. Par effet de bord, d'autres services ont fonctionné spontanément avec IPv6, comme ssh.

Quelques correctifs mineurs ont néanmoins été nécessaires dans les routeurs de Réaumur, notamment le fait que Linux utilise dans certains cas l'adresse lien local pour la découverte de voisins alors que seules les adresses globales étaient autorisées par le routeur de Réaumur. Ce type de problème a été pris en charge par Réaumur et résolu immédiatement.

De même, quelques ajustements dans des autorisations dépendant d'adresses IP comme l'accès à l'interface de gestion de SPIP ont été apportés également. Le problème qui a fait perdre le plus de temps (5 heures !) est l'incompatibilité documentée nulle part entre le mode « bridge » d'OpenVPN et IPv6 sur la même interface.

L'impression générale qui résulte de cette installation est que le fonctionnement est quasi-immédiat et sans surprise. Nous encourageons les entités de Réaumur et notamment les laboratoires à mettre en place IPv6 sur leurs serveurs.

Références

En complément de la présentation de Jean-Denis Portelli, les sites WWW suivant ont été consultés. Je remercie les auteurs de ces sites pour l'aide très précieuse qu'ils m'ont apportée :



Dans la même rubrique :