Mauvais serveur DNS en VPN Windows : métrique, ordre de liaison ou suffixe

Un client Windows peut avoir un tunnel qui fonctionne, porter le résolveur d’entreprise et continuer d’envoyer les noms internes au routeur domestique. Trois mécanismes différents décident quel serveur répond, et ils échouent de manières différentes. Il n’est pas nécessaire de corriger les trois : le symptôme vous dit lequel est en jeu. L’arbre de décision ci-dessous prend quelques minutes et évite l’issue habituelle, où un changement de métrique, une réorganisation du registre et une règle NRPT arrivent ensemble et personne ne sait laquelle a fait quelque chose.

Trois mécanismes décident, et en général un seul est faux

La métrique d’interface ordonne les adaptateurs pour une famille d’adresses. L’ordre de liaison sous Tcpip\Linkage est une liste d’identifiants d’interface valable pour toute la machine que les anciens chemins de code consultent encore. La table de stratégie de résolution de noms (NRPT) lie un espace de noms à des serveurs précis, et la liste de suffixes décide si un nom court est seulement développé. Ils sont indépendants, et c’est pourquoi un résolveur correct sur l’adaptateur VPN perd contre une préférence obsolète ailleurs.

Aucun de ces mécanismes n’est l’autre extrémité du tunnel. Si le serveur que le VPN pousse ne peut pas résoudre le nom, tout réglage côté client n’est que décoration, donc la première décision est de savoir si le résolveur lui-même peut répondre quand on l’interroge directement.

Décision un : le résolveur poussé peut-il seulement répondre ?

Interrogez le serveur explicitement et comparez avec une requête ordinaire. L’écart entre les réponses sépare un problème de sélection d’un problème d’atteinte, et c’est la bifurcation la plus rapide ici :

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Si la première réussit et la seconde échoue, le résolveur est joignable et Windows choisit mal ; allez aux décisions d’espace de noms et d’ordre ci-dessous. Si la première échoue aussi, rien sur le client n’aidera : vérifiez que UDP et TCP 53 atteignent le serveur par le tunnel, qu’aucun pare-feu de l’hôte sur le serveur ne rejette le pool, et que les redirecteurs du serveur lui-même sont sains.

Arrêtez-vous à cette bifurcation. Appliquer une règle NRPT à un résolveur que vous ne pouvez pas joindre produit la même panne avec plus de configuration à défaire, et elle cache la vraie faute derrière une règle qui paraît faire autorité.

Décision deux : un espace de noms, ou chaque requête ?

L’étendue décide de l’outil. Quand seuls les noms d’entreprise échouent, liez l’espace de noms au lieu de réordonner la machine : une règle NRPT envoie ce suffixe au résolveur du tunnel et laisse tout le reste tranquille. Quand chaque requête est touchée, le problème est la préférence globale d’adaptateurs, et la métrique est le bon point de départ parce qu’elle ne change aucun réglage serveur.

Réglez la métrique par famille d’adresses, sur les deux interfaces, puis confirmez l’ordre :

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Remplacez 11 par l’ifIndex de l’adaptateur du tunnel de la ligne ci-dessus ; si 11 est l’adaptateur LAN, la même commande abaisse le mauvais chemin. Relever plutôt l’adaptateur LAN atteint le même ordre par l’autre bout : netsh int ip set interface interface="Ethernet" metric=15, et netsh int ipv6 set interface interface="Ethernet" metric=15 pour la seconde famille, car int ip ne touche qu’IPv4.

L’ordre de liaison est le dernier recours et non le premier geste. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage contient une liste Bind d’identifiants de périphérique, et déplacer l’identifiant du tunnel en tête change bien quel adaptateur est interrogé en premier, mais c’est une valeur de registre propre à la machine, sans portée par espace de noms. Exportez-la avant de modifier et reconnectez le tunnel ensuite, pour que l’ordre s’applique dans l’état que le client attend.

Pour un seul espace de noms, préférez l’instrument le plus étroit :

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Décision trois : le correctif survit-il à une reconnexion ?

Une métrique qui tient jusqu’à la prochaine reconnexion par ligne commutée n’a jamais été enregistrée. L2TP/IPsec et les autres profils de connexion sont recréés au démarrage de la connexion, donc la valeur enregistrée vit dans l’entrée du carnet de téléphones sous IpInterfaceMetric, pas seulement sur l’interface active. Certains environnements scriptent ce champ pour cette raison même ; d’autres poussent la préférence depuis une stratégie de gestion et laissent le poste tranquille.

Le cache et l’enregistrement sont une couche à part. Les exécuter après la montée du tunnel corrige les entrées obsolètes et réenregistre le client, mais aucun des deux ne réordonne un adaptateur :

ipconfig /registerdns
ipconfig /flushdns

Il y a un interrupteur dans la même couche. Désactiver l’enregistrement dynamique sur l’adaptateur physique empêche le client d’annoncer son adresse côté VPN sous le mauvais nom, ce qui est une réparation différente de l’actualisation ci-dessus.

IPv6 mérite sa propre ligne dans la décision. Si l’adaptateur physique porte une adresse IPv6 globale alors que le tunnel ne transporte qu’IPv4, Windows peut préférer le chemin non tunnelé pour la résolution de noms. Vérifiez cette famille séparément, car une métrique réglée pour IPv4 ne dit rien d’elle :

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Désactiver IPv6 sur l’adaptateur LAN supprime ce chemin et le protocole avec lui ; un changement de métrique sur l’interface IPv6, ou une règle NRPT pour l’espace de noms d’entreprise, conserve la famille et corrige la préférence. Choisissez la plus étroite, sauf si vous avez décidé que ce lien ne doit pas avoir IPv6.

Vérifiez avec la source nommée, et gardez un seul propriétaire

Vérifiez avec des outils qui indiquent quelle source est en vigueur, pas seulement si une page se charge :

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Séparez ensuite le filtrage de la sélection, car depuis une application ils paraissent identiques. block-outside-dns d’OpenVPN bloque le port 53 sur les autres adaptateurs ; il ne choisit pas de résolveur. Si toutes les requêtes échouent maintenant, un filtre bloque peut-être le seul serveur joignable ; si le résolveur configuré est ignoré, l’ordre ou la règle d’espace de noms est faux. Changer les deux à la fois rend une requête bloquée et une requête ignorée indistinguables.

Gardez un seul propriétaire pour la stratégie DNS : le profil VPN, une stratégie de gestion ou une règle NRPT, pas deux d’entre eux. Avant de clore :

• Le résolveur poussé répond quand on le nomme explicitement, et une requête ordinaire l’utilise.
• La règle ou la métrique modifiée couvre la famille d’adresses qui porte réellement les requêtes.
• Le réglage survit à une déconnexion et reconnexion, ou vous l’avez déplacé dans le profil enregistré.
• Exactement un mécanisme fait autorité, et les autres ont été laissés tels quels.

Traitez l’ordre comme un état de l’environnement et non comme une chose que l’on termine. Revérifiez-le après une reconnexion et après une mise à jour de Windows qui touche la pile réseau, car l’une ou l’autre peut remettre l’adaptateur physique en tête.