Comment vérifier l'état IPv6 d'un Mac après la déconnexion du VPN

Atteignez un site en IPv4 après la chute du tunnel et vous n'avez rien prouvé sur IPv6. macOS configure les deux familles séparément, par service réseau, et un client VPN peut modifier l'une sans toucher l'autre. Travaillez les trois couches dans l'ordre : configuration de l'adresse, sélection de la route, puis toute politique que le client installe pendant la déconnexion. Gardez le réseau d'accès inchangé entre-temps, sinon vous comparerez deux problèmes différents.

Commencez par la famille qui a réellement échoué

Une page qui se charge en IPv4 vous dit que le réseau physique est vivant. Elle ne dit rien sur la présence d'une adresse IPv6 globale sur le service, sur la diffusion éventuelle du préfixe ou sur un filtrage de la famille. Confirmez ce qui a échoué avant de choisir un outil, car un nom qui résout vers une adresse injoignable ressemble exactement à un nom qui ne résout pas du tout. Demandez quelle couche a mal répondu et écrivez la réponse. Sans cela, chaque étape suivante est une supposition habillée en procédure.

Gardez le même réseau Wi-Fi et le même point d'accès pendant toute la comparaison. Un réseau de café qui proposait IPv6 hier ne dit rien de celui sur lequel vous êtes maintenant.

Lisez l'adresse avant la route

Dans Réglages Système, le panneau TCP/IP du service actif indique si IPv6 est automatique, manuel ou seulement local au lien. Comparez cela à ce que vous attendez, en gardant à l'esprit qu'une organisation a pu choisir la configuration manuelle délibérément. Exécutez ensuite ifconfig et lisez l'interface concernée. Une adresse fe80:: seule signifie que l'interface peut parler à ses voisins et rien de plus, donc la présence d'une adresse locale au lien n'est pas la preuve d'un chemin utilisable.

Cherchez aussi les interfaces utun laissées par le client. Un périphérique de tunnel obsolète peut conserver une adresse et une route longtemps après que le client a cessé de l'utiliser. S'il en existe un, c'est une constatation de cycle de vie pour le propriétaire du client, et non quelque chose à supprimer sur-le-champ.

Lisez la table de routage pour la destination défaillante

Interrogez le noyau sur la destination qui a échoué, pas sur la route par défaut. route -n get 2001:db8::25 affiche l'interface et la passerelle choisies pour cette adresse, et netstat -rn -f inet6 montre toute la table pour comparaison. Une route par défaut vous dit qu'une route par défaut existe ; elle ne dit pas que cette destination l'utilise.

Gardez le DNS dans son compartiment. Un résolveur joignable en IPv4 peut encore renvoyer des enregistrements AAAA, donc un échec de résolution et un échec de routage produisent le même symptôme dans le navigateur.

Séparez la politique de blocage du client d'un reliquat

Certains clients sont conçus pour bloquer le trafic pendant la déconnexion, y compris l'autre famille d'adresses, et ce comportement est une fonctionnalité, pas un défaut.

Découvrez quel comportement votre client documente avant de traiter un blocage comme un dommage. scutil --dns montre les résolveurs en vigueur par service, et c'est là qu'un résolveur installé par le client ou un réglage DNS restreint devient visible. Vérifiez ensuite si des règles de filtrage de paquets ont été installées et laissées en place. Un blocage attendu et une règle résiduelle exigent des réponses opposées, et seule la documentation du propriétaire les distingue.

Rassemblez des preuves, puis changez une seule chose

Consignez la version du client, la version de macOS, le service réseau, la politique de déconnexion prévue et la sortie des adresses et des routes des deux côtés d'un cycle de connexion-déconnexion. C'est cette consignation qui transforme une plainte en problème de cycle de vie qu'un tiers peut examiner. Faites ensuite un seul changement et mesurez à nouveau.

Résistez à la réinitialisation. Supprimer les interfaces virtuelles, vider la table de routage et désactiver IPv6 sur toute la machine détruisent l'état qu'il fallait capturer, et peuvent emporter une configuration sans rapport. Si le client propose un parcours pris en charge de pause, de réparation ou de désinstallation, utilisez-le, et suivez la procédure de l'administrateur là où le réseau est géré. Une machine déjà réinitialisée ne laisse rien à exploiter au propriétaire, et elle reproduit généralement la panne à la connexion suivante.