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.

Ma configuration marche tellement bien que plusieurs personnes de mon entourage m’ont demandé des accès. Mais j’ai rapidement eu envie de surveiller la consommation relative à OpenVPN ainsi que les utilisateurs connectés à un instant T.

OpenVPN ne facilite pas vraiment la tâche pour récupérer des informations. Elles sont de plus très minimales. Deux moyens sont possibles : envoyer un signal SIGUSR2 au processus OpenVPN ou consulter le fichier défini par l’option status dans la configuration du serveur.

La solution la plus simple que j’ai trouvé est de réaliser un petit script qui parcourt le ou les fichiers de configuration d’OpenVPN (pour ma part deux instances fonctionnent donc j’ai deux fichiers à analyser). Ce script est écrit en Perl et génère une page HTML classique contenant un tableau avec des informations comme le nom de l’utilisateur, son adresse IP source, son adresse IP virtuelle, les quantités de données envoyées et reçues et enfin le temps de connexion.

Je l’utilise dans un cronjob qui réécrit la page en question toutes les minutes.

Pour l’utiliser :

openvpnstatus.pl fichier_log1 [fichier_log2...] > webpage.html

Il permet d’utiliser des en-têtes et pieds de page personnalisés. Il faut positionner les variables header et footer.

Voici le script openvpnstatus.pl.

Fille de Jacques Higelin et soeur d’Arthur H, l’artiste parcourt les scènes françaises depuis environ 2 ans, avec des dates impressionnantes comme une première partie d’Iggy Pop & The Stooges. Elle est à l’affiche des plus gros festivals cet été : Vieilles Charrues, Printemps de Bourges, Solidays, etc. Le cadre est posé.

Que dire de cet album, tant les qualificatifs manquent pour exprimer à quel point il est excellent. Du Janis Joplin version 2009, de la rage à en avoir des frissons, les titres s’enchaînent, chaque morceau est meilleur que le précédent. Et puis l’album repart, repart, repart…

Du rock comme on en a pas écouté depuis des lustres, au temps où la soupe commerciale inonde tous les médias.

Izia est sans aucun doute une artiste avec un grand avenir. Mais j’en ai déjà beaucoup trop dit. La meilleure chose à faire est d’acheter l’album…

Quelques liens utils :

• Son MySpace,
• Sa page Wikipédia.

Ayant activé l’IPv6 sur toutes mes machines et étant donné que la Freebox route tout le trafic IPv6 sur l’interne, je suis dans l’obligation de restreindre les accès en utilisant PF (en IPv4 je n’avais pas ce souci puisqu’elles étaient derrière du NAT).

Le problème avec NFS c’est que certains ports sont alloués de manière statique : nfsd sur le 2049 et le portmapper sur le 111, mais certains autres sont alloués dynamiquement : j’utilise bootparam et mountd pour ma part.

Il me fallait donc une solution pour détecter au démarrage de la machine les ports utilisés par ces services.

La solution que j’utilise est relativement simple. On suppose que PF tourne sur la machine avec un fichier pf.conf valide.

Le principe retenu est d’utiliser une ancre (PF anchor) placée dans les règles de filtrage :

anchor nfs

Ainsi au démarrage de la machine, PF sera démarré avec une ancre d’affectée, à cet instant vide.

Ensuite il reste à lancer mon script Perl permettant de découvrir les ports utilisés et peupler l’ancre PF à l’aide de la commande pfctl.

Pour ce faire, j’utilise le script de démarrage rc.local en ajoutant ceci avant le echo ‘.’ final :

# RPC script
if [ -x /home/scripts/rpcports.pl ] ; then
/home/scripts/rpcports.pl
echo -n ' rpcports.pl'
fi

Attention cependant, ce script s’appuie sur la sortie de la commande rpcinfo -p et se base sur les longueurs fixes des chaînes de caractères en sortie.

Pour finir, le script rpcports.pl en question.

La saison dernière, j’avais parlé de la station de Gérardmer, je propose maintenant quelques photos de La Bresse.

Les différentes études récentes montrent clairement que IPv6 est pour le moment très très peu utilisé (il représente 0.01% du trafic Internet IPv4) sans compter que les adresses IPv4 seront bientôt complètement épuisées.

Pour vérifier ces études je me suis donc décidé à passer ma connexion internet et les deux machines principales que j’utilise en IPv6.

Première étape, activer IPv6 sur ma freeboîte : connexion au portail free, activation de la fonctionnalité, récupération de mon subnet IPv6 et reboot de la freeboîte. Et la surprise : free ne donne qu’un /64.  Moi qui espérais me faire un subnet local, une dmz, un subnet pour le wifi, etc., ce ne sera pas en passant par chez free (oui, il existe des bidouilles pour faire du subnetting avec un masque plus grand que /64, mais ici pas question de bidouiller). Je n’exclus pas de passer par un tunnel broker dans le futur.

Je continue mes expérimentations. Mon poste de travail principal est sous OpenBSD. Tout est de base prévu pour IPv6. Il me faut récupérer une adresse. Pour ça on utilise la commande rtsol, qui correspond à l’auto-configuration stateless en IPv6 :

$ sudo sh -c 'echo "!/sbin/rtsol \\\$if" >> /etc/hostname.bge0'
$ sudo rtsol bge0
$ ifconfig bge0
bge0: flags=8843 mtu 1500
lladdr aa:aa:bb:bb:cc:cc
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet6 fe80::aaaa:bbbb:cccc:dddd%bge0 prefixlen 64 scopeid 0x1
inet 192.168.1.20 netmask 0xffffff00 broadcast 192.168.1.255
inet6 2a01:e35:xxxx:yyyy:aaaa:bbbb:cccc:dddd prefixlen 64 autoconf pltime 86381 vltime 86381

Pour le moment tout se passe bien. Un petit tour sur www.kame.net et miracle, la tortue bouge .

Maintenant, pour continuer à faire joujou, je me dis que ce serait intéressant de passer ma seconde machine (la blade 1500) en full IPv6. Je boot sur un ramdisk du dernier snapshot pour une netinstall. Je paramètre le réseau : pas d’IPv4, IPv6 avec rtsol.

Et là, problème… quels sont les serveurs DNS joignables en IPv6 ?!? Sur ma machine principale je continuais d’utiliser les DNS IPv4 de Free, qui me répondaient avec les enregistrements AAAA correspondants, mais ici, plus d’IPv4. Je dois donc trouver un moyen pour les récupérer, et comme je l’ai dit plus haut, la freeboîte ne donne pas d’adresse en utilisant DHCPv6, mais à l’aide de l’auto-configuration stateless.

La station envoie un message ICMPv6 router solicitation sur l’adresse multicast all routers (ff02::2) en scope Link-Local. Le routeur présent répond alors à la station par un message ICMPv6 router advertisement sur l’adresse multicast all nodes (ff02::1) toujours en scope Link-Local. Ces messages de réponse contiennent différentes options.

Une option appelée IPv6 Router Advertisement Option for DNS Configuration est apparue avec la RFC 5006 expérimentale sortie en 2007. Seulement cette option n’est supportée à ma connaissance pour le moment que par linux, et problème, c’est ce mécanisme que Free utilise pour annoncer ses serveurs DNS.

Comment alors récupérer mes DNS ? Facile !!! retour sur ma machine principale, tcpdump dans un terminal, rtsol dans un autre :

$ sudo tcpdump -n -i bge0 -s 1600 -X icmp6
tcpdump: listening on bge0, link-type EN10MB
23:56:13.087743 fe80::211:25ff:fed3:542c > ff02::2: icmp6: router solicitation
[...]

23:56:13.094789 fe80::207:cbff:feb1:aacd > ff02::1: icmp6: router advertisement
[...]
0060: 2a01 0e00 0000 0000 0000 0000 0000 0002 *...............
0070: 2a01 0e00 0000 0000 0000 0000 0000 0001 *...............
[...]

Les DNS sont donc 2a01:e00::1 et 2a01:e00::2. Ok, maintenant j’ai les DNS, je peux poursuivre l’install. Je suis chanceux, mes miroirs favoris en France ont une connectivité IPv6. L’installation se termine, je reboot, et hop, me voilà avec un OpenBSD tout frais en full IPv6.

Prochaine étape, récupérer les sources de -current. Et la autre problème, après pas mal d’interrogations DNS sur les différents dépôts CVS :

$ host -t AAAA foo.bar

Il se trouve qu’il n’y en a pour le moment qu’un seul en Europe accessible sur IPv6. Ça vaut donc le coup de le signaler :

anoncvs@anoncvs.netbsd.se:/cvs

Je récupère les sources, je recompile un -current tout propre, je redémarre et je commence la config. Je veux synchroniser ma machine avec OpenNTPD. J’ai l’habitude d’utiliser fr.pool.ntp.org. Mais encore une fois surprise, quand je regarde les logs, aucune machine n’est joignable en IPv6. Je recherche un peu sur le net : pool.ntp.org ne distribue actuellement aucun serveur en IPv6. Ils commencent tout juste en ce début 2009 à les répertorier… Je continue alors mes recherches et après pas mal de temps j’obtiens une liste de cinq serveurs accessibles. Je la partage ici pour les intéressés :

server ntp2.cines.fr
server ntp6.space.net
server ntp.pouf.org
server ntp.via.ecp.fr
server ntp6.bsdsx.fr

Je peux maintenant utiliser ma machine correctement. Je me lance alors à l’assaut du web en IPv6. Je savais que le web en IPv6 était triste mais à ce point… je l’aurais jamais imaginé : google s’y met seulement, pas de yahoo, pas de lefigaro.fr, pas de lemonde.fr, etc. Bref, 99% des sites sur lesquels j’ai l’habitude d’aller ne passent pas.

Petite réflexion personnelle : que l’on aime ou pas IPv6 et j’ai mon avis sur la question… le jour où l’on pourra abandonner IPv4 est encore bien loin. Quand on voit comment les FAI traînent les pieds pour fournir de l’IPv6 décent (natif avec au moins un /48), la faible proportion de ressources disponibles sur internet en IPv6 et la pénurie approchante d’adresses IPv4, on se dit que le futur va devenir assez hilarant.

Il est basé sur le port déjà existant d’OpenArena, mais comme je préfère le « vrai » ioquake3, j’ai fait un port séparé. La version d’ioquake3 est un checkout du svn officiel du 16 novembre 2008.

Pour jouer, il faut le CD officiel avec le pak0.pk3 ainsi que la point release 1.32 contenant les pak[1-8].pk3. Il faut placer ces fichiers soit dans $HOME/.q3a/baseq3, soit dans /var/local/share/ioquake3/baseq3.

Le port est disponible ici.

On peut également y observer cette Berlinette A110 qui fut championne du monde des rallyes en 1973, et remporta tous les rallyes en son temps dont de très nombreuses éditions du Rallye Monte Carlo.

D’autres modèles qui furent l’histoire de la marque sont présents comme respectivement cette Formule Renault A366 ou cette Formule 2.

Consultez les webcams des stations vosgiennes :

• La Bresse
• Gérardmer
• Ventron

« Signal Spam » est une association de loi 1901 qui regroupe la plupart des organisations françaises concernées par la lutte contre le spam, qu’il s’agisse des pouvoirs publics ou des professionnels de l’Internet. Elle a pour objet de fédérer les efforts de tous pour lutter contre le fléau du spam.

« Signal Spam » répond à cet objectif en offrant une plate-forme nationale de signalement des spams, en lien avec les autorités compétentes. En complément, le site Internet propose les informations nécessaires pour se prémunir et lutter contre le spam.

L’association « Signal Spam » a été créée en novembre 2005 grâce aux travaux de la plateforme de concertation publique-privée pilotée par la Direction du développement des médias.

Les objectifs de l’association sont les suivants :
« L’association a pour objet la lutte contre le « spam » (courrier électronique non sollicité illicite) et ses effets, auprès des utilisateurs et des professionnels, en France comme à l’international.

- La formulation de recommandations, prises après consultation et concertation des autorités compétentes, aux pouvoirs publics comme aux représentants des acteurs et utilisateurs du courrier électronique. »

Des plugins pour les principaux clients de messagerie ont été développés et permettent de signaler directement un spam, sans passer par le site. Ces plugins sont disponibles une fois enregistré sur le site. Deux types d’inscription sont disponibles. L’inscription simple permet de signaler des spams à l’association. L’inscription complète offre des fonctions avancées comme permettre à l’association de vous contacter pour donner légalement suite à un signalement.

Notons également que différents outils pour les développeurs et administrateurs sont disponibles (API, Script Python, Script Shell).