GuiGui's show

L'idée du jour est d'utiliser un serveur dédié chez OVH, qui sert déjà à autre chose, pour se monter un petit VPN sans prétention. Quand je dis sans prétention c'est que je prévois ça pour un usage personnel (unipersonnel) et que je ne destine pas ce VPN à l'échange de flux hautement confidentiels (sinon ça ne finirait pas chez OVH ...). Donc si vous cherchez une config blindée haute sécurité, ce n'est pas le bon billet, désolé.

Le but de ce VPN est de me permettre d'être sur Internet quand je veux faire des tests ou autre (exemple parmi d'autres : nmap mon serveur pour vérifier qu'il n'y a rien de plus qui est ouvert sur l'extérieur que ce que je veux). Quand je dis « être sur Internet », je veux dire : être capable d'émettre et de recevoir tous les contenus et toutes les applications de mon choix sans aucune discrimination ... Ho ! La définition de la neutralité du net ! Donc éviter un filtrage de ports à la con, éviter un filtrage du type "ne peut entrer sur le réseau que ce qui fait suite à une demande de l'intérieur" (en gros : impossible d'héberger des services). C'est rageant d'être perturbé par notre FAI (Fournisseur d'Accès à son Intranet dans le cas présent) quand on veut observer quelque chose ou monter un service.

Attention toutefois : le tunnel sort chez OVH et il faut savoir qu'OVH n'a pas un impératif de neutralité. Des usages y sont clairement interdits ou soumis à autorisation préalable comme, par exemple mais pas seulement, héberger un proxy ou un nœud TOR ou utiliser des logiciels de P2P. OVH duplique aussi tous les mails sortants pour analyse temps-réel anti-spam ... Donc si vous cherchez un vrai accès à Internet, même grâce à un VPN, je vous conseille plutôt les FAI associatifs de la Fédération FDN qui offrent une telle garantie par design, sans fluctuation ni d'exceptions.

En supplément, "depuis Internet", je souhaite que mon client VPN soit vu avec une IP distincte de celle attribuée à mon dédié. Il faut donc utiliser une IP failover et faire en sorte que le trafic sorte et entre de notre dédié par cette IP.

Table des matières

Sources

Je clos le suspens de suite : ce billet est une arnaque ! On trouve les morceaux de config OpenVPN à peu près partout : OpenVPN sur le Wiki Debian.org, le man d'OpenVPN est bien fait et le petit morceau de conf pour sortir du VPN avec une IP failover est aussi documenté un peu partout : Utiliser un VPN avec une IP failover chez kdecherf (git)-[blog] %. Pour ceux qui cherchent comment monter un serveur VPN sur leur dédié OVH sans utiliser une IP failover : il suffit de faire un SNAT sur l'IP principale du serveur ou, au pire, un masquerade sur ce qui sort par eth0.

Néanmoins, parce que je vous aime bien, je vais vous donner ma config.

Trêve de blabla, on commence !

Au niveau d'OVH, c'est très simple : il suffit de commander une IP failover, de la payer et d'attendre un peu qu'elle soit active. Rien de plus. Pas besoin de définir une MAC virtuelle, rien.

Point to point et chiffrement symétrique

Dans un premier temps, on va utiliser une topologie point à point avec un chiffrement symétrique.

On installe OpenVPN sur le serveur et sur le client :

apt-get install openvpn

Pour l'instant, je ne veux pas qu'OpenVPN démarre tout seul au boot donc je lance la commande suivante sur le client et sur le serveur :

update-rc.d -f openvpn remove

On crée la config côté serveur (dans /etc/openvpn/server.conf par exemple) :

proto udp
port 1194
dev tun
 
mode p2p
 
cipher AES-256-CBC
secret /etc/openvpn/vpn-static.key
 
comp-lzo
 
verb 3
 
persist-key
persist-tun
ping 30
ping-exit 90
 
user openvpn
group openvpn
 
ifconfig 198.18.0.1 198.18.0.2
script-security 2
up /etc/openvpn/up.sh
plugin /usr/lib/openvpn/openvpn-down-root.so /etc/openvpn/down.sh

Quelques remarques :

• Pour le choix tun/tap (route/bridge) : comme je n'ai pas besoin des fonctionnalités des tap (broadcast, donc possibilité d'utiliser NetBios/SMB, possibilité d'utiliser d'autres protocoles de couches 3, ... voir : What is the difference between bridging and routing? sur OpenVPN.net et Bridging vs. routing sur OpenVPN community), j'ai choisi le mode router/tun pour profiter de l'avantage d'avoir moins d'overhead.
• Pour l'adressage du serveur et du client, j'ai pris le bloc 198.18.0.0/30 qui est englobé dans 198.18.0.0/15 qui est un préfixe réservé à l'IANA pour les tests et qui n'est donc pas annoncé globalement. L'idée est d'éviter une éventuelle collision. Comme ce préfixe est méconnu et que les réseaux auxquels je me connecte sont adressés soit en public soit avec les préfixes du RFC 1918, je suis sûr d'être tranquille. Notez qu'il serait peut-être plus pertinent de prendre un préfixe /30 dans 10.0.0.0/8. La probabilité de se connecter à un réseau existant utilisant ce bloc me paraît faible.
• « plugin /usr/lib/openvpn/openvpn-down-root.so » permet de lancer le script de fin avec les droits root alors même qu'OpenVPN a, comme on le lui a demandé, perdu, dès la fin de l'initialisation, les droits root pour ceux de l'utilisateur openvpn et du groupe openvpn.

On crée la config côté client (dans /etc/openvpn/client.conf, par exemple) :

proto udp
remote <IP PRINCIPALE DU SERVEUR> 1194
dev tun
 
cipher AES-256-CBC
secret /etc/openvpn/vpn-static.key
 
comp-lzo
 
verb 3
 
persist-key
persist-tun
ping 30
ping-exit 90
explicit-exit-notify
 
user openvpn
group openvpn
 
ifconfig 198.18.0.2 198.18.0.1
route-gateway 198.18.0.1
redirect-gateway def1

Sur le serveur, on crée les deux scripts. D'abord /etc/openvpn/up.sh :

#!/bin/bash
 
ifconfig br0:1 <IP FAILOVER> netmask 255.255.255.255 broadcast <IP FAILOVER>
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 198.18.0.0/30 ! -d 198.18.0.0/30 -j SNAT --to-source <IP FAILOVER>
iptables -t nat -A PREROUTING -d <IP FAILOVER> -j DNAT --to-destination 198.18.0.2

Puis le script /etc/openvpn/down.sh :

#!/bin/bash
 
echo 0 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -D POSTROUTING -s 198.18.0.0/30 ! -d 198.18.0.0/30 -j SNAT --to-source <IP FAILOVER>
iptables -t nat -D PREROUTING -d <IP FAILOVER> -j DNAT --to-destination 198.18.0.2
ifconfig br0:1 down

Quelques remarques :

• J'ai configuré l'alias sur br0 car j'utilise un bridge pour attribuer des IP failover à mes conteneurs LXC (voir Utiliser LXC sur un Kimsufi). Si vous n'avez pas de VM ni de conteneurs LXC ou autre montage du même type, alors il faudra faire l'alias sur eth0.
• Mapper 198.18.0.2 à l'IP failover suffit amplement. Néanmoins, j'ai voulu jouer la prudence au cas où le serveur émettrait avec 198.18.0.1 car je ne suis pas sur mon réseau mais sur celui d'OVH. Ce scénario ne devrait jamais se produire mais bon ... Au moins comme ça, ça sortira avec l'IP failover. Si je ne vois rien passer, OVH m'indiquera un problème avec cette IP et je saurai alors que le problème vient du VPN sans passer 5h à essayer de comprendre. Indiquer un /30 est par facilité : on pourrait utiliser les ip set pour indiquer les 2 adresses IP précises.
• Le DNAT n'est clairement pas obligatoire. C'est pour le fun ... Si l'on veut héberger des services derrière ce VPN ...
• Pour ceux qui cherchent comment monter un serveur VPN sur leur dédié OVH sans utiliser une IP failover, seule la première règle iptables change :

  iptables -t nat -D POSTROUTING -s 198.18.0.0/30 ! -d 198.18.0.0/30 -j SNAT --to-source <IP PRINCIPALE DU SERVEUR>

  Forcement, vous ne pouvez alors pas faire de DNAT complet mais uniquement pour certains ports que vous voulez rediriger vers votre client VPN.

• Enfin, selon votre configuration, il faudra autoriser le transfert de paquet depuis/vers le VPN. Cela se fait dans chaîne FORWARD. 😉

On rend ces scripts exécutables :

chmod u+x /etc/openvpn/up.sh /etc/openvpn/down.sh

On crée l'utilisateur openvpn :

adduser openvpn --disabled-login --no-create-home --shell /bin/false

Sur le serveur ou sur le client, on génère la clé cryptographique :

openvpn --genkey --secret /etc/openvpn/vpn-static.key

Il faudra la transférer à l'autre partie via scp puis vérifier les droits : root:root 400.

Enfin, selon votre configuration, il faudra autoriser OpenVPN dans votre firewall, en entrée et en sortie. Aussi bien sur le client que sur le serveur.

Il est l'heure de tester (sur le client et le serveur) :

service openvpn restart

Normalement, le client doit pouvoir pinguer 198.18.0.1 et sortir sur Internet par le VPN. L'adresse IP "vue depuis Internet" doit être l'IP failover.

Pour ceux que ça intéresse, voici les configurations équivalentes mais en utilisant des tap. Pour le serveur :

proto udp
port 1194
dev tap
 
cipher AES-256-CBC
secret /etc/openvpn/vpn-static.key
 
comp-lzo
 
verb 3

persist-key
persist-tun
ping 30
ping-exit 90
 
user openvpn
group openvpn
 
ifconfig 198.18.0.1 255.255.255.252
script-security 2
up /etc/openvpn/up.sh
plugin /usr/lib/openvpn/openvpn-down-root.so "/etc/openvpn/down.sh"

Pour le client :

proto udp
remote <IP PRINCIPALE DU SERVEUR> 1194
dev tap
 
cipher AES-256-CBC
secret /etc/openvpn/vpn-static.key
 
comp-lzo
 
verb 3
 
persist-key
persist-tun
ping 30
ping-exit 90
explicit-exit-notify
 
user openvpn
group openvpn
 
ifconfig 198.18.0.2 255.255.255.252
route-gateway 198.18.0.1
redirect-gateway def1

Point to point et chiffrement asymétrique

L'inconvénient principal du chiffrement symétrique est qu'il ne permet pas le perfect forward secrecy. Bien que, comme je l'ai déjà dit, mon VPN me servira principalement à faire des tests et ne transmettra pas mes secrets les plus noirs, je me dis qu'il peut être intéressant de faire une topologie p2p avec du chiffrement asymétrique, for ze fun.

Attention à ne pas mal interpréter mes propos : le chiffrement du tunnel reste symétrique. Simplement, lors de l'initialisation, le client et le serveur échangent une clé temporaire pour réaliser le chiffrement symétrique du tunnel. C'est cet échange initial qui se fait en utilisant la cryptographie asymétrique.

Pour cette partie, on va suivre d'encore plus près le tutoriel du wiki Debian.org. Reportez-vous à la partie « TLS-enabled VPN ». La génération du matériel cryptographique est identique : seules les configurations d'OpenVPN sont différentes.

Voici la configuration du serveur :

proto udp
port 1194
dev tun
 
mode p2p
tls-server
 
ca      /etc/openvpn/easy-rsa/keys/ca.crt
cert    /etc/openvpn/easy-rsa/keys/server.crt
key     /etc/openvpn/easy-rsa/keys/server.key
dh      /etc/openvpn/easy-rsa/keys/dh1024.pem
 
comp-lzo
 
verb 3
 
persist-key
persist-tun
ping 30
ping-exit 90
 
user openvpn
group openvpn
 
ifconfig 198.18.0.1 198.18.0.2
script-security 2
up /etc/openvpn/up.sh
plugin /usr/lib/openvpn/openvpn-down-root.so /etc/openvpn/down.sh

ÉDIT du 12/01/2014 à 13h10 : Il faudra prévoir la révocation des certificats clients. C'est toujours utile en cas de perte ou de compromission, surtout si vous distribuez des accès (oui oui, le titre du billet cause d'un VPN unipersonnel mais bon) ... Fin de l'édit

La configuration du client :

proto udp
remote <IP PRINCIPALE DU SERVEUR> 1194
dev tun
 
tls-client
 
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/guigui.crt
key /etc/openvpn/easy-rsa/keys/guigui.key
 
comp-lzo
 
verb 3
 
persist-key
persist-tun
ping 30
ping-exit 90
explicit-exit-notify
 
user openvpn
group openvpn
 
ifconfig 198.18.0.2 198.18.0.1
route-gateway 198.18.0.1
redirect-gateway def1

Il est l'heure de tester (sur le client et le serveur) :

service openvpn restart

Normalement, le client doit toujours pouvoir pinguer 198.18.0.1 et sortir sur Internet par le VPN. L'adresse IP "vue depuis Internet" doit toujours être l'IP failover.

La même mais en mieux

Le résultat obtenu jusque-là est pas mal. Il manque un dernier truc : pour l'instant le script up est exécuté au démarrage d'OpenVPN, juste après la création de l'interface tun. Le down est exécuté à l'arrêt d'OpenVPN. J'aimerais que les scripts soient exécutés uniquement lorsque le client se connecte/déconnecte de mon VPN. Comme ça, le reste du temps je n'ai pas de la config qui ne sert à rien en train de tourner. Pas de forward, pas de NAT, l'IP failover ne répond pas aux requêtes, ...

Cela est possible en utilisant les directives client-connect/client-disconnect d'OpenVPN. Mais elles sont disponibles uniquement en mode serveur. Ce mode requiert l'utilisation d'un /29 au minimum donc on va avoir un peu de configuration à changer.

On s'occupe d'abord des configurations OpenVPN. Celle du serveur :

proto udp
port 1194
 
dev tun
 
mode server
max-clients 1
 
tls-server
ca      /etc/openvpn/easy-rsa/keys/ca.crt
cert    /etc/openvpn/easy-rsa/keys/server.crt
key     /etc/openvpn/easy-rsa/keys/server.key
dh      /etc/openvpn/easy-rsa/keys/dh1024.pem
 
comp-lzo
 
verb 3
 
persist-key
persist-tun
ping 30
ping-exit 90
 
user openvpn
group openvpn
 
ifconfig 198.18.0.1 198.18.0.2
ifconfig-pool 198.18.0.5 198.18.0.6
route 198.18.0.0 255.255.255.240
push "route 198.18.0.1"
 
script-security 2
client-connect "/usr/bin/sudo -u root /etc/openvpn/up.sh"
client-disconnect "/usr/bin/sudo -u root /etc/openvpn/down.sh"

La configuration du client :

proto udp
port 1194
 
dev tun
 
client
remote <IP PRINCIPALE DU SERVEUR> 1194
 
tls-client
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/guigui.crt
key /etc/openvpn/easy-rsa/keys/guigui.key
 
comp-lzo
 
verb 3
 
persist-key
persist-tun
ping 30
ping-exit 90
explicit-exit-notify
 
user openvpn
group openvpn
 
redirect-gateway def1

On remarque l'utilisation de sudo pour lancer les scripts à la connexion/déconnexion. En effet, lorsque le client se connectera ou se déconnectera, il y aura longtemps que le serveur OpenVPN aura perdu les droits root. Il faut donc rajouter une ligne au fichier /etc/sudoers :

openvpn		ALL=(root)	NOPASSWD:/etc/openvpn/up.sh,/etc/openvpn/down.sh

Les scripts d'up et de down changent aussi : on NAT le /29 et on redirige le DNAT sur la bonne IP :

#!/bin/bash
 
echo 0 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -D POSTROUTING -s 198.18.0.0/29 ! -d 198.18.0.0/29 -j SNAT --to-source <IP FAILOVER>
iptables -t nat -D PREROUTING -d <IP FAILOVER> -j DNAT --to-destination 198.18.0.6
ifconfig br0:1 down

Les mêmes modifications s'appliquent au script de déconnexion. Je vous laisse faire les changements. 🙂

Voilà, on arrive à la fin de ce que je voulais vous montrer.

Aux alentours de Noêl (2012 hein :P), j'ai décidé de passer mes "serveurs" en IPv6. Ce billet est donc une sorte de retour d'expérience/un avis et surtout pas un tutoriel. Il y a suffisamment de tutoriels sur les sujets que je vais aborder. Il n'y aura pas non plus trop d'explications théoriques ni de prêches "pourquoi il est temps de se bouger pour IPv6" (il est évident que c'est uniquement pour voir la tortue dansante sur http://www.kame.net/).

Table des matières

Ressources

Si vous débutez avec IPv6, je vous recommande la lecture suivante : Yet Another Reference for Delivering IPv6 to the Next Generation.

Vous y trouverez, entre autres, des explications détaillées des notions que je vais employer dans ce billet sans forcement les expliciter.

Passer à IPv6

Utiliser IPv6, ce n'est pas difficile, ça ne nécessite pas des connaissances d'un niveau extraordinaire en réseaux informatiques. Il n'y a même pas besoin de comprendre tout ce que je vais raconter ici car c'est de la garniture. Pour débuter par la pratique, il y a une montagne de tutoriels sur Internet, il suffit de les suivre et, ensuite, si l'intérêt vient, de se documenter pour comprendre petit à petit.

Pour moi, il y a clairement deux étapes :

• Fournir une connectivité v6 à une machine. Cette étape est, comme je me tue à le répéter depuis le début de ce billet, facile. Sauf si comme moi, vous étudiez les différents "modes de fourniture", "for ze lulz".
• Dans le cas d'un serveur, il convient également de vérifier que les services (httpd, dnsd, smtpd, ...) soient bien disponibles sur IPv6 comme sur IPv4. Cette étape est juste de la rigolade : la documentation de tous les logiciels serveurs sérieux indiquent, clairement et de manière évidente, la directive de configuration "kivabien". La palme revient à Dovecot (serveur POP/IMAP) dont la directive de configuration pour du dual-stack est indiquée dans le fichier de configuration lui-même, il n'y a plus qu'à décommenter la ligne.

La connectivité

Différence entre les méthodes de transition

Il y a plusieurs modes de fourniture d'adresses v6 : natif (votre opérateur réseau vous alloue un bloc), 6in4 (typiquement un tunnel chez Hurricane Electric), 6to4 (passerelles qui encapsulent de l'IPv6 dans de l'IPv4), Teredo (encapsulation au niveau UDP), ... En terme de qualité du service, il est souvent admis que l'on a : natif > 6in4 > 6to4 > Teredo.

Certaines sont obsolètes ou sur le point de l'être (6to4), d'autres méthodes existent mais ne conviennent pas à ma situation (je veux une connectivité IPv6 sur mes serveurs disposant d'une connectivité v4 uniquement).

Dans la suite, je ne parlerai que de natif, de 6in4 et de 6to4.

Natif

Bon, on va faire ça rapidement car ça se configure le plus simplement du monde. Chez OVH, il suffit de regarder quel bloc vous a été attribué dans le manager et ensuite d'ajouter quelque chose comme ça dans votre /etc/network/interfaces :

iface eth0 inet6 static
        address 2001:41d0:1:2345::1
        netmask 64
        up ip -6 r a 2001:41d0:1:23FF:FF:FF:FF:FF dev eth0 && ip -6 r a default via 2001:41D0:1:23FF:FF:FF:FF:FF

address doit avoir pour valeur une des IPs dans le bloc qui vous a été attribué. Le masque est fixe : /64. La passerelle est celle du /56 qui englobe votre /64. Donc réseau /56 complété par « ff ». Pour pouvoir l'ajouter, comme elle est hors de votre /64, il faut ajouter une route (première partie de la commande passée à « up ») puis ensuite ajouter la définition de la passerelle par défaut elle-même (deuxième partie de la commande). Attention : le guide OVH concernant l'IPv6 n'est pas à jour. Voir ce post sur le forum OVH anglais.

Bien sûr, si vous avez un bridge (LXC, tout ça), la première ligne sera "iface br0 inet6 static" 😉 .

ÉDIT du 03/08/2013 à 18h45 : mise à jour de cette sous-partie pour apporter quelques précisions. Fin de l'édit

Pour appliquer les modifications :

service networking restart

Ici les avantages et inconvénients sont vite vus : c'est tout pareil que d'avoir une IPv4.

6in4

Là aussi, c'est plutôt simple : il suffit de se créer un compte chez un tunnel broker (Hurricane Electric, SixXS, Freenet6, ...) et d'utiliser les paramètres qu'il nous donne pour configurer notre réseau. Vu le plus grand bien que j'ai entendu d'Hurricane Electric, j'ai décidé de prendre mon tunnel chez eux.

Pour la configuration, je vous recommande : Tunnelled IPv6 via Hurricane Electric on Ubuntu.

Dans mon cas, avec le bloc qui m'a été attribué et en utilisant le POP de Londres, ça donne ça dans mon /etc/network/interfaces :

auto he-ipv6
iface he-ipv6 inet6 v4tunnel
        address 2001:470:1f08:751::2
        netmask 64
        remote 216.66.80.26
        local 87.98.183.12
        endpoint any
        up      ip -6 route add 2000::/3 via ::216.66.80.26 dev he-ipv6
        up      ip -6 addr add 2001:470:1f09:751::1/128 dev he-ipv6
        down    ip -6 route flush dev he-ipv6

he-ipv6 est un label choisi arbitrairement.

Le piège bateau qui peut vous arriver est de confondre l'adresse v6 de sortie du tunnel, qu'il faut mettre dans addresss et l'adresse que vous allez réellement attribuer à la machine, qui doit être prise dans le bloc qui vous a été attribué. Le débbogage n'est pas évident : une inversion semblera fonctionner, surtout depuis d'autres tunnels HE mais cela ne fonctionnera pas depuis partout, tout le temps.

Pour appliquer les modifications :

service networking restart

Au niveau des avantages et des inconvénients :
Cela ajoute un saut de réseau et une dépendance supplémentaire. Quand le POP d'Hurricane Electric sur lequel vous êtes tombe en rade, comme en septembre/octobre dernier pour celui de Paris, votre connectivité IPv6 tombe. On nuancera en disant qu'HE semble sérieux (donc les pannes n'arrivent pas tous les jours) et qu'après tout, il ne s'agit que d'une solution de transition librement consentie.

Ce qui me dérange plus, c'est la centralisation du réseau que cela induit. Rappelez-vous : Internet est un réseau acentré : il n'y a jamais eu de centre ni dans la technique ni dans les usages. Pour les usages, c'est loupé (Google, Facebook, ...) donc si l'on se met aussi à le faire techniquement ... Tout le monde se concentre chez un, deux, maximum trois fournisseurs de tunnels qui accumulent mécaniquement du pouvoir.

Avant, je dégainais aussi l'argument "vie privée" mais j'ai dû retrousser chemin. Certes, nos données (votre demande et la réponse de mon serveur) passent chez HE mais, même sans HE, et même en v4, nos données transitent par quelques fournisseurs de connectivité avant d'atteindre leur destination. C'est le principe d'Internet. Les a-t-on choisi ? Certainement pas : cela dépend des accords passés par notre opérateur réseau et par des choix automatiques de la route optimale. Au moins, HE est un choix librement consenti. Pour la protection de la vie privée, il faut utiliser le chiffrement.

6to4

Là,je pense qu'on atteint des sommets de simplicité : pas d'allocation à avoir ni de compte à créer chez un tiers.

Pour la mise en pratique, on cherche notre bloc préfixé par 2002. Dans mon cas, avec mon IPv4 (ipv6calc se trouve dans le package Debian du même nom) :

ipv6calc --action conv6to4 87.98.183.12
No input type specified, try autodetection...found type: ipv4addr
No output type specified, try autodetection...found type: ipv6addr
2002:5762:b70c::

Ensuite, on édite le fichier /etc/network/interfaces. Dans mon cas, cela donne :

auto tun6to4
iface tun6to4 inet6 v4tunnel
        address 2002:5762:b70c::1
        netmask 48
        local 87.98.183.12
        endpoint any
        gateway ::192.88.99.1

tun6to4 est un label choisi arbitrairement. La gateway et le netmask sont fixe. L'adresse est choisie dans le bloc. Attention, il y a des morceaux de configuration erronées qui traînent sur le web et comme pour un tunnel, le débbogage n'est pas forcement évident.

Pour appliquer les modifications :

service networking restart

Au niveau des avantages et des inconvénients :
Le préfixe 2002::/16 et l'adresse 192.88.99.1 sont anycastés. Donc on ne sait jamais sur quelle instance on va atterrir. Et cela peut varier d'un échange réseau à un autre. L'effet de concentration visible avec les tunnels 6in4 est moins accentué. C'est cela qui m'a intéressé dans cette solution.

La conséquence du point précédent est que la connectivité dépend d'une infrastructure qu'on ne maîtrise pas : le relai n'est-il pas malveillant ? Ne va-t-il pas mettre en danger ma vie privée ? Et si un opérateur fait, volontairement ou non, une fausse annonce des préfixes alors qu'il n'a pas de relai 6to4 opérationnel ? Et si le relai choisi automatiquement est victime de congestion, quid de ma connectivité ?

Une autre conséquence est que le trafic est asymétrique. À l'aller, vos paquets passent par le relai le plus proche de vous (au sens réseau). Au retour, ils passeront par le relai le plus proche de la destination. Ces relais peuvent donc être différents et de qualité inégale. Le chemin ne sera donc pas optimal : s'il n'y a pas de relai proche de la destination ? Et si ce relai n'est pas également le plus proche de vous ?

J'ai remarqué que l'initialisation d'une communication en utilisant 6to4 est clairement plus longue qu'avec de l'IPv6 natif ou qu'avec un tunnel. J'ai aussi remarqué que la qualité est toute relative. J'ai testé ma connectivité sur le top 10 des sites web les plus fréquentés (donc pas sur des infrastructures isolées/possiblement mal-configurées) sans tenter le diable : des pertes de paquets surviennent à une fréquence relativement haute.

En 2011, les RFC décrivant 6to4 ont fait l'objet d'une demande de passage à un statut "historique". Même si cette demande n'a pas aboutie, cela montre un désintérêt certain pour cette méthode de transition. De ce fait, on peut estimer qu'aucun nouveau relai 6to4 ne sera mis en place, que les relais en place ne seront plus la priorité de leurs administrateurs donc ils ne seront plus maintenus "au top". On peut supposer aussi que le nombre de relais à même déjà diminué et qu'il y a donc autant de concentration de trafic avec 6to4 qu'avec un tunnel 6in4.

J'ai aussi remarqué que le préfixe 2002::/16 ne semble pas prioritaire. Soit une machine source qui sélectionne l'adresse de destination de la cible qu'elle veut atteindre. Si elle a le choix entre une IPv6 6to4 et une IPv4, elle choisira l'IPv4. Je ne dis pas que mes tests et mon panel sont représentatifs mais du coup, ça me jette tout de même un froid vis-à-vis de 6to4. Après, il y a sûrement moyen de prioriser le choix du préfixe 6to4 (dans le fichier /etc/gai.conf pour la libc sous GNU/Linux, par exemple) mais cela se fait sur le client. Comme la masse n'éditera pas ce fichier, l'intérêt de 6to4 en prend un coup.

Question de découpage

On pourrait se demander pourquoi je n'ai pas utilisé une partie de mon bloc IPv6 natif by OVH pour adresser le serveur de ce blog. La réponse se fait en plusieurs temps.

D'une part, j'ai plusieurs domaines différents, qui n'ont pas grand chose en commun. On considère qu'un /64 est le minimum syndical pour un utilisateur final. Je considère chacun de mes domaines comme un utilisateur final. Chacun doit donc avoir son bloc v6. Une autre manière de le formuler est de dire que cela préserve un minimum de cohérence entre l'adressage des domaines si l'on considère, qu'un /64 v6 est l'équivalent d'un /32 v4. Même si l'autoconfiguration (qui ne marche plus au délà d'un /64) n'est pas activée chez OVH, ne pas découper au delà d'un /64 permet de former son esprit aux bonnes pratiques.

D'autre part, cela met en place une sorte de "redondance" (je ne sais pas comment qualifier ça, en fait) : chez OVH, j'ai déjà eu des problèmes sur un bloc précis (un bloc plus joignable ou partiellement). Néanmoins, cela dure très peu de temps. En utilisant des IPv4 dans des blocs différents, on peut diminuer le risque. En utilisant des bloc v6 différents, c'est le même principe.

Enfin : tester les différentes méthodes pour de vrai "for ze fun". Les labos (Netkit ou autres) ne permettent pas de se rendre compte de tous les aspects d'une méthode. Et surtout car si l'on doit attendre un déploiement natif pour se former en pratique, on ne s'en sortira pas !

Configuration des services

Pour vous montrer que la configuration pour un usage en double pile des grands logiciels serveurs massivement utilisés est facile, je vais vous donner quelques directives de configuration :

• OpenSSHd : AddressFamily any;
• BIND : listen-on { interface v4/toute interface v4; }; listen-on-v6 { interface v6/toute interface v6; };
• Unbound : interface: interface-v4 interface: interface-v6
• Apache HTTPD : Listen 80 / Listen 443 par défaut suffisent.
• Postfix : inet_protocols = ipv4,ipv6 dans main.cf
• Dovecot : listen = *, [::]
• Ngnix : listen [::]:80 default_server ipv6only=off;
• ejabberd : inet6, dans les blocs ejabberd_c2s et ejabberd_s2s_in,

Il faudra redémarrer le service pour prendre en compte la modification.

Pensez au DNS

La première chose à faire est d'indiquer que vous utilisez IPv6. Cela se fait en ajoutant les enregistrements AAAA qui vont bien dans votre zone. Ces enregistrements fonctionnent pareil que les A mais pour IPv6. Si le serveur faisant autorité sur votre zone passe aussi en v6, et que son nom fait partie de la zone (exemple : ns1.guiguishow.info fait partie de la zone guiguishow.info), pensez à soumettre un glue record AAAA à votre zone parente sinon une résolution totalement en v6 de votre zone sera impossible.

Reverse v6

La deuxième chose sera d'affecter la bonne valeur à vos reverse. Vous savez, le truc qui dit que 87.98.183.12 c'est viki.guiguishow.info (et qui est bien différent de la requête qui dit viki.guiguishow.info c'est 87.98.183.12). Il faut le faire aussi en v6. C'est surtout utile pour les vérifications faites par les serveurs SMTP mais c'est une bonne pratique en général.

Tunnel 6in4

Pour les tunnels Hurricane Electric, HE vous délègue la zone reverse qui correspond au bloc qu'ils vous ont attribué. Pour la mise en œuvre, tout est expliqué ici : Reversing IPv6 Addresses to Names.

Pour vous aider à trouver votre zone reverse/vos enregistrements PTR, je vous conseille l'usage d'ipv6calc (package du même nom sous Debian). Exemple :

ipv6calc --addr2ip6_arpa 2001:470:1f09:751::1
No input type specified, try autodetection...found type: ipv6addr
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.5.7.0.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa.

Là, c'est un enregistrement complet. Pour votre zone, comme HE vous attribue, pour simplifier, un /64, il s'agira des 4 derniers groupes de 4 chiffres (64 bits pour la partie réseau de l'adresse donc 4 groupes de 4 chiffres hexadécimaux). Ici : 1.5.7.0.9.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa. est la zone reverse.

6to4

Pour le 6to4, vous pouvez aussi obtenir une délégation de la zone reverse, ce que je trouve "énorme" ! Il suffit d'aller à l'adresse suivante : https://6to4.nro.net/, qui est gérée par les différents RIR. On remarquera tout de suite que le certificat x509 a expiré en juillet 2012, ce qui tend à confirmer 6to4 comme une solution de seconde zone.

Pour obtenir la délégation, il faut aller sur ce site avec une IPv6 préfixée par 2002::. Sur un serveur, on pourra donc avoir recours à du bon vieux ssh port forwarding :P.

Vous devez remplir le formulaire en indiquant, entre autres, l'adresse d'au moins 2 serveurs de noms qui distribue la zone indiquée. Pour la suite, je ne peux pas vous aider plus puisque j'ai été confronté à une erreur aléatoire : soit je n'avais aucun message en retour, soit une erreur m'informant que je n'ai pas l'autorisation pour effectuer l'opération demandée ... Dommage car j'ai trouvé le concept formidable.

IPv6, ce futur

Je reste dubitatif sur le déploiement massif d'IPv6 dans les années à venir ... Après tout, les vieux routards vous diront que cela fait déjà quasiment 10 ans qu'on leur dit qu'IPv6 c'est demain.

Je vais tenter d'argumenter (peu de noms car je fais des statistiques, pas une distribution de blâmes) :

• Les principaux FAI commerciaux français ne sont pas prêts (pour les particuliers). Orange ne prévoit rien avant mi-2014. Bouygues devait proposer du v6 sur son offre ADSL fin 2012 mais ça semble encore repoussé. Free fait du 6rd (évolution 6to4) sur l'ADSL et du natif sur la fibre. Dans les 2 cas, il s'agit d'un /64. Autrement dit, mettre la freebox en bridge serait impossible sans manipulations crades (proxy NDP, tout ça) et cela amène d'autres problématiques (contrôle du terminal vers Internet, liberté, ...). SFR propose aussi du v6 encapsulé (un /64). FDN fournit un /48. Pour les autres, je vous laisse chercher.
• Les opérateurs en général, pas seulement les FAI, sont-ils prêts ? Pour me donner une idée, j'aime bien regarder la table de routage des Internets et comparer le nombre d'annonces v4/v6, le nombre d'AS v4/v6, la moyenne du nombre d'annonces v4/v6 par AS, ... C'est par ici que ça se passe. Normalement, ça se passe de commentaires.
• Les services ne sont pas disponibles en IPv6. Et là, je ne parle pas du top 10 des sites web les plus visités mais de la réalité, des sites que je visite très régulièrement. Faisons un tour rapide : les sites web des 3 banques que je connais : raté ; les sites web principaux des 3 universités que je connais et qui ont une formation orientée réseaux informatiques : raté ; les serveurs de mails que j'utilise : 1/5 = raté ; Parmi la centaine de flux RSS que je consulte tous les jours (et j'ai un profil atypique de passionné d'informatique qui consulte des sites de passionnés donc il y a un biais statistique ...) : 1/4 = raté. Et parmi ces sites web disponibles en IPv6, environ 3/4 le sont par un tunnel 6in4 comme Hurricane Electric. Note : pour les calculs relatifs aux flux RSS, je n'ai pas pris en compte les sites utilisant feedburner mais n'ayant pas une v6 pour leur site. Les contenus n'ayant rien en commun mais étant hébergés sur une même plateforme (Blogger, Twitter, ...) ne sont pris en compte qu'une seule fois.
• Mais IPv6, c'est aussi des gens pour le déployer et le maintenir. Je ne suis pas compétent pour estimer les personnes compétentes "en IPv6" sur le marché du travail. Par contre, je suis compétent pour "évaluer" l'offre de formation française. Une école d'ingénieurs en informatique ne le fait toujours pas étudier au niveau bac+4. Au-delà, je ne sais pas. Un IUT informatique ne le fait pas étudier en DUT Informatique. Une fac ne le fait toujours pas étudier au niveau bac+4 d'une formation informatique, au-delà, je ne sais pas. Une autre fac le fait étudier au niveau bac+4. Une dernière fac le fait étudier en M2 d'une formation orientée réseaux informatiques. Je n'ai pas eu de retour sur les formations professionnelles de type L3 Pro/Master Pro. Je sais que certains nuanceront ce point en disant que l'enseignement supérieur donne les bases et que c'est à l'étudiant de faire sa veille technologique. Je n'ai pas de problèmes avec ça. Juste pourquoi ne pas donner les bases v6 ?

J'ai du oublier des paramètres et des biais statistiques mais ça me semble toujours aussi mal parti pour qu'Internet soit majoritairement IPv6 demain. Au moins je ne suis pas tout seul à penser ça dans mon coin : IPv6, je t’aime mais tout le monde s’en fout chez iMil.

Ça commence à faire un petit moment que je n'ai rien posté. On va donc se faire un concentré d'astuces.

Table des matières

Copier/déplacer un dossier contenant beaucoup de petits fichiers

Quand vous tentez de déplacer un dossier qui contient vraiment beaucoup de petits fichiers (au hasard, le Buildroot complet d'OpenWRT), vous allez prendre du temps car le débit en écriture va s'effondrer à cause des petits fichiers. Pour peu que le support physique qui est en dessous soit un peu mou, la copie va vraiment s'éterniser.

On n'y pense pas assez souvent mais tar est notre ami. La création de l'archive (tar -cf destination.tar source/ ), même directement sur le support de destination sera largement plus rapide (on parle d'un gain de plusieurs dizaines de minutes dans mon cas). 7z s'est montré moins efficace. Pas contre, rien n'empêche de 7zippé une archive tar 😉 .

Dans le même ordre d'idée, un rm -rf dossier sera toujours plus rapide dans ces cas-là qu'une interface graphique.

Trier vos comptes de courrier sous Thunderbird/Icedove

La barre latérale gauche de Thunderbird vous montre vos comptes de courrier ainsi que leurs sous-dossiers. Si vous souhaitez trier l'ordre d'affichage de cette liste, il y a deux méthodes : le faire à la main dans le about:config ou le faire avec une extension.

Parmi les extensions existantes, ma préférence va à manually-sort-folders/manually-sort-folders qui fait juste ce qu'on attend d'elle.

Restreindre les droits de Wireshark

Pour utiliser Wireshark, il y a le bon vieux sudo que personne ne recommande et pour cause, lancer une GUI en root est une aberration car elle n'a pas besoin des droits acquis et qu'il s'agit donc d'un vecteur d'attaque supplémentaire. Il y a aussi la méthode qui consiste à exécuter seulement la dumpcap (la librairie de capture) en mode root en utilisant le setuid bit. C'est la méthode que j'ai toujours utilisée.

®om nous parle d'une autre méthode qui consiste à autoriser les membres d'un groupe d'utilisateurs bien défini à capturer les paquets.

Notez deux choses :

1. On a déporté les droits d'une application sur un groupe : n'importe quelle application lancée par l'utilisateur faisant partie du groupe aura donc la possibilité de capturer le trafic réseau.
2. Cette méthode permet de faire en sorte que la manipulation soit persistante : le setuid bit sur la dumpcap saute à chacune de ses mises à jour (sauf à utiliser dpkg-statoverride mais c'est une autre histoire).

Pensez à regarder les commentaires sous le billet de ®om pour y trouver d'autres manips sympas (capabilities ou le chaînage tcpdump/wireshark).

Ne pas être informé des mises à jour d'une extension WordPress

Quand une mise à jour pour un thème ou une extension que vous utilisez apparaît, WordPress vous le signale dans l'administration. C'est très bien. Sauf quand il confond une extension avec une autre. Non, Table of Contents Generator de Scott Yang n'est pas la même extension que Table of Contents Generator de Tim Carr (l'insertion d'une TOC ne se fait pas avec le même tag et il y a qu'un seul fichier dans la version de Scott Yang contre une multitude dans celle de Tim Carr, par exemple).

Jusqu'à peu, j'empêchais WordPress de m'informer d'une mise à jour de cette extension en modifiant son numéro de version dans le fichier source. Mais depuis peu, WordPress ne se laisse plus berner. J'ai donc recours à une extension qui bloque les notifications de mise à jour d'une extension en particulier. Parmi toutes les extensions disponibles pour ce travail, j'ai choisi Plugin updates blocker. Simple et efficace.

Attention toutefois à ne pas faire n'importe quoi : ce n'est pas une bonne idée de bloquer les notifications de MAJ de toutes vos extensions, par exemple. Entre autres, sachez que la non-mise à jour d'une extension peut entraîner des risques de compromission (sisi, ça c'est déjà vu). Mais quand l'extension dont vous désirez bloquer les notifications n'est plus maintenue depuis plus de 5 ans ...

Faire en sorte que les identifiants de Table of Contents Generator soient uniques

En effet, si vous utilisez un même titre dans deux de vos billets et que vous utilisez ToCG (de Scott Yang hein), vous aurez deux identifiants identiques. Exemple fictif : Pour deux titres "toto" dans deux billets différents, vous aurez http://www.guiguishow.info/2011/07/14/mon-super-billet/#toc-toto et http://www.guiguishow.info/2012/08/02/en-vrac-2/#toc-toto. Si les deux billets tombent sur la même page (index, catégories, archives, ...), cela posera quelques problèmes au navigateur, au validateur W3C et à l'utilisateur qui n'obtiendra pas ce qu'il voudra quand il cliquera sur le lien. En effet, un identifiant (ancre ou autre) doit être unique dans une page web.

L'idée est donc d'ajouter dans l'identifiant toc un élément variable et unique. L'ID du billet ? Dans l'exemple précédent, cela donnerait (toujours fictif) :http://www.guiguishow.info/2011/07/14/mon-super-billet/#toc-254-toto et http://www.guiguishow.info/2012/08/02/en-vrac-2/#toc-123-toto. Les identifiants seront uniques et plus aucune collision ne se produira si les billets tombent sur la même page.

Pour réaliser ce changement, il suffit de modifier une ligne de la méthode "get_tocid($text)" :
La ligne 26 :

return "toc-$tocid";

devient :

return "toc-$this->postid-$tocid";

Le code complet de la méthode devient donc :

function get_tocid($text) {
        $text = sanitize_title_with_dashes($text);
        $text = preg_replace('|%([a-fA-F0-9][a-fA-F0-9])|', '', $text);
        $tocid = $text;
        $count = 0;
        while (isset($this->tocmap[$tocid]))
            $tocid = $text.strval(++ $count);

        $this->tocmap[$tocid] = true;
        return "toc-$this->postid-$tocid";
}

La variable d'instance $this->postid est définie dans la méthode "the_posts($posts)".

À voir

Si vous ne vous êtes jamais penché sur eux, je vous conseille d'aller voir de plus près :

• OpenStreetMap (OSM) : Projet de cartographie mondiale libre. Je ne trollerai pas sur "pas complet"/"plus complet que"/"collaboratif donc pas fiable" car la messe est déjà dite avec Wikipédia (dans le sens où Wikipédia a été reconnue aussi fiable que les encyclopédies classiques) et ce billet de SebSauvage. Et quand je vois les arnaques sur les GPS commerciaux (30 jours max après achat pour mettre à jour les cartes avec un soft non libre, une seule mise à jour dans les GPS bas de gamme, les GPS haut de gamme mise à jour "à vie" limitées, ...), je ne peux pas m'empêcher de penser que si je m'achète un GPS un jour, alors ça sera un modèle sur lequel je pourrais mettre les cartes OSM. En attendant, j'ai déjà effectué quelques modifications de la carte de ma ville et il faut reconnaître que c'est facile à faire et rapide même avec l'éditeur en ligne.
• FRnOG : "Le FRench Network Operators Group (FRnOG) est un groupe d'échange d'informations qui rassemble des personnes intéressées par les domaines de la sécurité, la recherche et le fonctionnement d'Internet en France." Mélange entre information et troll, toute personne intéressée par le monde des réseaux se doit de suivre cette liste de discussion.

Quelques définitions basiques et simplifiées de termes employés chez les opérateurs

Quelques définitions à ceux qui débutent en "vrai" réseau ( 😉 ) car le net regorge de schémas et d'explication juste que des fois, il faut faire plus simple.

GIX | IX | IPX | Point d'échange : Lieu physique (généralement un datacenter) dans lequel des opérateurs s'interconnectent. Pour simplifier, il faut voir cela comme un gros switch sur lequel des opérateurs viendraient connecter un câble menant à leur réseau. Actuellement, beaucoup d'interconnexions se font sur Paris. Ce qui est une mauvaise chose puisque le trafic se concentre en un lieu avant d'être réparti localement. L'idéal serait de favoriser les GIX locaux entre plusieurs membres de la fédération.

Peering : Accord (souvent gratuit mais pas que) entre deux (ou plus) opérateurs pour s'échanger le trafic entre leurs réseaux de manière directe.
Avantages :

• Optimisation : route plus courte donc on diminue la latence.
• On gagne (un poil) en indépendance vis-à-vis de son transitaire : si le réseau de ce dernier tombe, on a encore nos routes vers les réseaux avec lesquels on a un peering.
• On augmente les interconnexions existantes entre plusieurs points et donc, on augmente la robustesse de l'Internet.

Dans la vraie vie, les opérateurs imposent des politiques de peering plus ou moins débiles (quota, “jeCausePasAuxPetits”, …).
Attention : le peering n'est pas transitif. Si A peer avec B et B peer avec C, A ne peer pas avec C et A devra donc avoir un transitaire pour faire le trajet A <> C.

Transitaire : Opérateur qui donne accès à tous les réseaux qui composent Internet. Cet opérateur peut faire des peering, acheter des routes, … mais l'important est qu'il doit fournir un accès complet. La question bête qui peut venir à l'esprit est : mais si tous les transitaires fournissent toutes les routes vers n'importe où, comment en choisir un plutôt qu'un autre ? On tombe là dans des problématiques de qualité des routes proposées. Exemple : vous êtes en France et vous avez le choix entre le transitaire A et le transitaire B. A peer avec les réseaux importants français (FT, Free, peu importe) à Paris. B peer avec ces mêmes réseaux à Amsterdam. Vous comprenez que, dans votre cas, A > B.

Porte de collecte : Point de sortie d'un tunnel L2TP.

Tunnel L2TP : Permet de récupérer les abonnés au BAS (= concentrateur en sortie de DSLAM) et de les acheminer jusqu'au réseau de l'opérateur desdits abonnés quand l'opérateur ne dispose pas de ses propres installations au niveau physique et local. Il faut voir ça comme un câble virtuel amenant l'abonné jusqu'au réseau de l'opérateur.

Note : ce contenu est disponible sur le wiki de la FFDN tout simplement car je l'y ai mis. Mais comme j'aime bien la redondance, je recopie ici.

Les différentes approches de la collecte ADSL

Attention : Cette page se veut simple et non-exhaustive. Son but principal est de répondre à la question “Pourquoi un FAI de FFDN ne prend pas en charge l'abonné de son routeur jusqu'à son réseau ?”.

Quel est le but du jeu quand on est FAI ? Amener un abonné à votre service jusqu'à Internet. Plus précisément, jusqu'à votre réseau, qui, comme d'autres, compose Internet. Ce qui n'est pas forcement clair, c'est qu'il y a plusieurs niveaux. Du plus indépendant au plus dépendant. On ne parle ici que d'ADSL et donc de collecte ADSL. La fibre semble ouvrir de nouvelles opportunités.

Tout faire soit même (du routeur de l'abonné jusqu'à votre réseau opérateur)

Vous êtes financé par une jeune et riche Nigérienne qui vient d'hériter de ses parents ( 😀 ) ?

Alors vous installez des DSLAM dans les NRA dans lesquels arrivent les lignes des abonnés qui vous intéressent. Ensuite vous avez votre propre BAS (= un bête concentrateur) raccordé à votre DSLAM, votre propre lien en fibre optique jusqu'à un datacenter dans lequel vous installez votre cœur de réseau (le routeur qui parle BGP, entre autres) et depuis lequel vous donnez accès au net grâce à des peering et des transitaires.

L'indépendance est totale (sauf vis-à-vis du(des) prestataires qui vous fournissent des chemins vers le reste d'Internet). Cette solution est fortement onéreuse : coût du DSLAM et du BAS, location des lignes de vos abonnés à FT, “loyer” pour installer votre DSLAM et votre BAS, …

Plus raisonnable

Faire appel à un opérateur de collecte qui vous livrera, en L2TP, vos abonnés dans un datacenter. Reste à trouver celui qui fait ça à un niveau local sans passer par Paris. Il y a eu coût à prévoir qui n'est pas à la portée du premier FAI local en construction venu.

#!/bin/sh -e
# Script to take DHCP configured NTP servers
# This heavily leverages the ntp script from dhclient-exit-hooks.d
 
if [ -z "$1" ]; then

    echo "$0: called with no interface" 1>&2
    exit 1;
fi
 
case "$2" in

    up|vpn-up)
 
	if [ -z "$DHCP4_NTP_SERVERS" ]; then

		logger "DHCP n'a retourné aucun serveur NTP."
		exit 1;
	else
		ntpdate $DHCP4_NTP_SERVERS
		if [ $? -eq 0 ]

		then
			logger "Synchronisation NTP effectuée."
			exit 0;
		else
			logger "Problème lors de la synchronisation NTP."

			exit 1;
		fi
	fi
	;;
    down|vpn-down)

	;;
    *)
	echo "$0: called with unknown action \`$2'" 1>&2
	exit 1

	;;
esac

[...]
 
if [ -r /etc/default/ntpdate ]; then
        . /etc/default/ntpdate
fi
 
# VIA DHCP
NTPSERVERS=$(nmcli -f DHCP4 dev list | grep ntp_servers | cut -d '=' -f 2)" "$NTPSERVERS
 
[...]

uci set dhcp.lan.dhcp_option=42,192.168.0.254

/etc/init.d/dnsmasq restart

uci set dhcp.lan.dhcp_option="42,192.168.0.254 66,tftpsrv.lan 67,tftp.bin"

/etc/init.d/dnsmasq restart
 
ou
 
uci add_list dhcp.lan.dhcp_option=42,192.168.0.254
uci add_list dhcp.lan.dhcp_option=66,tftpsrv.lan
uci add_list dhcp.lan.dhcp_option=66,tftp.bin
/etc/init.d/dnsmasq restart

Quand vous tentez de vous associer à un AP public (j'ai rencontré ce problème sur les réseaux FreeWifi et SFR Wifi Public), il peut arriver qu'aucune adresse ne vous soit attribué par le serveur DHCP. Parfois, et c'est encore plus fort, vous obtenez, sans rien toucher, une IP à peine 5 minutes après l'échec. Toujours plus fort : vous surfez tranquillement, vous êtes brutalement déconnecté et il vous est impossible d'obtenir une IP.

Je parle ici d'une utilisation raisonnable : vous avez toujours utilisé uniquement votre identifiant, vous ne l'avez pas prêté, vous n'avez pas tenté de faire une mauvaise action telle quelle soit, vous faites un fair-use du réseau (en terme de temps d'utilisation et en terme de quantité de données transférée), etc ...

De plus, je pars du principe que la réception du signal radio est bonne car le problème n'est clairement pas lié à une mauvaise réception ou à un système d'exploitation ou bien encore à un chipset wifi.

On peut émettre plusieurs hypothèses plus ou moins réalistes : plage IP totalement distribuée par le serveur DHCP, blacklistage de votre adresse MAC, doublon de MAC, DoS du serveur DHCP, ... Certaines hypothèses n'expliquent cependant pas certains des scénarios énoncés au début de ce billet.

Je connais au moins deux solutions pour avoir une IP quand un serveur DHCP refuse de nous servir :

1. Attribuer manuellement une IP à l'interface réseau. Inconvénients : il faut connaître le plan d'adressage du réseau et trouver une IP non utilisée.
2. Changer son adresse MAC pour une MAC générée au pif. Avantage : rien d'autre à faire.

Intuitivement, j'ai éliminé la première méthode et je ne l'ai jamais essayée car le problème m'a toujours semblé venir des couches inférieures. Je vous conseille donc la deuxième méthode. En effet, en changeant l'adresse MAC de mon interface wifi, j'ai constaté que, à chaque fois, le serveur DHCP du réseau wifi public (uniquement testé sur FreeWifi et SFR Wifi Public, pour rappel) se réveille et m'attribue une IP.

Petit rappel de la commande permettant de changer, jusqu'au prochain reboot, l'adresse MAC d'une interface réseau :

sudo ifconfig <interface> hw ether <nouvelle_MAC>

Un blocage par MAC de la part des opérateurs me semblait improbable : complexe à établir/maintenir, probabilité importante de faux positifs. De plus, l'adresse MAC "d'origine" de mon interface wifi est parfois acceptée, parfois refusée par la même borne dans un intervalle qui se compte parfois en minutes et parfois en jours.

Hé bah pourtant, il semble bien y avoir un filtrage MAC, chez Free en tout cas : il suffit de chercher et on trouve ça, ça et encore bien d'autres ... En revanche, je n'ai rien trouvé concernant SFR ...

Personnellement, vu les circonstances dans lesquelles ce problème apparaît chez moi, je tique encore sur la possibilité d'un filtrage MAC volontaire. Mais comme je ne peux fournir une explication complète et que la réponse des opérateurs (et surtout de Free) se fait visiblement attendre ...

À défaut d'être un billet technique, ce billet se propose de regrouper quelques-unes de mes découvertes plus ou moins récentes en informatique.

Table des matières

Différence entre un firewall stateless (pare-feu sans états) et un firewall stateful (pare-feu avec états)

Une bonne définition et une présentation détaillée de l'apport de sécurité amené par le stateful sont exposées ici (même si cette problématique n'est pas le thème majeur du billet) : Palo Alto Networks : Faut-il repenser notre vision du Firewall ? chez Guiguiabloc. Je rajouterai juste que le mode stateful permet une hausse des performances puisque les paquets appartenant à une connexion existante ne sont pas analysés "à fond" contrairement aux premiers paquets de chaque connexion.

Sécuriser un échange chiffré sur le long terme

Pourquoi vouloir sécuriser une connexion déjà sécurisée et temporaire, comme par exemple une session SSL/TLS, sur le long terme ? Imaginons simplement qu'une personne ou une organisation malveillante (pensez plus loin que les soit disant méchants pirates : autorités, prestataire réseau, ...) ait, un jour, l'occasion de faire un man-in-the-middle passif entre vous et un quelconque serveur avec lequel vous effectuez une connexion sécurisée : elle ne verra qu'une connexion chiffrée. Bien. Supposons maintenant qu'elle conserve votre échange avec le serveur et qu'un beau jour, elle soit en mesure de récupérer la clé privée du serveur (mauvais recyclage, saisie du serveur, ...) : elle sera en mesure de déchiffrer l'échange conservé. Afin d'éviter ceci, une méthode existe : le perfect forward secrecy (on peut traduire ça en "confidentialité persistante" ou en "confidentialité de transmission parfaite" mais je pense qu'il vaut mieux garder ça en anglais pour le coup). Cette technique s'applique aux protocoles d'échange de clé qui utilisent la cryptographie asymétrique (= à clé publique) et, de ce fait, aux protocoles utilisant ces derniers : SSL/TLS, SSH, IPSec, ... Notez que l’utilisation du perfect forward secrecy (PFS) est une option en SSL/TLS ou dans IPSec. Par contre, la version 2 de SSH, utilise, par défaut, diffie-hellman pour l'échange des clés et utilise donc le PFS.

Si cette méthode fait parler d'elle ces derniers temps, c'est tout simplement à cause de l'annonce de Google qui nous informe l'avoir mise en place sur ses services qui proposent un accès sécurisé (GMail, Google search, ...).

Je voulais donc profiter de l’occasion pour vous proposer d'en apprendre plus au sujet du PFS via ces deux sites :

• Perfect forward secrecy sur Wikipedia en
• SSL/TLS & Perfect Forward Secrecy chez Vincent Bernat. C'est en anglais mais très accessible (et si vous ne voulez pas faire un effort, une version française est également disponible : SSL/TLS & Perfect Forward Secrecy chez Vincent Bernat (FR)). Via GCU-Squad.

ÉDIT du 23/12/2011 à 17h50 :

J'ai modifié le paragraphe sur le PFS car il contenait un combo de boulettes. D'une part, le blog de Vincent Bernat est aussi accessible en langue française pour les irréductibles et d'autre part, le style d'écriture laissait entendre que le PFS n'était possible qu'avec SSL/TLS alors que je me servais uniquement de l'annonce de Google, qui pour le coup concerne uniquement SSL/TLS, pour évoquer le PFS.
Fin de l'édit

GNOME 3 - gestion de l'énergie et ordinateur portable - ne pas hiberner quand on ferme l'écran

Avec GNOME 2, il suffisait d'aller dans les paramètres systèmes. Plus aujourd'hui ... Qu'à cela ne tienne : utilisons gsettings :

$ gsettings set org.gnome.settings-daemon.plugins.power lid-close-ac-action blank

Dans la même veine, GNOME 3 ne laisse plus le choix de ne rien faire lorsque le niveau de la batterie atteint un niveau critique. Qu'à cela ne tienne (bis) :

$ gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action nothing

Et pour avoir une idée des autres paramètres disponibles pour la gestion de l'énergie, il suffit d'utiliser cette commande :

$ gsettings list-keys org.gnome.settings-daemon.plugins.power

Présentation de Netkit

À tous ceux qui veulent faire des expériences réseaux "sanstoutcasser", je recommande Netkit. J'avais déjà entendu parler de ce projet dans GNU/Linux Magazine France mais je ne l'avais pas testé. C'est aujourd'hui chose faite et je le recommande. Il ne me reste plus qu'à essayer quelques uns des intéressants labs proposés sur le wiki du projet.

Et pour faire, facilement, une capture réseau sur un lien entre deux machines d'un lab, c'est par ici : New package of uml_dump for netkit 2.7 chez Kartoch's Blog. Ce patch fonctionne encore tel quel avec la version 2.8 de Netkit.

ÉDIT du 28/02/2012 à 23h45 : Et pour ceux qui se demande quelle est la syntaxe de vdump, voici (copier/coller du Kartoch's Blog) : vdump <domaine de collision> | wireshark -i - -k . Pour trouver le domaine de collision entre deux machines d'un lab Netkit, il suffit de regarder le lab.conf. Par exemple, quel paramètre dois-je passer à la commande vdump pour écouter le trafic réseau entre pc1 et pc2 en fonction de l'extrait de lab.conf suivant ?

pc1[0]="A"
root[0]="A"
root[1]="B"
bidule[0]="B"

pc2[0]="A"

Réponse : vdump A | wireshark -i - -k
Fin de l'édit

ÉDIT du 23/12/2011 à 17h50 : Et pour ceux qui veulent une configuration plus poussée et/ou mieux comprendre comment ça se passe sous le capot, je vous propose de lire ceci : Labo virtuel avec User Mode Linux chez Vincent Bernat.
Fin de l'édit

Fichier avec des zones vides (sparse file)

À ceux qui se demande comment font les logiciels de virtualisation pour créer des disques dur de taille dynamique (transition depuis Netkit : done), ne vous posez plus la question : il s'agit de sparse files. Je vous dirige vers Wikipedia pour une définition : sparse file sur Wikipédia. Si vous souhaitez obtenir plus de renseignements, c'est par là : Sparse files – what, why, and how chez UNIX Administratosphere. Ce type de fichier est également utilisé par les utilitaires de sauvegarde. Par exemple : Clonezilla sauvegarde l'intégralité de votre disque dur, même les zones vides, sans pour autant créer une image disque de même taille (je ne parle pas d'une quelconque compression).

Pour ma part, j'ai fait le rapprochement entre le nom (sparse file) et les usages en lisant le "Kernel corner" du numéro de novembre 2011 de GNU/Linux Magazine France qui parle de deux nouvelles opérations ajoutées à l'appel système lseek dans la version 3.1 du noyau Linux : SEEK_HOLE et SEEK_DATA qui permettent, respectivement de se placer au début d'une zone vide ou d'une zone de données.

Pointeur de fonction : maFonction(void) != maFonction() ?

N'étant pas un as du développement logiciel (chacun son truc on va dire), je me posais une question toute simple : pourquoi ce code compile-t-il sans erreur ni avertissement ?

void maFonction(void (*f)(double)) { 
     ; 

}
 
void FUSR1() {
     ;
}
 
int main(void) {

     maFonction(FUSR1);
     return 0;
}

Pour ceux que cela intéresse, la réponse se trouve ici : Pointeur de fonction : maFonction(void) != maFonction() ? sur la catégorie "C" du forum du SdZ.

Masque de réseau identique ne signifie pas réseau identique

Récemment, j'ai dépanné une personne se plaignant que deux machines, soit disant sur le même réseau, ne puisse pas se pinger. Le problème venait en fait du fait que cette personne croyait que les deux machines étaient sur le même réseau alors qu'elles ne l'étaient pas. Elle se fiait au masque de réseau, pourtant identique.

Les machines avaient des IPs ressemblant à : 192.168.0.1/30 et 192.168.0.5/30. Un /30 suppose que le dernier octet soit composé de 6 bits pour l'adresse réseau et 2 bits pour l'adresse machine. Cela donne donc un masque égal à 255.255.255.252. Calculons le pas : 256 - 252 = 4. Toutes les 4 adresses, nous changeons donc de sous-réseau :

192.168.0.0/30 est l'adresse du premier réseau
192.168.0.1/30 est la première machine du premier réseau
192.168.0.2/30 est la deuxième machine du premier réseau
192.168.0.3/30 est l'adresse de broadcast du premier réseau

192.168.0.4/30 est l'adresse du deuxième réseau
192.168.0.5/30 est la première adresse du deuxième réseau

192.168.0.6/30 est la deuxième adresse du deuxième réseau
192.168.0.7/30 est l'adresse de broadcast du deuxième réseau

...

On voit clairement que les machines 192.168.0.1/30 et 192.168.0.5/30 ne sont pas sur le même sous-réseau et qu'une passerelle sera donc nécessaire pour les faire communiquer.

Ce qui m'a mis la puce à l'oreille pendant que je faisais les vérifications d'usage (cablage), c'est l'interrogation de la personne : "les masques sont identiques mais les adresses de broadcast sont différentes, je ne comprend pas comment c'est possible. Si elles ont le même masque, les machines sont sur le même réseau et elles devraient donc avoir la même adresse de broadcast".

Comment indiquer un port supérieur ou égal à 1024 dans iptables ?

Une autre question que l'on m'a posé récemment. Il suffit simplement d'utiliser la syntaxe "1024:". Exemple :

iptables -t filter -A OUTPUT -o eth0 -s 172.16.0.0/24 -d 192.168.0.5/32 -p tcp -m tcp --sport 1024: --dport 80 -m state --state NEW -j ACCEPT

Pourquoi Windows 7 ne voit pas le disque dur et ses partitions lors d'une réinstallation ?

Encore un dépannage étonnant 🙂 . L'ordinateur est équipé de Windows 7 Ultimate et d'Ubuntu tous deux installés par le propriétaire de la machine. Celui-ci souhaite réinstaller Windows 7 Ultimate en reformatant. Mais le programme d'installation ne détecte pas le disque dur et ses partitions.

Le mode AHCI est activé dans le BIOS mais cela ne devrait pas avoir d'importance puisque Windows 7 contient les drivers nécessaires. Je pars néanmoins à la recherche des drivers Intel AHCI et les mets sur une clé USB (voir le début de Adding Intel Matrix Drivers to Your XP Image for AHCI SATA Support chez Symantec Connect Community pour extraire les fichiers .inf de l'exécutable fourni par Intel). Windows les détecte bien mais affiche un message d'erreur en tentant de les charger. Encore plus fort : désactiver l'AHCI dans le BIOS ne résoud pas le problème !

Je pense pour un problème de disque dur et je démarre sur un live-cd de Gparted. Le disque dur se compose d'une partition de type inconnu de 200 Mo, de la partition dédiée à Windows, de la partition dédiée à Ubuntu et d'une partition dédiée au stockage des données. Mais à quoi sert donc cette partition de type inconnu ? L'utilisateur n'a pas le souvenir d'avoir créé cette partition ...

Doutant que la suppression de cette partition soit la solution au problème, je tente de cherche d'autres pistes. L'utilisateur m'incite à détruire la partition et je me laisse convaincre. Et le pire, c'est que cela fonctionne ! La suppression de cette partition a permis au programme d'installation de Windows 7 de détecter le disque dur et ses partitions contre toute logique (en même temps avec Windows ... je dis ça, je dis rien 🙂 ).

Je n'ai par contre aucune piste concernant l'origine de cette partition atypique ...

Et comme mot de la fin : écoutez les personnes que vous dépannez, elles n'ont pas toujours tords 😉 .