Pourquoi nslookup résout via le VPN mais pas le navigateur

nslookup envoie une requête au serveur que vous nommez et imprime la réponse, c’est pourquoi il peut réussir alors que chaque onglet du navigateur échoue. Le navigateur demande au système d’exploitation de résoudre, et le système pèse les résolveurs par interface, les règles de stratégie de résolution de noms et l’emplacement réseau de l’adaptateur. Ensuite, le navigateur peut ajouter son propre DNS chiffré par-dessus. Trois chemins différents, un symptôme, et le tunnel n’est généralement pas la partie en panne.

Les vérifications ci-dessous suivent ces chemins du système vers l’extérieur. Ne modifiez pas le profil VPN avant de savoir quel chemin a répondu et lequel a échoué.

Trois stratégies décident de la réponse

Chaque interface porte sa propre liste de résolveurs et ses suffixes de recherche. Un adaptateur VPN ajoute des serveurs tandis que l’adaptateur physique garde les siens, et le système peut prendre celui qui répond en premier, si bien qu’une résolution peut être servie hors du tunnel sans que personne ne l’ait choisi. Les règles de la table de stratégie de résolution de noms peuvent envoyer des domaines choisis vers des serveurs choisis, ce qui est la façon habituelle d’exprimer le DNS séparé sous Windows. Et le client ou la passerelle VPN peut pousser une adresse de résolveur qui n’existe qu’à l’intérieur du réseau privé.

Ces trois interagissent de manières qui paraissent arbitraires depuis un navigateur. Un résolveur poussé à une adresse privée sans route à travers le tunnel séparé fait que chaque résolution se bloque puis échoue. Une règle de stratégie couvrant le suffixe interne et pointant vers un serveur arrêté produit la même erreur visible qu’une route absente. Un suffixe de recherche manquant sur l’adaptateur VPN transforme un nom court en requête publique pour le mauvais domaine. Chacun demande une réparation différente.

Pourquoi le navigateur pose une autre question

nslookup émet sa propre requête vers le serveur qu’il choisit et ne suit ni la stratégie d’espace de noms ni le réglage de DNS chiffré du navigateur. C’est pourquoi une requête manuelle vers un résolveur public répond alors que le navigateur signale que le site n’existe pas. Vous comparez deux programmes, pas deux états d’un même programme.

La préférence de famille d’adresses explique un délai, pas un échec. Un navigateur qui demande d’abord des enregistrements IPv6 sur un tunnel ne transportant que de l’IPv4 attend l’expiration du délai avant de reculer. Firefox a porté une préférence précisément pour cela, et la désactiver est une étape de diagnostic, pas une réparation.

Lisez la liste des résolveurs et les règles

Sous Windows, videz ce que le système détient avant de théoriser. Get-DnsClientServerAddress affiche les serveurs par interface, Get-DnsClientNrptRule liste les règles d’espace de noms, et Resolve-DnsName répond pour le nom exact par le chemin du système. Comparez cette réponse avec une requête directe vers le serveur du VPN par adresse. Quand Resolve-DnsName échoue et que la requête directe réussit, la liste des résolveurs ou une règle d’espace de noms est le suspect.

Vérifiez aussi le nom lui-même. Un nom court interne peut avoir besoin du suffixe privé que seul l’adaptateur VPN fournit, tandis que le nom pleinement qualifié se résout bien. Un avertissement de certificat après une résolution réussie relève d’un autre problème.

Le résolveur poussé injoignable

La passerelle ou le client peut pousser une adresse de résolveur, et cette adresse doit être joignable à travers le tunnel. Sur un tunnel séparé, la plage privée contenant le résolveur peut ne pas figurer dans les routes incluses, ce qui produit une résolution qui ne reçoit jamais de réponse. Confirmez que la route existe, puis interrogez cette adresse précisément, à travers le tunnel. C’est la panne derrière une erreur de domaine dans le navigateur alors qu’un résolveur public répond encore.

Si le résolveur est injoignable, la réparation est une route ou un sous-réseau inclus, pas un autre serveur DNS.

Le DNS chiffré contourne tout le chemin

Les navigateurs dotés de DNS-over-HTTPS résolvent eux-mêmes les noms via une connexion HTTPS vers un fournisseur choisi. Quand c’est activé, le résolveur du système et les règles de DNS séparé sont entièrement contournés pour ces résolutions, si bien que les noms internes échouent dans le navigateur alors que le système d’exploitation les résout correctement. L’inverse se produit aussi : des noms internes réussissent dans le navigateur via un fournisseur qui n’aurait jamais dû les voir, et c’est un problème de stratégie, non de connectivité.

Décidez délibérément si le DNS chiffré est autorisé sur les appareils gérés, puis configurez-le via la surface de gestion du navigateur pour que le choix soit visible. Le laisser aux préférences individuelles produit un parc où le même VPN se comporte différemment sur chaque portable.

Des réparations adaptées à la panne

Si le VPN pousse son résolveur, faites en sorte que le tunnel transporte le trafic vers lui et que le même réglage soit visible sur les adaptateurs qui participent à la résolution. Si les sites locaux cessent de se résoudre lorsque vous êtes connecté, ajoutez des exceptions d’espace de noms explicites ou un redirecteur conditionnel au lieu de remplacer le résolveur en bloc. Si le DNS chiffré du navigateur contourne la stratégie, c’est le réglage à changer. N’ajoutez jamais un résolveur public pour corriger un nom interne : il fuite des requêtes privées et ne résout pas le nom.

Séparez ensuite la résolution de la connexion. Un nom qui se résout vers la bonne adresse mais refuse une connexion est un problème de service, de pare-feu ou de certificat, et des changements DNS ne le corrigeront pas.

Notez quel chemin a répondu, lequel a échoué et ce que vous avez modifié. Le prochain rapport du même symptôme coûtera alors une commande au lieu d’un après-midi.