Un réseau uniquement IPv6 casse le VPN avant même le démarrage du tunnel

L’ordinateur portable se connecte à un Wi-Fi de conférence qui ne distribue que de l’IPv6, le client VPN tourne puis échoue, alors que le même profil fonctionnait dans un hôtel une heure plus tôt. Rien n’a changé côté identifiants. Ce qui a changé, c’est que le client doit désormais joindre une destination IPv4 à travers un réseau qui ne transporte que de l’IPv6, et tous les clients ne savent pas le faire.

Suivez les cinq mêmes étapes que les paquets.

Étape 1 : observez la résolution de nom

Si le profil utilise un nom d’hôte, la première question est ce que renvoie le résolveur. dig AAAA vpn.example.com sur le réseau uniquement IPv6 renvoie un véritable enregistrement AAAA, un enregistrement synthétisé par DNS64, ou rien du tout. Une réponse synthétisée encode la destination IPv4 dans un préfixe de traduction, et c’est seulement alors qu’un client sans destination IPv6 peut l’atteindre. Un profil avec une adresse IPv4 codée en dur n’arrive jamais jusque-là, car il n’y a aucun nom à synthétiser.

Cette seule différence explique la plupart des rapports « ça marche là-bas, ça échoue ici », et une seule commande suffit pour le voir.

Étape 2 : voyez quelle famille le client a appelée

Regardez la socket plutôt que la barre de progression. Un client qui ouvre une socket IPv4 vers une adresse IPv4 sur une liaison uniquement IPv6 n’a nulle part où l’envoyer, et l’échec se manifeste par un délai d’attente et non par une erreur de nom. ss -tanp pendant la connexion du client montre l’adresse distante et la famille tentée. Comparez avec ip -6 route pour confirmer que la route par défaut est un vrai saut suivant IPv6.

La famille d’adresses dans la table des sockets est le fait. La barre de progression est un résumé que quelqu’un d’autre a écrit.

Étape 3 : séparez la traduction du tunnel

NAT64 et DNS64 sont la façon dont le réseau d’accès atteint les destinations IPv4, et ils ne font rien pour le tunnel une fois qu’il est monté. Un tunnel établi sur un chemin traduit négocie toujours son propre adressage interne, et la couverture interne IPv4 ou IPv6 est une question de politique distincte. Si le client se connecte puis n’atteint rien, vous êtes au-delà de la traduction et dans le routage, ce qui est une autre enquête avec d’autres preuves.

Un échec de traduction ressemble à une absence de connexion. Un échec de couverture interne ressemble à une connexion qui n’atteint rien.

Étape 4 : testez le même profil sur un autre réseau

Emportez le même profil, la même version de client et les mêmes identifiants sur un réseau double pile et recommencez. Si cela fonctionne là-bas et échoue sur le chemin uniquement IPv6, la variable est le réseau d’accès et non le profil. Notez la version du client et l’état du réseau dans le ticket, car la correction finale est une mise à jour du client ou une autre destination.

Un rapport disant que le VPN est cassé n’est pas exploitable. Un rapport disant qu’il échoue uniquement en accès uniquement IPv6 est un rapport de bogue.

Étape 5 : corrigez le chemin, pas les réglages de sécurité

Toutes les réparations tentantes aggravent les choses. Désactiver l’IPv6 supprime le seul chemin que le réseau offre. Pointer le client vers un résolveur public casse la synthèse DNS64, car cette synthèse doit venir du résolveur situé derrière le traducteur. Désactiver la vérification des certificats vous donne une connexion vers quelque chose que vous ne pouvez pas identifier. Aucune de ces solutions n’est une correction, et deux d’entre elles sont des régressions de sécurité qui survivront à l’incident.

Les vraies options sont un client qui prend en charge le modèle de traduction réseau, ou une destination avec une adresse IPv6 joignable. Demandez l’une des deux.