Je propose dans cet article une manière efficace et rapide de corriger cela sur une passerelle OpenBSD à l’aide de quelques règles PF en utilisant une première approche avec le moteur de priorisation ALTQ et la nouvelle souplesse des règles match depuis la version 4.6, puis en utilisant le nouveau moteur de priorisation intégré disponible à partir de la version 5.1.

1. Détail du problème

Lorsque l’on télécharge un fichier en utilisant le protocole TCP, les données que nous recevons sont contenues dans des paquets TCP ayant des données « utiles ». Selon le fonctionnement du protocole TCP, nous devons acquitter au fur et à mesure les données reçues, en envoyant au serveur des paquets TCP vides, mais acquittant de la réception des données (ces paquets contiennent le drapeau ACK). Lorsque nous envoyons un fichier sur internet, c’est le mécanisme inverse qui se produit : la machine recevant notre fichier nous envoie des paquets d’acquittement. Pour plus de détails, lire la RFC 793.

Si à un moment donné, les paquets d’acquittement sont ralentis ou perdus, alors le trafic est ralenti puisque la machine envoyant les données, doit attendre voir ré-émettre les données : car les paquets auront été acquittés tardivement ou pas du tout. Avec les connexions ADSL, fortement asymétriques, que nous avons aujourd’hui, on voit aisément le problème qui peut survenir : si nous lançons sur notre connexion internet, plusieurs envois/réceptions de fichiers simultanés, il est facile de saturer notre débit d’émission. Ce qui a pour effet de ralentir l’émission des paquets d’acquittement pour les fichiers que l’on télécharge, et donc de ralentir la vitesse de téléchargement de nos fichiers.

2. Solution A

Le filtre de paquets PF d’OpenBSD possède depuis longtemps un moteur très souple, ALTQ, permettant de prioriser les flux suivant différents algorithmes et paramètres. Sa configuration est détaillée dans la page de manuel pf.conf(5). Nous ne détaillerons pas sa syntaxe, juste les quelques règles qui nous intéressent. Voyons tout d’abord comment créer une queue permettant de prioriser les paquets. Ajoutons cette section au fichier /etc/pf.conf :

ext_if = vr3
altq on $ext_if priq bandwidth 920Kb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)

Ici nous avons créé une macro ext_if, nommant notre interface externe vr3 sur laquelle nous allons prioriser nos paquets. Puis, nous créons une queue mère sur l’interface $ext_if en utilisant l’algorithme priq (simple algorithme de priorité). Cette queue mère se voit affecter 820Kb et deux queues filles : q_pri ayant une priorité élevée de 7 et q_def la queue par défaut ayant une priorité plus basse de 1.

L’algorithme priq est le plus simple présent dans ALTQ : on affecte une priorité différente aux sous-queues (de 0 à 15), les paquets de la queue ayant la priorité la plus élevée sont traités en premier.

Dans la déclaration de la queue mère, j’ai réservé 920Kb de bande passante. Ma connexion internet synchronise à environ 6Mb en réception et 1Mb en émission. Avec l’encapsulation IPoA chez Free, j’ai un débit effectif d’environ 920Kb. Je vous conseille de faire quelques essais : si vous ne réservez pas assez de bande passante, la priorisation sera inefficace, et si vous réservez trop de débit, vous allez brider inutilement votre connexion.

Une fois les queues déclarées, passons maintenant à leur affectation dans nos règles de filtrage. J’écrivais précédemment que depuis OpenBSD 4.6, une nouvelle façon de filtrer est apparue avec le mot clé match. En effet, depuis cette version, de profonds changements structurels ont été apportés à PF, résultant en une bien meilleure souplesse d’écriture. Le mot clé ‘match’ permet ainsi de « matcher » certains flux pour modifier leur filtrage à la volée, sans arrêter leur évaluation dans le fichier de règles : c’est à dire sans modifier l’action finale block ou pass.

Alors que précédemment, l’affectation des queues ALTQ aux flux se faisait à chaque règle de filtrage, il est maintenant possible d’affecter nos queues par une simple règle match au début des règles de filtrage :
match on $ext_if inet proto tcp queue (q_def, q_pri)

Ainsi, toutes les connexions TCP sur l’interface externe $ext_if se verront affecter nos deux queues : q_def et q_pri. L’évaluation des règles continuera ensuite normalement.

Notons que l’ordre dans lequel nous avons mis les deux queues est indispensable. La première queue précisée dans la règle match est la queue par défaut : q_def. Si nous précisons une deuxième queue (c’est ce que nous avons fait), q_pri, alors PF lui affecte automatiquement les paquets ayant l’option IP ToS positionnée à « nodelay » ainsi que les paquets TCP sans charge utile ayant le drapeau ACK. C’est exactement le comportement que nous recherchons : nos acquittements TCP seront ainsi priorisés par rapport aux autres paquets et nous diminuerons les risques de ralentissement.

3. Solution B

La solution précédente relativement simple, peut être encore beaucoup plus simplifiée, depuis OpenBSD 5.1. En effet, de gros travaux sont en cours pour intégrer totalement à PF les fonctionnalités de ALTQ. Aujourd’hui, ALTQ peut être très pénalisant en terme de performance et sa complexité rend difficile son évolution.

Ainsi, le mot-clé prio est apparu, permettant à chaque règle d’affecter une priorité au trafic visé. Ce nouveau système de priorisation peut être combiné avec les règles match. Ainsi, les quelques lignes précédentes avec ALTQ peuvent être simplifiées en :
match on $ext_if inet proto tcp prio (2, 5)

Ici, plus besoin de déclaration de queues et d’algorithme. Nous affectons une priorité 2 au trafic normal et une priorité 5 aux paquets ayant un champ IP TOS nodelay, ou les paquets TCP ACK sans donnée utile.

A noter qu’en utilisant ce nouveau mécanisme de priorisation, nous avons à notre disponibilité 8 queues (priorité de 0 à 7. De plus, certains trafics sont automatiquement priorisés :

• Les priorités des VLAN sont héritées,
• Le trafic CARP est priorisé.

Attention : la syntaxe est sujette à évolution, puisque l’intégration des autres parties de ALTQ est en cours.

4. Illustration

Voici maintenant en pratique le résultat. Le premier graphe correspond à notre politique de filtrage sans ALTQ, le second avec ALTQ.

Dans ce premier graphe, les trois premières minutes consistent à télécharger quelques fichiers. Ensuite, je lance une émission de fichier simultanée aux téléchargements durant les quatre minutes suivantes. On peut voir que non seulement la réception de mes fichiers (en vert) est perturbée par rapport à la première partie du graphe, mais également l’émission de mon fichier qui n’utilise pas les 1Mb de bande passante disponible.

Dans ce second graphe, les deux premières minutes correspondent à plusieurs téléchargements de fichiers. Puis, je lance une émission de fichier durant quatre minutes. On peut voir que ALTQ fait correctement son travail : la réception de mes fichiers n’est absolument pas perturbée par l’émission de mon autre fichier qui se fait en utilisant au maximum les 1Mb de capacité d’émission de mon lien internet.

Le protocole L2TP (Layer 2 Tunneling Protocol) est un protocole de tunneling à la popularité grandissante, car supporté nativement par de nombreux OS : Windows, MacOS X, Linux, etc. mais également par les plate-formes mobiles populaires que sont Android et iOS. De plus, L2TP permet aisément de réaliser des VPN au dessus d’infrastructures existantes puisqu’il est transporté dans des paquets IP/UDP sur le port 1701. Dans la suite du document, nous allons utiliser le nouveau daemon npppd(8), inclus dans le système de base d’OpenBSD.

Afin de rendre le VPN plus sûr, la méthode est de chiffrer le trafic L2TP dans un tunnel IPsec. Ici rien de bien nouveau, nous nous reposerons sur l’extrême simplicité de configuration offerte par OpenBSD.

Un petit HOWTO est disponible avec les sources du ‘daemon’ npppd(8) que nous allons utiliser à cette adresse. Seulement, cet exemple de configuration ne s’intéresse qu’au cas générique et ne peut pas être repris tel quel dans certains scénarios.

1. Eléments d’architecture

Mon opérateur internet est Free. J’utilise une Freebox Revolution (v6) en mode routeur afin d’utiliser toutes les fonctionnalités multimedia qu’elle offre. Il faut donc noter que ma passerelle VPN possède une adresse IPv4 privée (192.168.0.1) sur le réseau interne de ma Freebox. Il ne faut donc pas oublier de configurer la Freebox pour rediriger le trafic IPsec et L2TP (chiffré avec IPsec) sur la passerelle VPN, en utilisant une IP « DMZ » dans l’interface de configuration de la Freebox.

Note : Les simples redirections de ports ne fonctionnent pas, car il faut non seulement rediriger le trafic UDP sur les ports 500 et 4500 (pour respectivement les protocoles ISAKMP et NAT-Traversal concernant la gestion de clés) mais également le trafic ESP (Encap Security Payload), qui a le numéro de protocole IP n°50 ; et qui concerne nos données utiles chiffrées.

Ensuite, mon opérateur mobile est également Free. Free ne pouvant techniquement pas assigner une adresse IP publique à chaque équipement mobile sur son réseau, lorsque vous utilisez des connexions pour de la donnée, vous vous retrouvez avec une IP en adressage privé (10.X.X.X).

Ces points sont à prendre en compte, surtout concernant la configuration IPsec qui devient légèrement plus complexe sur notre passerelle.

2. Configuration de la passerelle VPN

L’étape d’installation de l’OS OpenBSD ne sera pas détaillée puisque c’est une installation tout ce qu’il y a de plus standard. Deux points sont cependant à noter.

D’une part, vous aurez besoin d’utiliser au minimum OpenBSD 5.1 dont la date de sortie est comme d’habitude (cycles de développement de 6 mois) fixée au 1er mai 2012. A l’heure où je rédige cet article, OpenBSD 5.1 est seulement taggé dans le CVS, vous pouvez donc utiliser un snapshot de -current.

D’autre part, vous aurez besoin d’installer les sources de l’OS (src, pas xenocara ni les ports). J’utilise pour ma part une machine à base de Soekris net5501 avec le système installé sur une carte flash. Ne pouvant pas vraiment installer les sources et compiler les outils nécessaires, du fait de l’utilisation d’une carte flash, je monte les répertoires (/usr/obj et /usr/src) via un partage NFS exporté par une autre machine.

Je vous invite à lire la FAQ d’OpenBSD qui est un modèle du genre pour de plus amples informations sur l’installation de l’OS.

Une fois l’OS OpenBSD 5.1 installé, ainsi que ses sources, il faut modifier le fichier /etc/sysctl.conf pour autoriser certaines fonctionnalités au niveau du noyau d’OpenBSD. Pour cela, il faut s’assurer que ces lignes soient dé-commentées :
net.inet.ip.forwarding=1 # transfert IP entre interfaces
net.inet.gre.allow=1 # autorise le protocole de tunneling GRE
net.pipex.enable=1 # accélérateur de transfert IP pour PPP

4. Installation et configuration de npppd(8)

Ensuite, il faut compiler le daemon npppd(8). Celui-ci est déjà stable ; il n’est cependant pas compilé par défaut, suite à un manque de documentation mais également à une configuration qui doit être ré-écrite, afin de coller à la syntaxe des autres daemons d’OpenBSD. Pour compiler npppd(8) :
$ cd /usr/src/usr.sbin/npppd
$ make
$ sudo make install

Pour compiler npppdctl(8), son outil de contrôle :
$ cd /usr/src/usr.sbin/npppctl
$ make
$ sudo make install

Créer le fichier npppd.conf (issu du HOWTO évoqué précédemment) :
interface_list: tun0
interface.tun0.ip4addr: 10.0.0.1
pool.dyna_pool: 10.0.0.0/25
pool.pool: 10.0.0.128/25
auth.local.realm_list: local
auth.local.realm.acctlist: /etc/npppd/npppd-users.csv
realm.local.concentrate: tun0
lcp.mru: 1400
auth.method: mschapv2 chap
pptpd.enabled: true
pptpd.ip4_allow: 0.0.0.0/0
l2tpd.enabled: true
l2tpd.ip4_allow: 0.0.0.0/0
l2tpd.require_ipsec: false

Adapter ce fichier à votre convenance, en particulier les paramètres :

• interface_list : l’interface tun(4) à utiliser, « tun0″ si aucun autre tunnel n’existe.
• interface.tunX.ip4addr : l’adresse de l’interface tun(4).
• pool.dyna_pool : la plage dynamique des IP attribuées à vos utilisateurs.
• pool.pool : la plage utilisée pour les utilisateurs disposant d’adresses statiques (précisé plus bas).
• realm.local.concentrate : doit correspondre à l’interface tun(4) configurée précédemment.

Créer le fichier npppd-users.csv (issu du HOWTO évoqué précédemment) :
Username,Passwd,IP-Address,IP-Netmask,Descr,Calling-Id
user1,user1's secret,10.0.0.129,,memo for user1

Ce fichier contiendra les noms d’utilisateurs, leur mot de passe, l’adresse IP statique qui leur est affectée, ainsi que des informations optionnelles.

Une fois ces fichiers créés et ajustés à vos besoins, placez-les à l’endroit approprié :
$ sudo mkdir -m 0755 /etc/npppd
$ sudo cp npppd.conf /etc/npppd/
$ sudo cp npppd-users.csv /etc/npppd/

Ensuite, nous pouvons démarrer npppd(8) :
$ sudo npppd -D

5. Confiruration IPsec

Sous OpenBSD, la configuration IPsec est extrêmement simple et se trouve centralisée dans le fichier /etc/ipsec.conf. Éditer ce fichier, pour y ajouter la configuration IPsec :
ike dynamic esp transport \
proto udp from AA.AA.AA.AA (192.168.0.1) to any port 1701 \
aggressive auth "hmac-sha" enc "3des" group modp1024 \
quick auth "hmac-sha" enc "aes" \
srcid "server@my.domain" dstid "client@my.domain" \
psk "myandroidpsk"

Quelques précisions :

• dynamic : aide les configurations dans lequel le client a une IP qui change constemment.
• AA.AA.AA.AA : adresse IP publique de la connexion internet de notre passerelle VPN.
• 192.168.0.1 : adresse IP privée de notre passerelle VPN.
• aggressive : ce mode est nécessaire lors de l’utilisation d’ID spécifiques pour la connexion.
• srcid "server@my.domain" : ID IPsec du serveur, utilisé comme identité de la passerelle.
• dstid "client@my.domain" : ID IPsec du client, à configurer dans le client VPN du smartphone.

Note : ici, nous utilisons des ID spécifiques (srcid et dstid) car par défaut, les ID utilisés sont les IP des machines : c’est-à-dire les IP privées du smartphone et de la passerelle sur leur réseau respectif. Or, nos deux connexions à internet (celle du smartphone et celle de la passerelle VPN) sont derrière du NAT. Donc les ID utilisés par défaut ne sont pas reconnus par la machine distante, puisque la machine locale ne voit que l’IP publique de la machine distante.

Une fois la configuration IPsec effectuée, il faut :

• Démarrer l’interface virtuelle enc(4), sur laquelle le trafic IPsec déchiffré va circuler,
• Démarrer le ‘daemon’ isakmpd(8) qui a pour but d’assurer la gestion des clés IPsec avec le protocole IKEv1,
• Charger la configuration IPsec.

Cela se traduit par les commandes :
$ sudo ifconfig enc0 up
$ sudo isakmpd -Kv
$ sudo ipsecctl -f /etc/ipsec.conf

6. Le filtrage avec PF

Je ne vais pas détailler l’utilisation de Packet Filter (PF), le filtre de paquets d’OpenBSD ; pour celà vous pouvez vous référer à l’excellente FAQ de PF.

Je vais par contre détailler les points importants concernant notre utilisation dans le cadre de cette passerelle VPN L2TP/IPsec.

PF est maintenant activé par défaut dans OpenBSD, il est seulement nécessaire d’éditer sa configuration qui se fait dans le fichier /etc/pf.conf.

Tout d’abord, commençons par établir quelques variables utiles :
# Interface réseau physique
$ext_if = vr3
# Interface réseau virtuelle tun(4)
$tun_if = tun0
# Plage des clients VPN
$vpn_net = "10.0.0.0/24"
# Ports pour IPsec en UDP
$serv_udp = "{ isakmp, ipsec-nat-t }"
# Ports pour IPsec en TCP ainsi que SSH pour le management
$serv_tcp = "{ ssh, ipsec-nat-t }"

Notre règle par défaut bloque tout en entrée, mais pas en sortie ; par défaut avec PF, ce qui n’est pas bloqué est autorisé :
block in all

Ensuite, définissons une règle de NAT pour que les clients VPN qui arrivent sur l’interface virtuelle, puissent sortir sur l’interface physique, et donc les réseaux locaux de notre passerelle (et internet).
match out on $ext_if inet from $vpn_net nat-to $ext_if

Passons maintenant au filtrage à proprement dit. Commençons par autoriser le trafic IPsec sur notre interface physique :

• Le protocole ESP (le trafic L2TP chiffré avec IPsec),
• Les protocoles IKEv1 et NAT-Traversal pour les échanges de clés

Cela se traduit par les règles :
pass in on $ext_if proto esp to $ext_if
pass in on $ext_if proto udp to $ext_if port $serv_udp
pass in on $ext_if proto tcp to $ext_if port $serv_tcp

Puis, autorisons le trafic déchiffré, c’est à dire le trafic L2TP venant du smartphone vers notre passerelle, à passer sur l’interface enc(4) :
pass in on enc0 proto udp to $ext_if port l2tp keep state (if-bound)

Note : le mot clé ‘keep state (if-bound)’ est nécessaire sur une interface enc(4). Il permet de lier l’état créé dans PF à l’interface enc0 (par défaut, les états sont flottants), évitant ainsi d’avoir des flux non chiffrés sur d’autres interfaces.

Pour finir, autorisons le trafic utile de notre VPN : le trafic encapsulé dans le VPN, à destination de notre réseau local, d’internet, etc. à entrer sur l’interface virtuelle tun0. Celui-ci sera ensuite automatiquement routé vers la bonne interface :
pass in on $tun_if inet proto { icmp, tcp, udp } from $vpn_net

7. Rendre permanente la configuration

Pour configurer l’interface enc0 à chaque démarrage :
$ sudo sh -c "echo up > /etc/hostname.enc0"
$ sudo chmod 640 /etc/hostname.enc0

Pour démarrer isakmpd(8) au démarrage, ajouter ces lignes au fichier /etc/rc.conf.local :
ipsec=YES
isakmpd_flags="-K"

Pour démarrer npppd(8) automatiquement, ajouter ces lignes au fichier /etc/rc.local :
echo -n 'starting site daemons:'
if [ -x /usr/sbin/npppd ] ; then
/usr/sbin/npppd -D
echo -n ' npppd'
fi
echo '.'

8. Configuration du client

La configuration d’un VPN sur un téléphone Android est très simple. Pour cela, allons dans les paramètres, puis les paramètres sans fil, puis dans la section VPN :

Ajoutons maintenant un nouveau VPN en sélectionnant le type « L2TP/IPsec PSK », puis remplissons les données que nous avons indiquées précédemment :

• Nom : peut être ce que vous souhaitez,
• Type : doit être « L2TP/IPsec PSK »,
• Adresse du serveur : l’adresse IP publique de votre connexion internet ou alors votre nom de domaine si vous en possédez un,
• Secret L2TP : laissez vide,
• Identifiant IPsec : doit correspondre à ce que vous avez indiqué pour le paramètre « dstid » dans le fichier /etc/ipsec.conf de la passerelle,
• Clé pré-partagée IPsec : doit correspondre à ce que vous avez indiqué pour le paramètre « psk » dans le fichier /etc/ipsec.conf de la passerelle.

Une fois les paramètres renseignés, démarrons la connexion, en fournissant le nom d’utilisateur et le mot de passe indiqués dans le fichier npppd-users.conf :

La connexion VPN est démarrée une fois que la petite clé est présente dans la barre de notification en haut à gauche :

9. Gestion de la passerelle

Pour avoir une vision de ce qu’il se passe en temps réel sur notre passerelle VPN, deux commandes sont très utiles.

Tout d’abord, pour consulter les sessions IPsec en cours et en particulier la Security Association Database (SAD) :
$ sudo ipsecctl -sa
FLOWS:
flow esp in proto udp from BB.BB.BB.BB to 192.168.0.1 peer BB.BB.BB.BB srcid server@my.domain dstid client@my.domain type use
flow esp out proto udp from 192.168.0.1 to BB.BB.BB.BB peer BB.BB.BB.BB srcid server@my.domain dstid client@my.domain type require

SAD:
esp transport from 192.168.0.1 to BB.BB.BB.BB spi 0x026f944d auth hmac-sha1 enc aes-256
esp transport from BB.BB.BB.BB to 192.168.0.1 spi 0x20510079 auth hmac-sha1 enc aes-256

Et ensuite pour consulter les sessions L2TP démarrées dans npppd(8) ainsi que des statistiques utiles :
$ sudo npppctl session all
Ppp Id = 14
Ppp Id : 14
Username : user1
Realm Name : local
Concentrated Interface : tun0
Assigned IPv4 Address : 10.0.0.129
Tunnel Protocol : L2TP
Tunnel From : BB-BB-BB-BB.romanichel.net:43682
Start Time : 2012/02/15 16:48:57
Elapsed Time : 114 sec (1 minute)
Input Bytes : 3214 (3.1 KB)
Input Packets : 45
Input Errors : 0 (0.0%)
Output Bytes : 6861 (6.7 KB)
Output Packets : 25
Output Errors : 0 (0.0%)

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.