Pourquoi Windows envoie les noms de votre VPN à un serveur DNS que vous n'avez jamais configuré

Vous définissez le serveur DNS sur l'adaptateur VPN, vous vous reconnectez, et le nom privé revient toujours du résolveur du bureau que personne n'a configuré sur ce portable. Le résultat donne l'impression que le réglage a été ignoré, et d'une certaine manière il l'a été, car la liste des adaptateurs est un ensemble de candidats et non une décision. Windows résout les noms via une stratégie d'espace de noms qui peut désigner un autre serveur pour un suffixe donné, et cette stratégie s'applique avant que le réglage de l'adaptateur soit consulté. Trouver la règle qui a gagné est l'affaire de cinq minutes une fois qu'on sait quelle table lire.

Ce que vous avez changé, et ce qui décide réellement

L'adresse DNS d'un adaptateur indique au client où cette interface pourrait envoyer des requêtes. La table de stratégie de résolution de noms indique au client où il doit envoyer les requêtes pour un espace de noms donné, et elle est évaluée par nom, pas par adaptateur. Quand une règle correspond au suffixe saisi, les serveurs de la règle sont utilisés et la liste des adaptateurs cesse d'avoir de l'importance pour cette résolution.

C'est pourquoi deux noms sur le même portable peuvent suivre des chemins différents au même instant. Un hôte sous le suffixe d'entreprise suit sa règle ; un nom public suit le chemin par défaut, ce qui signifie généralement l'adaptateur qui répond en premier.

Comment la table associe un nom

Les règles sont indexées par espace de noms, et la correspondance la plus précise l'emporte. Une règle pour corp.example s'applique à vpn.corp.example et ne s'applique pas à example.net. Une règle avec l'espace de noms . couvre tout ce que les autres règles ne couvrent pas, ce qui en fait l'entrée la plus dangereuse de la liste et celle qu'il vaut la peine de vérifier quand un site sans rapport se résout par le tunnel.

Une règle peut aussi porter un commentaire, une stratégie qui désactive l'entrée et des paramètres de sécurité sans rapport avec les adresses DNS. Une règle désactivée reste visible dans la configuration sans aucun effet, si bien qu'une entrée qui semble correcte sur le papier peut rester inerte après un changement de profil.

Lisez la table effective, pas la liste de souhaits

Les règles configurées et les règles effectives sont deux questions différentes. Get-DnsClientNrptRule énumère ce qui existe sur la machine. Get-DnsClientNrptPolicy -Effective montre ce que le client appliquera réellement, avec les valeurs fusionnées de la stratégie et des paramètres locaux.

Comparez le suffixe de cette sortie avec le nom que vous testez, caractère par caractère. Une règle pour corp.example ne capture pas un nom se terminant par corp.example.com, et un point final à un endroit et pas à l'autre suffit à changer la correspondance.

Sans règle, Windows interroge plus d'un adaptateur

Quand rien dans la table ne revendique le nom, le client peut envoyer la requête par plusieurs interfaces et retenir la première réponse qui arrive. Le résultat dépend du moment : le même nom peut se résoudre depuis l'adaptateur filaire le lundi et depuis le tunnel le mardi, et rien dans la configuration de l'un ou l'autre adaptateur n'explique la différence.

Il existe deux issues. Ajoutez une règle pour l'espace de noms afin que la décision cesse d'être une course, ou désactivez le comportement parallèle via la stratégie de client DNS et acceptez une résolution plus lente et déterministe. La première convient généralement mieux à un VPN à tunnel divisé, car elle documente l'intention au lieu de dépendre de l'ordre.

Des chemins qui contournent entièrement le résolveur

Un navigateur avec DNS sécurisé activé résout lui-même et ne transmet à Windows que l'adresse, si bien que la table des règles ne voit jamais le nom. Les clients construits sur des environnements dotés de leur propre résolveur peuvent se comporter de la même façon. Quand un nom se résout dans une application et échoue dans une autre sur la même machine, comparez les deux chemins de résolution avant de toucher à la stratégie.

Vérifiez aussi si l'application se connecte à une adresse en cache d'une session précédente. Clear-DnsClientCache puis la même recherche donne une réponse plus nette que de la déduire d'un résultat ancien.

Testez avec le nom qui a échoué

Résolvez le nom d'hôte exact du rapport, pas un domaine public de test de débit, et notez quel serveur a répondu. Changez ensuite une seule chose : la règle, la liste des adaptateurs ou l'affectation de stratégie, puis répétez la même recherche après une reconnexion pour que l'état appliqué soit reconstruit.

Si le nom se résout et que le service refuse toujours, arrêtez de modifier le DNS. L'étape utile suivante est l'adresse et la route vers celle-ci, car la résolution de noms a déjà fait son travail.