Le kill switch ne bloque que l’IPv4 : pourquoi l’IPv6 s’échappe encore

Le tunnel tombe, le kill switch signale qu’il s’est déclenché et un téléchargement continue. Rien n’est cassé dans les règles IPv4. L’application s’est simplement déplacée vers un chemin pour lequel ces règles n’ont jamais été écrites.

Les appareils à double pile disposent de deux sorties indépendantes. Bloquer l’une d’elles revient à bloquer à moitié.

Deux jeux de règles, deux valeurs par défaut

Sous Linux, iptables et ip6tables sont des tables distinctes avec des politiques distinctes. Mettre les chaînes INPUT et OUTPUT de la table IPv4 sur DROP ne change rien dans la table IPv6, où la valeur par défaut est généralement ACCEPT. La même séparation existe dans nftables, où l’on peut inspecter une famille et constater qu’une seule d’entre elles porte vos règles. Cette asymétrie est normale, et c’est tout le problème.

C’est pourquoi un kill switch peut sembler complet et se comporter partiellement. Le script qui a écrit les règles IPv4 s’est exécuté, les compteurs s’incrémentent, la ligne de journal apparaît, et un paquet IPv6 quitte l’interface physique totalement intact.

Lisez ce que votre client installe réellement plutôt que ce que promet la page marketing. Certains clients routent l’IPv6 dans le tunnel, d’autres le bloquent délibérément, et d’autres le laissent tranquille tandis qu’un verrouillage au niveau de la plateforme applique une règle différente. La documentation du fournisseur est la seule source à laquelle se fier ici.

Ce que la configuration de l’interface vous apprend

La page de manuel de wg-quick inclut des règles IPv6 dans sa configuration d’exemple, et la raison est exactement cette lacune. L’exemple n’est pas décoratif. Il existe parce que les seules règles IPv4 laisseraient la seconde famille ouverte.

Copier la moitié d’un exemple produit la moitié d’une politique. C’est l’origine la plus courante de cette fuite. Un billet de blog a raccourci l’exemple pour des raisons de longueur. La version raccourcie est ensuite devenue le modèle que tout le monde a réutilisé.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Si la seconde commande affiche une politique permissive tandis que la première affiche DROP, vous avez trouvé la réponse sans toucher au client. Cette asymétrie est le défaut.

Pourquoi une seule résolution ne raconte pas tout

Un seul nom peut renvoyer à la fois un enregistrement A et un enregistrement AAAA, et les applications ne choisissent pas toutes de la même manière. Un navigateur peut préférer l’IPv6 lorsque le réseau le propose et revenir en arrière en cas d’échec, tandis qu’une synchronisation en arrière-plan ou un programme de mise à jour utilise son propre résolveur et sa propre préférence. Un test réussi en IPv4 prouve donc un chemin, pas la politique.

Les transitions réseau changent aussi la réponse. Rejoindre un autre réseau Wi-Fi, sortir de veille ou passer au réseau mobile peut donner à l’appareil un nouveau préfixe IPv6, et la politique qui semblait suffisante sur le LAN du bureau peut ne pas le couvrir.

Testez l’état où le tunnel est coupé

Tester pendant la connexion vous dit que le tunnel fonctionne. Le test intéressant est l’état indisponible, car c’est là que le kill switch est censé tenir. Arrêtez le tunnel volontairement, puis essayez les destinations qui comptent depuis l’application que vous protégez.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Les deux familles devraient échouer fermées. Si la requête IPv4 expire et que la requête IPv6 renvoie un code de statut, la politique est incomplète, et aucun retest du tunnel ne changera cela.

Conservez aussi les exceptions documentées dans ce test. La découverte du réseau local, un renouvellement DHCP ou le chemin d’amorçage vers le point de terminaison VPN peuvent avoir besoin de rester joignables, et ces exceptions devraient être nommées dans la politique plutôt que découvertes pendant une panne. Un test de fuite qui échoue parce que le tunnel ne peut pas revenir n’est pas une constatation de sécurité, c’est une constatation de connectivité.