VPN double pile : c'est le client qui choisit la famille d'adresses, pas vous

Le tunnel est monté, les sites IPv4 se chargent et un nom d'hôte expire. La conclusion immédiate est que le VPN est en panne ou que les identifiants sont faux, et ni l'un ni l'autre n'est généralement vrai. Le nom a renvoyé à la fois une adresse IPv4 et une adresse IPv6, l'application en a choisi une, et un seul de ces candidats avait un chemin fonctionnel. C'est le client qui a pris la décision de sélection ; le tunnel ne couvrait tout simplement pas ce qu'il avait sélectionné.

Choisir n'est pas promettre une couverture

La sélection d'adresse par défaut, décrite dans la RFC 6724, décide quel couple source-destination un hôte préfère lorsque plusieurs sont disponibles. Happy Eyeballs ajoute par-dessus une stratégie de connexion : il lance des tentatives sur les deux familles et garde celle qui répond en premier, afin que l'utilisateur n'attende pas qu'une famille en panne expire.

Aucun des deux mécanismes ne crée de route. Si votre tunnel ne transporte que de l'IPv4, un candidat AAAA reste une destination légitime que le client peut essayer, et l'échec se manifeste par un chargement lent plutôt que par une erreur, parce que le navigateur est retombé sur ses pieds. L'utilisateur signale un site lent, pas cassé, et le ticket de support hérite de ce flou. Reproduisez-le avec une famille fixe et le rapport devient précis.

C'est ce repli qui rend le symptôme incohérent d'une application à l'autre. Un navigateur masque le délai ; un client en ligne de commande avec une famille fixe vous montre l'échec réel immédiatement.

Trouvez la famille que la requête a réellement utilisée

Commencez par le nom, pas par le tunnel. Interrogez les deux types d'enregistrement et notez ce qui est revenu :

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Si la requête v4 réussit et que la requête v6 échoue, vous avez reproduit le problème sous une forme que vous pouvez déboguer. Si les deux réussissent depuis le shell et que le navigateur échoue encore, examinez le résolveur propre à l'application ou une réponse en cache avant de toucher au tunnel.

Gardez la famille et la destination dans vos notes. Un ticket qui dit que le site ne se charge pas via le VPN ne peut être vérifié par personne, tandis qu'un ticket qui dit qu'AAAA échoue et que A fonctionne pointe vers une route précise.

Vérifiez la route de cette famille

Pour la famille qui échoue, demandez au noyau quel chemin il utiliserait et comparez-le aux adresses configurées du tunnel. Sous Linux, ip -6 route get pour la destination affiche l'interface et la source qui seraient choisies.

Vérifiez ensuite le tunnel lui-même. Les pairs WireGuard portent une liste d'IP autorisées, et une entrée pour 0.0.0.0/0 ne dit rien sur l'IPv6. Si la liste du pair n'a aucun préfixe IPv6, le client n'a aucune raison d'envoyer du trafic AAAA dans le tunnel, et le paquet sort par ce que l'hôte ferait autrement.

Les règles de pare-feu et la politique NAT méritent la même vérification par famille. Une règle écrite pour IPv4 ne couvre pas l'IPv6 sur aucune plateforme, et c'est la raison la plus fréquente pour laquelle une famille fonctionne et l'autre non.

Ne désactivez pas l'IPv6 pour simplifier la capture d'écran

Désactiver l'IPv6 à l'échelle du système fera disparaître le symptôme et vous laissera sans diagnostic. Cela casse aussi toute destination qui n'est qu'IPv6, et cela masque le même bogue pour l'application suivante. Si une machine ne doit vraiment pas utiliser l'IPv6, c'est une politique délibérée avec un responsable et un test. La désactiver pendant un incident n'est ni l'un ni l'autre.

Décidez ce que le client doit faire de la famille et configurez-le explicitement: faites-la passer par le tunnel, ou bloquez-la d'une manière prise en charge pour que la sélection n'offre jamais un candidat injoignable. Les deux sont des conceptions légitimes. Une désactivation globale n'est ni l'une ni l'autre, car ce n'est pas une conception du tout.

Ce qu'il faut mettre dans le ticket

Notez quatre choses : le nom d'hôte, la famille qui a échoué, la route choisie par le noyau et le résultat d'une requête propre à la famille. Cet ensemble suffit à quelqu'un d'autre pour reproduire l'échec sans deviner lequel des deux chemins vous vouliez dire.

Les règles de sélection d'adresse de la RFC 6724 expliquent pourquoi le client a préféré le candidat qu'il a préféré, et la RFC 8305 explique le comportement de course qui a masqué le délai. Aucune des deux ne routra un paquet pour vous, et c'est la partie que le tunnel doit assurer.