Configurer le DNS sur un adaptateur VPN Windows avec PowerShell, puis vérifier

Une connexion VPN Windows ne stocke pas les serveurs DNS dans le profil que vous modifiez dans Paramètres. Quand le tunnel monte, le client négocie la configuration IP avec la passerelle, la passerelle pousse une liste de résolveurs, et Windows l’applique à l’adaptateur du tunnel. Cet adaptateur est une interface distincte de votre Wi-Fi ou Ethernet, et la liste appartient à l’interface, pas au profil. Une fois que vous savez quel objet possède la valeur, la remplacer dans PowerShell est une commande ; faire survivre le remplacement à une reconnexion est la partie qui demande une décision.

Quel objet possède l’adresse

RAS crée l’adaptateur du tunnel quand la connexion réussit et le supprime quand la connexion tombe. Les serveurs DNS que vous voyez dans ipconfig /all arrivent pendant cet échange de configuration, à côté des adresses IPv4 et IPv6 et des routes. Comme la valeur est attachée à l’interface, Set-DnsClientServerAddress écrit dans quelque chose qui n’existe que tant que la connexion existe.

Ce seul fait explique la majeure partie de la confusion autour du DNS VPN. Un profil peut être inspecté hors connexion, mais il n’y a aucune interface à désigner, donc un script d’ouverture de session qui appelle la commande contre l’alias VPN échoue avant que quiconque se soit connecté. Il explique aussi un changement qui semble revenir en arrière : rien n’est revenu, l’interface a été détruite et reconstruite avec les valeurs poussées par la passerelle.

Trouvez l’alias avant de toucher au DNS

Le nom du profil et l’alias de l’interface sont généralement la même chaîne, mais ce ne sont pas le même objet. Get-VpnConnection répertorie les profils ; Get-NetAdapter répertorie les interfaces que Windows possède réellement. Les commandes DNS veulent la seconde, et les deux divergent plus souvent qu’on ne l’attend, surtout quand le client ajoute un descripteur comme "(RAS)" au nom de l’adaptateur.

Si le profil n’existe pas, PowerShell peut créer une entrée native. Le type de tunnel et l’authentification doivent correspondre à ce que la passerelle propose, car l’écart se manifeste à la connexion, pas à la création :

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

Connectez-vous une fois, puis lisez le véritable alias avant d’écrire la moindre commande DNS :

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

Appliquez le remplacement dans le bon ordre

L’ordre compte plus que la syntaxe. L’adaptateur doit être actif, l’alias doit se résoudre et le compte doit être autorisé à modifier les paramètres de l’interface. Une connexion par utilisateur accepte généralement le changement de l’utilisateur connecté ; une connexion pour tous les utilisateurs créée avec -AllUserConnection nécessite en général un shell élevé.

La commande elle-même tient sur une ligne, documentée dans la référence Set-DnsClientServerAddress:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

Deux modes d’échec méritent d’être reconnus au premier coup d’œil. Un mauvais alias produit une erreur de la commande, ce qui est le bon résultat, car le silence serait pire. Une commande correcte sans effet visible signifie généralement que vous regardez le mauvais adaptateur : un adaptateur de tunnel resté d’un autre client, une carte réseau physique à la description similaire, ou un second adaptateur virtuel créé par un outil de réseau isolé.

Pourquoi une reconnexion peut annuler le changement

Le remplacement appartient à une instance d’interface. Quand le client démonte l’adaptateur et le reconstruit à la connexion suivante, les valeurs poussées sont de nouveau appliquées et votre liste disparaît. Certains clients recréent l’interface à chaque connexion ; d’autres la réutilisent pendant toute la session. Comparez l’index d’interface dans Get-NetAdapter entre deux connexions et vous saurez quel comportement vous avez.

Il existe trois réponses durables, et les empiler crée ses propres bogues. Un suffixe DNS propre à la connexion plus une règle NRPT n’envoie que l’espace de noms interne au résolveur interne et laisse les noms publics tranquilles. Un paramètre de Group Policy ou MDM appliqué à la connexion VPN définit le DNS à la connexion sans aucun script. Une tâche planifiée qui réagit à l’événement de connexion et relance la commande est l’option brutale, mais elle fonctionne et laisse un journal. Choisissez un seul propriétaire pour le DNS et notez lequel c’est.

Les noms internes à une seule étiquette ont aussi besoin d’une liste de recherche de suffixes. Set-DnsClientGlobalSetting -SuffixSearchList s’applique à toute la machine, donc il change la résolution pour chaque adaptateur de la machine, y compris Ethernet. Testez-le sur une machine de laboratoire avant qu’il n’entre dans une image.

Vérifiez la résolution, pas seulement le paramètre

Un résolveur listé sur un adaptateur prouve seulement qu’une valeur a été écrite. Interrogez le serveur prévu directement, puis interrogez par le chemin normal :

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

La séparation vous dit où se situe la panne. La requête directe répond et la requête simple échoue : le paramètre de l’adaptateur ou la liste de suffixes n’est pas actif. Les deux échouent : le résolveur est injoignable par le tunnel, alors regardez les routes et les règles de pare-feu avant de retoucher au DNS. La requête directe échoue tandis que la requête simple répond d’ailleurs : le split DNS est mal configuré et un nom interne est résolu par un résolveur public, ce qui est un problème de politique avant d’être un problème de connectivité.

Exécutez le test deux fois, une fois juste après la connexion et une fois après une déconnexion et une reconnexion, et comparez la Get-DnsClientServerAddress sortie des deux exécutions. Si la valeur poussée est revenue à la seconde connexion, le remplacement a vécu et est mort avec l’adaptateur, et seule la route NRPT ou de politique de la section précédente tiendra. Conservez les deux transcriptions et les horodatages de connexion ; ils tranchent la question de la persistance plus vite qu’une autre série de modifications.