VPN connecté mais les noms échouent : où le DNS casse vraiment

Tunnel établi, icône verte et chaque onglet du navigateur signale un échec de résolution de nom. Trois mécanismes différents produisent cette image : le résolveur peut être injoignable, le client peut interroger un résolveur que vous n'attendiez pas, ou seuls les noms privés peuvent échouer. Séparez-les avant de changer quoi que ce soit au protocole du tunnel, car chacun se répare à un endroit différent. L'ordre ci-dessous commence par les observations qui distinguent les trois.

Ce dont une requête a vraiment besoin

Une requête a besoin de trois choses : une adresse de résolveur, une route vers cette adresse et une réponse qui correspond à la question. Chacune peut échouer seule, et le symptôme visible est la même page qui ne se charge pas. C'est pourquoi la page d'erreur ne vous dit presque rien tant que vous ne savez pas laquelle des trois s'est cassée.

Le client apprend son résolveur depuis le profil VPN, depuis le DHCP du tunnel ou depuis sa propre configuration, et la source qui l'emporte dépend de la plateforme. Sous Windows, ipconfig /all liste les serveurs DNS par adaptateur, vous voyez donc si la valeur poussée est réellement arrivée. Une valeur poussée qui n'a jamais atteint le système d'exploitation est une panne silencieuse et courante. Lisez la valeur configurée avant de toucher au profil.

Linux et macOS répondent à la même question avec des commandes différentes, et la réponse mérite la même lecture : resolvectl status et scutil --dns listent tous deux les serveurs par interface. Comparez cette liste à l'adresse que le profil prétend pousser. Une incohérence ici explique tout ce qui suit, réglez-la donc avant de tester des noms.

Testez un nom public et un nom privé

Interrogez un nom d'hôte public ordinaire et le nom d'hôte privé documenté depuis la même machine, et notez quel serveur a répondu à chacun. Si les deux échouent, le résolveur ou sa route est cassé. Si seul le nom privé échoue, le résolveur a répondu et la question devient la zone ou le routage. Lancez les deux requêtes à moins d'une minute d'intervalle pour qu'un changement de route ne puisse pas expliquer la différence.

Gardez les noms internes hors des captures d'écran publiques et hors des résolveurs publics. Un délai d'attente et une réponse de domaine inexistant sont des observations différentes : la première dit que rien n'est revenu, la seconde qu'une autorité a répondu que le nom n'existe pas. Les traiter comme une seule erreur vous envoie à la mauvaise couche, et un avertissement de certificat est encore une troisième chose, pas une panne DNS.

nslookup affiche à la fois le serveur interrogé et la réponse reçue, et c'est exactement la paire qu'il vous faut. Exécutez-la deux fois dans le même shell et notez l'adresse qui répond à côté de chaque réponse.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Vérifiez que le client peut réellement joindre ce serveur

Un résolveur privé poussé par le profil n'est utile que si le client peut le joindre pendant que le tunnel est établi. Une adresse d'apparence correcte sans route produit un délai d'attente, et l'état connecté du tunnel ne dit rien de cette route. La vérification est une recherche de route visant le résolveur lui-même, pas le point de terminaison VPN.

Chaque plateforme répond à cela en une ligne, et l'interface nommée dans la sortie est toute la réponse. Si elle pointe vers l'adaptateur physique alors que le résolveur se trouve derrière le tunnel, le profil ne pousse pas de préfixe qui le couvre.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Sur un profil à tunnel divisé, le résolveur peut se trouver hors des routes poussées, ce qui est un problème de profil et non de serveur. Comparez l'adresse du résolveur aux préfixes poussés et confirmez que l'un d'eux le couvre. La même incohérence explique pourquoi le DNS fonctionne sur un réseau et échoue sur un autre avec un profil identique.

N'oubliez pas que les navigateurs peuvent contourner le résolveur du système

Un navigateur avec le DNS sécurisé activé peut envoyer des requêtes via HTTPS à un fournisseur de son choix et ignorer entièrement le résolveur du système d'exploitation. Le système semble alors correct tandis que le navigateur échoue, ou l'inverse. C'est une question de politique pour le navigateur, pas pour le tunnel.

Vérifiez le réglage DNS sécurisé du navigateur et toute politique gérée qui le contrôle, puis essayez une seconde application ou un second navigateur avec le tunnel inchangé. Si une seule application échoue, la correction appartient à cette application. Une fenêtre privée n'est pas une comparaison propre, car elle peut désactiver les extensions par défaut dans un navigateur et pas dans un autre, et elle ne contourne jamais une politique gérée. Utilisez plutôt un second profil de navigateur ou une autre application.

Videz le cache et retestez la vraie tâche

Après avoir corrigé un réglage, videz le cache local du résolveur pour qu'une ancienne réponse ne survive pas à la correction. Un bref rétablissement suivi d'un nouvel échec signifie que la cause est toujours là, pas que le vidage a échoué. Choisissez la ligne qui correspond à la machine sur laquelle vous êtes, car les trois caches sont séparés.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Répétez ensuite la tâche d'origine plutôt qu'une requête synthétique, car la tâche est ce qui intéresse l'utilisateur. Reconnectez-vous une fois aussi, pour que le retest couvre l'état dans lequel l'utilisateur se trouvera réellement. La référence nslookup de Microsoft est la page à conserver pour les arguments de la requête.

Si les noms n'échouent qu'après une déconnexion, le client n'a pas restauré la configuration précédente, ce qui est un bug de cycle de vie à signaler, et non un serveur DNS à remplacer. Une requête qui fonctionne n'est pas non plus un test de fuite, car le pays de sortie ne vous dit rien du résolveur qui a répondu.