Comme vous le pouvez peut-être pas deviner (je plaisante), j'ai des adresses IPv6 sous la main que je peux utiliser. Dans l'article précédent, j'avais dit que je me ferais une installation d'OPNsense sur mon réseau pour séparer le réseau des machines virtuelles du reste. Je vous ai également mentionné que j'avais quelques "projets" pour l'utilisation de ce routeur. L'adressage IPv6 en faisait partie. Jusque là, je vous rassure, tout fonctionne correctement, même si j'ai dû changer quelques plans d'origine avec Wireguard.

Prélude de l'histoire

J'ai un bloc IPv6 fourni par mon FAI donc, en théorie, même en pratique, je pourrais sans autres l'utiliser pour faire des enregistrements AAAA et ce serait un court article. Oui... mais non. Le préfixe donné est basé sur une IPv4 changeante. Comment dire que j'ai franchement pas envie de mettre à jour X enregistrements DNS AAAA quand une adresse IPv4 décide de changer.

Donc le domaine était disponible qu'en IPv4 "épicétou". Jusqu'au jour où un ami me propose un préfixe IPv6 /64 routé à travers un tunnel VPN Wireguard. Chouette !

Le choix porté sur Wireguard a principalement été motivé par la tolérance au changements d'IP d'un des points du VPN, en l'occurence le mien. Cette capacité à changer d'IP à la volée sans broncher à déjà fait ses preuves.

L'histoire avec Wireguard

J'ai essayé de mettre en place un tunnel Wireguard pour avoir le préfixe IPv6 sur OPNsense. Par contre, comment dire que la configuration était laborieuse ?

Je ne vais pas aller dans les détails tellement je m'étais perdu. Éventuellement, j'ai réussi à router avec une hache et ça fonctionnait plus ou moins correctement. Au moins, les paquets passaient sans soucis, avec des paramètres un peu "oh là, qu'est-ce qui se passe ?".

J'avais à ce moment-là, accrochez vos ceintures: 9.2234×10¹⁸ adresses à disposition parce que le routage à la tronconneuse, mais largement assez.

Puis j'ai remarqué quelques soucis de performance avec un débit plus bas qu'attendu. De ce que j'ai pu comprendre, Wireguard tournerait dans le userspace avec le package supplémentaire qui correspond pour OPNsense. Petit (gros) souci puisque Wireguard est fait pour s'exécuter dans le kernelspace. Alors il a fallu réfléchir à autre chose.

Debian rebonjour !

La réponse assez directe au souci, du moins de ce que je pensais, était de mettre en place une Debian qui s'occupera de faire ce qu'il faut avec Wireguard. Fort heureusement, pendant que je galérais avec OPNsense, j'avais mis en place une machine virtuelle qui ferait l'affaire. Donc passer de l'un à l'autre fut rapide et le routage a été fait proprement.

Certes, après analyse pour voir si j'ai changé quelque chose (spoiler alert: marginalement voire pas), il s'agit probablement du fait que la VM tourne avec qemu qui tourne dans le userspace de l'hyperviseur. Oups.

Le truc qui permet de router proprement

Je pense qu'il est un peu temps de révéler quelques détails que j'ai promis. Comme j'ai dit avant, j'ai un préfixe IPv6 qui est un /64. Je peux donc affecter...

• 2⁶⁴;
• 1.8447×10¹⁹;
• 18 446 744 073 709 551 616;
• dix-huit trillons quatre cent quarante-six billiards sept cent quarante-quatre billions septante-trois millards sept cent neuf millions cinq cent cinquante et un mille six cent seize; ¹

adresses. Oui, ça fait bizarre qu'on te donne un préfixe IPv6, sans se poser de questions, qui te permette d'avoir autant d'adresses !

Bref. Quel "truc" ai-je bien pu utiliser pour router proprement mon préfixe pour toutes les machines virtuelles ? L'astuce utilisée est de mettre l'adresse sur l'interface réseau faisant face aux machines virtuelles dont on veut assigner une adresse IP. Ensuite, j'ai paramétré Wireguard pour faire passer toutes les IPv6 au travers du tunnel, sinon le routage ne va pas jouer.

La configuration de mon côté ressemble à ça:

[Interface]
PrivateKey = [partie privée de votre paire de clefs]
MTU = 1380
# Pas d'adresse IP

[Peer]
PublicKey = [clef publique]
AllowedIPs = ::/0
Endpoint = [adresse IPv4:port]
PersistentKeepalive = 15

En plus, en paramétrant ainsi, le pare-feu sera automagiquement configuré et la table de routage aussi. N'est-ce pas merveilleux ?

Petit détail technique: le paquet IPv6 est emballé dans un paquet IPv4 et déballé à l'autre bout du tunnel. Ça fait bizarre de le dire mais on fait avec les moyens du bord, à défaut de faire autrement. Il se peut qu'il y ait un petit souci de MTU parce que je ne l'ai peut-être pas bien calculé. Peut-être que j'aurais même pas besoin de le réduire plus bas que ce que Wireguard met par défaut.

Je mets un KeepAlive explicite afin d'éviter des surprises avec un NAT. 15 secondes me semble raisonable comme intervalle. De plus, avec le KeepAlive, le second pair est au courant d'un changement d'adresse (si ça ne causait pas entre temps) et enverra les paquets au bon endroit.

Deux options en plus dans sysctl

On a le routage qui est correctement paramétrée par Wireguard parce qu'on a mis les bons paramètres. Mais si on essaye de faire passer un paquet avec le paramétrage actuel... ça passe pas.

En effet, le routeur reçoit bien le paquet mais ne le relaie pas parce qu'un paramètre, désactivé par défaut, nécessite d'être activé.

Pour ce faire, on va éditer le fichier /etc/sysctl.d/99-sysctl.conf et activer le transfert de paquets IPv6. On oublie pas de recharger avec sysctl -p.

Si on réessaye, les paquets passent comme il faut.

Router Solicitation - Router Advertisement

J'ai configuré un DHCPv6 pour attribuer des adresses IPv6 quand il n'y a pas besoin d'en mettre une en statique. Tout marche correctement jusqu'au moment où je tente de sortir du réseau, toujours avec des paquets IPv6. Tiens, rien qui passe. Alors j'ai sorti une arme redoutablement efficace pour débugger du réseau: tcpdump et Wireshark.

Je lance une petite capture sur des paquets ICMPv6. Qu'est-ce que je vois d'intéressant ? Des paquets Router Solicitation qui sont balancés sur le réseau et restent sans réponse. Sortir du réseau sans passerelle s'avère... compliqué, pour ne pas dire impossible.

Mais pas de panique, le daemon radvd (initiales pour Router ADVertisement) pourra répondre aux sollicitations de routeur avec une annonce.

Le ballet des paquets peut commencer !

Tout est en place est correctement configuré, que le ballet des paquets commence ! *regarde les paquets passer d'un endroit à un autre*

# traceroute -I6 searx.gnous.eu
traceroute to searx.gnous.eu (2001:67c:1740:900a::122), 30 hops max, 80 byte packets
 1  l4p1n.cust.infra.enpls.org (2a0e:e704:42:13::2)  0.215 ms  0.215 ms  0.230 ms
 2  gw.fr.infra.enpls.org (2a0e:e704:42:13::1)  19.487 ms  18.469 ms  19.712 ms
 3  gre0.ccr1072.core.brs.infra.ip6.milkywan.net (2a0b:cbc0:1::15d)  19.701 ms  19.810 ms  19.848 ms
 4  te1.ccr1072.core.th2.infra.ip6.milkywan.net (2a0b:cbc0:1::8d)  19.858 ms  19.848 ms  20.030 ms
 5  ve503-rt2-th2.bb.hivane.net (2001:67c:1740:8008::1)  20.594 ms  21.200 ms  21.202 ms
 6  ae0-3000-rt2-th2.bb.hivane.net (2001:67c:1740:1::65)  21.204 ms  20.302 ms  20.258 ms
 7  xe-0-0-3-rt-lyn.bb.hivane.net (2001:67c:1740:1::6a)  26.181 ms  28.077 ms  26.503 ms
 8  ricard.gnous.eu (2001:67c:1740:900a::122)  25.573 ms  25.591 ms  25.593 ms