Offrez-vous une connectivité IPv6 Internet, LAN et DMZ pour 0 euro
En ces temps où toutes économies sont bonnes à prendre, je me suis attelé à mettre en place chez moi un « vrai » accès IPv6. Par vrai, je n’entends pas un accès natif (ce serait trop beau, aucun opérateur grand public français ne le propose à l’heure actuelle hormis Nerim dont l’offre est tout de même plus orientée vers les TPE), mais un accès offrant un espace d’adressage correct, ie. un /48.
Même Free qui propose de l’IPv6 à ses clients ne propose qu’un semblant d’accès natif, avec du 6rd mais il se limite à donner un /64.
Dans ce billet, je vais donc m’attacher à présenter les grandes lignes pour mettre en place à la maison (et même ailleurs) un accès IPv6 avec différents sous-réseaux, en utilisant un tunnel broker. Pour y arriver je présenterai des exemples de configuration pour une passerelle OpenBSD, ainsi que des astuces.
Tout d’abord, revenons sur quelques bases. Avec IPv4 il se pratique depuis de nombreuse années un routage ne se basant plus sur les classes avec CIDR (Classless Inter Domain Routing). Ceci est rendu possible par l’utilisation de masques réseau à taille variable (VLSM, Variable Length Subnet Masking). Avec IPv6, les masques disparaissent au profit de préfixes. Un préfixe IPv6 est l’équivalent d’un masque, qui permet de router un sous-réseau à travers internet. D’un point de vue routage, un préfixe a une taille maximale de 64 bits (une adresse IPv6 ayant une taille de 128 bits). Les opérateurs peuvent localement découper plus finement cet espace d’adressage, mais sur internet, les règles de routage seront communes au /64.
Ainsi, Free qui propose un /64 à ses clients, ne donne la possibilité d’adresser qu’un seul sous-réseau. Si vous souhaitez vous amuser avec les joies de l’IPv6 qui vous permet de posséder pour chaque machine une adresse publique routable, alors la solution de Free montre vite ses limites. Il vous sera en effet impossible (comme c’est également le cas de tous les autres FAIs grand public français) de segmenter votre réseau pour séparer vos clients de vos serveurs en mettant par exemple en place un LAN local, une DMZ, un accès Wifi, etc. le tout sur un espace d’adressage IPv6 public.
Mais comme sur internet on trouve de tout, il existe des « tunnel brokers » qui fournissent des points d’accès IPv6 un peu partout dans le monde. La technique est simple : depuis votre accès IPv4 natif, on va encapsuler jusqu’au point de présence du tunnel broker l’intégralité du trafic IPv6 sur de l’IPv4. Il y a quelques années, les points de présence étaient bien souvent situés aux États Unis ou assez loin géographiquement de l’Europe. Mais désormais, de nombreux tunnel brokers ont fait leur apparition proposant des services très intéressants comme :
- Une présence de proximité avec des points de présence en France et à travers l’Europe,
- Un sous-réseau IPv6 large : /48 ou plus,
- La délégation de la zone DNS de votre sous-réseau, vous permettant de personnaliser vos enregistrements PTR (pour les résolutions inverses),
- Des possibilités de peering BGP si vous disposez de votre AS.
Même si toutes ces fonctionnalités sont loin d’être indispensables pour un accès personnel… (c’est le moins que l’on puisse dire 😉 ), les deux premières sont très alléchantes. Chez moi, j’ai choisi d’utiliser Hurricane Electric (HE). Il propose l’ensemble des services ci-dessus, pour la très modique somme de 0 euros…
La première étape est bien évidemment de s’inscrire sur le site, puis de créer un tunnel (en choisissant le point d’accès le plus proche de chez sois). Ce tunnel, comme je le disais précédemment consiste à encapsuler sur votre passerelle, tout le trafic IPv6 dans de l’IPv4. Pour cela, il faudra donc établir une lisaison point à point IPv4 entre votre passerelle et l’autre bout du tunnel chez HE. Une fois celui-ci créé depuis l’interface web du site, HE vous indique alors les différents paramètres d’accès.
- Client IPv4 address : l’adresse IPv4 de votre bout du tunnel (l’adresse fournie par votre opérateur),
- Server IPv4 address : l’adresse IPv4 de l’autre bout du tunnel (chez HE),
- Client IPv6 address : l’adresse IPv6 publique que vous assigne HE,
- Server IPv6 address : l’adresse IPv6 faisant office de passerelle chez HE (liaison point à point).
Ces paramètres, vous l’aurez compris, vont vous permettre de monter le tunnel vers le point d’accès HE. Sous OpenBSD, ce tunnel se concrétisera par une interface virtuelle gif(4). Elle se configure très simplement en ligne de commande (remplacez évidemment les adresses par celles fournies par HE) :
$ sudo ifconfig gif0 tunnel <client_ipv4> <server_ipv4>
$ sudo ifconfig gif0 inet6 alias <client_ipv6> <server_ipv6> prefixlen 128
$ sudo route -n add -inet6 default <server_ipv6>
Et pour automatiquement monter le tunnel au démarrage, par un fichier « /etc/hostname.gif0 » :
tunnel <client_ipv4> <server_ipv4>
inet6 <client_ipv6> 128 <server_ipv6>
! /sbin/route add -inet6 default <server_ipv6>
Lorsque le tunnel est monté sur votre passerelle, cela signifie qu’il est fonctionnel et que la passerelle dispose maintenant d’un accès public IPv6. A noter que si vous souhaitez filtrer finement les flux du tunnel avec PF (ce qui est plus que recommandé), des lignes similaires (à adapter en fonction de votre config) permettront d’autoriser le tunnel sur votre interface physique en IPv4 (l’interface gif0 verra le trafic IPv6 non encapsulé, comme s’il venait d’une connexion native) :
pass in on $ext_if proto ipv6 from $server_ipv4 to $ext_if
pass out on $ext_if proto ipv6 from $ext_if to $server_ipv4
Pour le moment, nous disposons simplement d’un accès IPv6 sur la passerelle. Pour votre réseau interne, par défaut, HE vous propose un sous-réseau /64 routé. Mais comme je l’expliquais en début de l’article, c’est insuffisant dans notre cas car nous souhaitons un /48 pour pouvoir le fractionner et le router sur internet. Il sera donc nécessaire de demander l’assignation d’un /48 routé. Cette opération ne prend que quelques secondes et s’effectue en un clique sur l’interface de gestion de votre compte HE.
Ce /48 se présente sous la forme xxxx:yyyy:zzzz::/48. C’est ce sous-réseau que nous allons fractionner. Ainsi on peut imaginer :
- xxxx:yyyy:zzzz:1::/64 : réseau local LAN,
- xxxx:yyyy:zzzz:2::/64 : DMZ hébergeant nos serveurs,
- xxxx:yyyy:zzzz:3::/64 : réseau Wifi personnel (si vous prenez le risque d’utiliser IPv6 sur du wifi…),
- etc.
Une adresse de ces sous-réseaux est à assigner à chaque interface de la passerelle, dans un fichier « /etc/hostname.if » approprié. Si vous souhaitez bénéficier de l’autoconfiguration « stateless », rtadvd(8) est fait pour vous. Par exemple, si vous souhaitez configurer vos machines du LAN local, ajoutez cette ligne au fichier « /etc/rtadvd.conf » (remplacer « if » par l’interface sur laquelle vous souhaitez activer l’autoconfiguration) :
if:\
:addr="xxxx:yyyy:zzzz:1::":prefixlen#64:
Ensuite vous pouvez activer définitivement rtadvd en ajoutant cette ligne dans le fichier « /etc/rc.conf.local » (remplacer « if » par l’interface sur laquelle vous souhaitez activer l’autoconfiguration) :
rtadvd_flags="if"
Selon le trafic que vous souhaitez autoriser sur votre passerelle avec PF, il faut noter qu’IPv6 n’utilise pas le protocole ARP d’IPv4 pour faire la résolution entre adresse MAC et adresse IP sur un segment réseau. Il utilise au contraire une nouvelle fonctionnalité apportée par ICMPv6 (version d’ICMP pour IPv6) qui est la découverte du voisinage (ND, Neighbor Discovery). Ce mécanisme repose sur deux types de paquets :
- La machine souhaitant communiquer avec une autre envoie un paquet de type « Neighbor solicitation » (icmp6-type neighbrsol dans PF),
- La machine concernée répond par un paquet de type « Neighbor advertisement » (icmp-type neighbradv dans PF).
Il faudra donc absolument autoriser ces paquets pour que les machines puissent communiquer. Des règles PF peuvent ainsi être :
pass in on gif0 inet6 proto icmp6 icmp6-type neighbrsol
Ici on autorise juste le paquet neighbrsol : le paquet neighbradv retourné par l’autre machine sera autorisé par l’état créé par le premier paquet.
De même que si vous utilisez rtadvd et que vous souhaitez effectuer un filtrage fin, il faudra autoriser les paquets du mécanisme de découverte de routeur. Le principe :
- Le client envoie un paquet « Router solicitation » (icmp6-type routersol dans PF),
- Le routeur répond par un paquet « Router advertisement » (icmp6-type routeradv dans PF).
Les règles peuvent ainsi être :
pass in on $int_if inet6 proto icmp6 icmp6-type routersol
De la même façon que pour le mécanisme de ND présenté précédemment, la réponse routeradv est automatiquement acceptée par PF, un état étant créé par le premier paquet.
Il faut également noter qu’avec IPv6, filtrer l’ICMP est très délicat. La bonne pratique avec IPv4 est de ne pas le bloquer. Mais pour IPv6, plus qu’une bonne pratique c’est également une règle pour éviter d’aller vers de gros problèmes. Le meilleur exemple est le « Path MTU Discovery » (PMTU) qui se base sur les paquets ICMP « Packet too big ».
Enfin, le dernier point à aborder, le FTP. C’est souvent le protocole qui pose problème. OpenBSD offre un outil très utile pour automatiquement gérer les connexions de donnée avec PF : ftp-proxy(8). En IPv4 le fonctionnement est assez naturel, mais avec IPv6 il y a quelques particularités à prendre en compte. Prenons comme exemple un server FTP hébergé dans notre DMZ, que nous souhaitons rendre accessible en IPv6 depuis l’extérieur.
La page de manuel indique que lorsque ftp-proxy fonctionne en IPv6, l’adresse par défaut sur laquelle il écoute est ::1 (équivalent de 127.0.0.1 pour IPv6). Or, un bug rend impossible les redirections IPv6 vers ::1. Il faudra donc rediriger avec PF le trafic sur une adresse globale, et non sur le localhost. Par exemple :
anchor "ftp-proxy/*"
pass in quick inet6 proto tcp to port ftp rdr-to $client_ipv6 port 8021
Ensuite, lorsque l’on démarre ftp-proxy, il faut lui passer les bons arguments pour qu’il écoute sur l’adresse en question et redirige le trafic sur notre serveur FTP :
$ sudo /usr/sbin/ftp-proxy -6 -b <client_ipv6> -R <ftp_server>
Pour conclure cet article, il faut bien garder à l’esprit que les extraits de configuration dont je parle sont uniquement là pour améliorer la compréhension. Ils doivent être finement adaptés selon votre configuration, vos buts et la topologie de votre réseau.