Christophe Nowicki

March 29, 2010

Migration d’un réseau Debian GNU/Linux vers IPv6 et au-delà …

Migration IPv6

C’était une tâche sur ma TODO liste depuis quelques années…
J’ai enfin franchi le pas et migré mon réseau vers IPv6.

Cette migration n’est pas encore évidente et j’ai rencontré quelques problèmes dont je voulais vous faire part dans ce billet.

L’objectif inavouable de cette migration était de rendre mon réfrigérateur directement accessible depuis le travail ;-)

Amis manchots, suivez- moi ;-)

Présentation d’IPv6

IPv6 c’est le futur ©, l’avenir du monde libre, c’est le monde de demain … puisqu’on vous le dit depuis 10ans^W^W!

Bref, je ne vais pas vous faire un long discours sur le sujet mais
plus simplement vous expliquer ce qui a réellement motivé ma migration.

Comme vous le savez sûrement, je m’intéresse un peu à la domotique et à la culture D.I.Y., ce qui m’a permis de découvrir quelques concepts sympathiques et connexe au domaine tels que :

  • Physical computing : l’intéraction entre un processeur et le monde physique ;
  • Ambient intelligence : L’Intelligence ambiante, la fonte de l’informatique dans nos objets de tous les jours ;
  • Internet of Things : L’Internet des objets, l’extension de l’Internet au monde réel.

Pour émerger, ces concepts ont tous besoin de la même chose : un nouveau protocole Internet permettant :

  • d’augmenter sensiblement le nombre d’adresses disponibles ;
  • des mécanismes de configuration automatique ;
  • la sécurité et de la mobilité.

Avec IPv6, il est possible de connecter :

Bref, cela permet d’ouvrir de nombreuses possibilités ;-)

Tunnel

Si votre fournisseur d’accès Internet ne met pas à votre disposition une collectivité IPv6 native, alors vous aurez besoin de mettre en place un tunnel 6to4.
Visiblement seuls Nerim et FDN offrent en France un collectivités IPv6 native.

IPv6 Tunnel Brocker

Pour obtenir un tunnel, il suffit d’ouvrir un compte chez Hurricane Electric (HE), vous devez suivre la procédure décrite avec des copies d’écran sur howto forge.

Fonctionnalités

HE vous fournit les services suivants :

  • Tunnel 6to4 ;
  • Deux sous-réseau IPv6 : /64 et /48 ;
  • Serveur DNS accessible en IPv4 et IPv6 ;
  • Résolution inverse DNS sur vos deux sous réseaux ;
  • Une certification de vos compétences IPv6 et du bon fonctionnement de votre reseau.

Un des gros avantage de HE est de vous fournir un sous-réseau /48 qu’il est possible de découper en plusieurs sous-réseau /64 en fonction de vos besoins : LAN, DMZ, Réseau de capteurs, etc…

Configuration du pare-feu Shorewall

DMZ avec un s

Comme la plupart des réseaux, j’utilise le principe de DMZ pour les services accessibles publiquement en IPv4.

Comme IPv6 me fournit beaucoup plus d’adresses publiques, il est possible de découper la route /48 fourni par HE en plusieurs DMZ.

Installation de Shorewall6

Pour la gestion du pare-feu, j’utilise les scriptes fournis par le projet Shorewall, qui facilite grandement l’écriture et l’organisation des règles.
Pour la gestion de l’IPv6, il est nécessaire d’utiliser une version spécifique : shorewall6.
Celle-ci est disponible dans les versions squeeze et sid de Debian, il est donc nécessaire de backporter le paquet.
Il suffit donc de backporter la version 4.4 de shorewall dans lenny :

# cd /usr/src
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall6/shorewall6_4.4.7.4-2.dsc
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall6/shorewall6_4.4.7.4.orig.tar.gz
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall6/shorewall6_4.4.7.4-2.diff.gz
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall/shorewall_4.4.7.5-1.dsc
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall/shorewall_4.4.7.5.orig.tar.gz
# wget http://ftp.de.debian.org/debian/pool/main/s/shorewall/shorewall_4.4.7.5-1.diff.gz
# dpkg-source -x shorewall6_4.4.7-2.dsc
# dpkg-source -x shorewall_4.4.7-1.dsc
# cd shorewall-4.4.7
# dpkg-buildpackage -b
...
# dpkg -i ../shorewall-common*
# dpkg -i ../shorewall-all*
# dpkg -i ../shorewall-shell*
# cd ../shorewall6-4.4.7
# dpkg-buildpackage -b
# dpkg -i ../shorewall6*.deb

Configuration du tunnel

Pour le tunnel 6to4, il est nécessaire de modifier le fichier /etc/shorewall/tunnels de Shorewall (IPv4) :
###############################################################################
#TYPE ZONE GATEWAY GATEWAY
6to4 net IP
#

Migration de la configuration

Vous devez ensuite migrer votre configuration de Shorewall IPv4 vers IPv6.
Pour cela vous pouvez vous aider avec les exemples fournis dans le /usr/share/doc/shorewall6/examples

La stratégie de filtrage est identique à celle en IPv4 : c’est à dire bloquer tous les services et ajouter des règles spécifiques pour autoriser des services. Il faut juste faire attention à l’ICMPv6 qui à un plus grand rôle dans le cas de IPv6.

Pour la configuration des fonctionnalités spécifiques à IPv6 dans Shorewall6, vous pouvez vous reporter directement à la documentation : Shorewall IPv6 Support

Configuration du DNS

Pour la configuration de mon serveur DNS, BIND prend en charge l’IPv6. J’ai donc créé une sous-zone v6.csquad.org pour les services uniquement accèssibles en IPv6 et attribués des addresses aux services publics existants :

$ grep AAAA /etc/bind/wan/db.csquad.org
        		AAAA    2001:470:c830::6
ns			AAAA	2001:470:c830::3
smtp			AAAA	2001:470:c830::10
www                      AAAA    2001:470:c830::6

Une sous-zone v6.csquad.org pour les services uniquement accessibles en IPv6:

$TTL    3600 ; 8 heures
@       IN      SOA ns.v6.csquad.org. hostmaster.csquad.org. (
                        2010031801      ; Serial
                                1D      ; Refresh
                                2H      ; Retry
                                6W      ; Expire
                         3600 ) ; Negative Cache TTL

                        NS      ns.v6.csquad.org.
                        A       82.247.220.114

ns              IN A 82.247.220.114

host             IN      AAAA    2042:42:42:42:42:42:42:42

La partie la plus difficile est la Zone inverse IPv6, car le contenu du fichier est très verbeux, et il est nécessaire de manipuler des adresses complexes à la main :

$TTL    3600 ; 8 heures
@       IN      SOA ns.v6.csquad.org. hostmaster.csquad.org. (
                        2010031602      ; Serial
                                1D      ; Refresh
                                2H      ; Retry
                                6W      ; Expire
                         3600 ) ; Negative Cache TTL

                        NS      ns.v6.csquad.org.

$ORIGIN 0.0.2.4.0.0.2.4.0.0.2.4.0.2.ip6.arpa.

2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4 IN PTR host.v6.csquad.org.

Pour vous aider, vous pouvez utiliser le programme ipv6calc :

$ ipv6calc --in ipv6addr --out revnibbles.arpa 2042:42:42:42:42:42:42:42
2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.0.2.4.0.2.ip6.arpa.

Vous pouvez tester le bon fonctionnement du DNS IPv6 à l’aide de la commande dig :
$ dig +short -t aaaa host.v6.csquad.org
2042:42:42:42:42:42:42:42

Le reverse :
$ dig +short -x 2042:42:42:42:42:42:42:42
host.v6.csquad.org.

Google et ses amis

De nombreux services Internet ne sont pas IPv6 ready out of the box et utilisent des sous-zones DNS pour leur services accèssibles en IPv6. Par example Google :
$ dig +short -t aaaa www.google.com
$ dig +short -t aaaa ipv6.google.com
ipv6.l.google.com.
2a00:1450:8001::63
2a00:1450:8001::67
2a00:1450:8001::68
2a00:1450:8001::69
2a00:1450:8001::6a
2a00:1450:8001::93

La commande ne retourne pas d’adresse IPv6, car google réserve cette réponse aux ISP/services qui disposent d’une connectivité IPv6 :
$ dig +short -t aaaa @212.27.32.176 google.com
$ dig +short -t aaaa @4.2.2.2 google.com

Pas de réponse via le DNS de Free et le DNS Public de Google.
Par contre, si j’interroge le DNS de Hurricane Electric (HE) :
$ dig +short -t aaaa @74.82.42.42 google.com
2a00:1450:8001::68
2a00:1450:8001::93
2a00:1450:8001::6a
2a00:1450:8001::67
2a00:1450:8001::69
2a00:1450:8001::63

Il faut donc modifier le fichier /etc/bind/named.conf.local pour forwarder la résolution de certains noms de domaine via le DNS de HE :

zone "google.com" {
        type forward;
        forwarders {
                  2001:470:20::2;
        };
};

D’habitude, je fais du Google bashing, mais je dois avouer que cette fois-ci Google est le seul à résoudre en IPv6.
Les autres “Grands Noms de l’Internet” , ne disposent pas d’une connectivité IPv6, parmi ceux-ci :

  • wikipedia ;
  • facebook ;
  • twitter ;
  • flickr ;
  • yahoo ;
  • slashdot ;
  • linuxfr.org ;

Bref, seul google est IPv6 friendly, les autres acteurs de l’internet sont à la traine.

Vous pouvez tester tous ses noms de domaines via cette page : IPv6 websites accesibility.

Configuration des machines

Autoconfiguration

Pour l’auto-configuration des machines, vous devez installer le paquet radvd :
# apt-get install radvd
Et modifier le fichier de configuration /etc/radvd.conf pour prendre en charge votre interface LAN avec votre prefix IPv6, comme cela :

interface eth1
{
        AdvSendAdvert on;
        MaxRtrAdvInterval 30;
        prefix 2042:42:42:42::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
                AdvValidLifetime 300;
                AdvPreferredLifetime 120;
        };
};

Ensuite vous devez relancer le daemon :
# /etc/init.d/radvd restart

Ensuite vous pouvez relancer l’interface réseau d’une machine et vérifier qu’elle à bien pris une adresse IPv6 :

# ip -f inet6 addr   | grep -B 1 global
4: eth0: <BROADCAST ,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000
    inet6 2042:42:42:42:42:42:42:2/64 scope global dynamic

Cette adresse IPv6 est produite à l’aide du prefix v6 et l’adresse MAC de votre carte réseau.

IP statique

Vous pouvez aussi attribuer une adresse IPv6 statique à l’aide du fichier /etc/network/interfaces :

auto eth0
iface eth0 inet static
        address 192.168.0.11
        netmask 255.255.255.0
        gateway 192.168.0.100

iface eth0 inet6 static
        address 2042:42:42:42::1
        netmask 64
        gateway 2042:42:42:42::100

Linux-VServer

La version de Linux VServer disponible dans Debian “lenny” dispose du support IPv6.

Il suffit d’ajouter l’adresse ip à l’interface et relancer le serveur :

# cd /etc/vservers/NOM_MACHINE/interfaces
# mkdir 1
# echo "eth0" > dev
# echo "2042:42:42:42:42:42:42:42/64" > ip
# echo "NOM_MACHINE" > name
# vserver NOM_MACHINE restart

Migration des services

Apache

Pour la configuration d’Apache, il suffit d’ajouter dans le fichier /etc/apache2/ports.conf, l’adresse de votre service :

Listen [2042:42:42:42:42:42:42:42]:80
Listen [2042:42:42:42:42:42:42:42]:443

Puis d’utiliser cette adrese dans un VirtualHost :

<VirtualHost  [2042:42:42:42:42:42:42:42]:80>
        ServerName host.v6.csquad.org
...

Messagerie

La configuration de Postfix en IPv6, ne pose aucun problème particulier. Il suffit d’ajouter des enregistrements DNS AAAA à votre serveur de messagerie :

                        MX      10 smtp
smtp                    AAAA    2001:470:c830::10

Et de modifier le fichier /etc/postfix/main.cf :

mynetworks = 127.0.0.0/8 [::1]/128 [2001:470:c830::]/48 [2001:470:1f13:299::]/64
inet_interfaces = [2001:470:c830::10]
inet_protocols = ipv4, ipv6

Ensuite, vous pourrez recevoir des mails de la part de [2001:41b8:202:deb:…] ;-)

CUPS

La configuration est identique à celle d’apache. Il suffit de modifier la directive Listen du fichier /etc/cups/cupsd.conf.

Samba

Je n’ai pas testé, mais visiblement depuis 2008, Samba dispose d’un support d’IPv6 qui est parfaitement inter-opérable avec les versions recentes de Microsoft Windows : Archive for the ‘Samba’ Category sur le blog de Erion Services.

Squid

Pour faire fonctionner le proxy mandataire Squid avec IPv6, il est nécessaire de mettre à jours la version disponible dans Debian “lenny”, vers la version 3.1.
La procédure de mise à jours est décrite dans ce billet : Squid 3.1 on Debian Lenny

Jabber

Pour mon serveur Jabber, j’utilise ejabberd. La migration consiste simplement à ajouter votre interface IPv6 dans le fichier /etc/ejabberd/ejabberd.cfg, comme cela :


{listen,
[
{5222, ejabberd_c2s, [
inet6,
{access, c2s},
{shaper, c2s_shaper},
{max_stanza_size, 65536},
starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
]},
...

Le plus dur est de trouver un serveur jabber compatible IPv6 poour faire du s2s.

Téléphonie

Il existe une version spécifique d’Asterisk pour IPv6.,mais elle n’a pas été intégrée dans la branche principale du projet et elle n’a pas l’air d’être maintenue activement.
Je vais donc me configurer OpenSER (alias Kamailio) pour faire office de proxy SIP IPv4/IPv6. (en cours ;-) )

Télévision

Je diffuse la télévision sur mon résau local avec MuMuDVB (j’ai décrit ma configuration dans ce billet : Diffuser des flux TV sur réseau local avec MuMuDVB). Celui-ci ne supporte pas IPv6.

Par contre VLC supporte très bien IPv6. Il est donc possible de transposer un flux IPv4 multicast vers un flux IPv6 multicast.

Les équipements

Le point noir dans cette migration vient des équipements embarqués qui disposent d’une connectivité IPv4 :

  • Switch manageable : aucun firmware disponible avec le support d’IPv6 ;
  • Télephones SIP : le SPA941 et le PAP2, ne disposent pas d’un firmware compatible IPv6 ;
  • Amplificateur Home-Cinema : idem ;
  • Imprimante : idem ;
  • RFXCOM : idem ;

Pas de surprises, l’ensemble des équipements IP ne disposent pas d’une connectivité IPv6, il faut chercher dans du matèriel très haut de gamme pour obtenir cette fonctionnalité.

Une solution possible est de rendre ses services accessibles en IPv6 à l’aide d’un reverse proxy 6to4 via Apache :

<VirtualHost [2042:42:42:22:42:42:42:42]:80>
   ServerName host.v6.domaine
   DocumentRoot /var/www
   ProxyPass / http://host.domaine/
   ProxyPassReverse / http://host.domaine/
</VirtualHost>

Mais cela ne fonctionne que pour les inferfaces HTTP de configuration et non pour tous les services fournir par ces équipements.

La seule bonne nouvelle pour les équipements et que la plupart disposent de la possiblité de mise à jours de leur firmware et donc ils seront un jour compatible ;-)

Sécurité

Kerberos Comme vos machines sont directement accessibles via Internet, il est nécessaire d’augmenter le niveau de sécurité du réseau. Pour ma part, j’ai déployé les éléments suivants :

  • Chiffrement TLS/SSL de TOUS les services, c’est le minimum syndical ;
  • Règles de Firewall strictes ;
  • Désactiver des services réseaux inutiles ;
  • Maintien à jours de l’ensemble des paquets ;

Et si vous êtes un peu paranoïaque, (comme moi ;-) ) vous pouvez encore ajouter quelques éléments de sécurité en plus :

  • Renforcer la sécurité du noyau et des services à l’aide de patches spécifiques ( grsecurity, Suhosin, etc…) ;
  • Mettre en place un NIDS comme Prelude ;
  • Mettre en place un HIDS comme SAMHAIN.

Bref, Comme les machines peuvent être directement accessibles et vous n’avez plus la “protection” du NAT. Il est nécessaire d’accorder plus d’importance à la sécurisation des vos serveurs.
Si non vous avez de fortes chances de vous retrouver dans ce cas : The brave new world of IPv6. (on me signale qu’il existe une très bonne protection ;-) )

Références

Conclusion

J’ai appris beaucoup de choses lors de cette migration.

Mon réseau dispose d’une connectivité IPv6 et je vais pouvoir m’amuser avec les nouvelles possiblités offertes ;-)

Powered by WordPress