Le VPN a pris le relais du DNS et cassé les noms locaux : réparer la liste

Le tunnel monte, l’intranet se charge et le nom de l’imprimante cesse d’être résolu. Ou l’inverse : les noms locaux fonctionnent encore alors que tout ce qui est dans le réseau d’entreprise expire. Les deux symptômes viennent du même endroit, une liste de résolveurs que le client VPN a réécrite à la connexion.

Réparez la liste délibérément, puis traitez le mécanisme push séparément. Les routes sont un troisième sujet et ce n’est pas celui qui est réparé ici.

Quelle liste les applications utilisent réellement

Windows résout via des paramètres au niveau de l’interface et non via ce qu’affiche une boîte de dialogue, commencez donc par les listes effectives par interface. L’alias compte plus que le nom affiché, car chaque commande ci-dessous s’adresse à une interface. Trompez-vous d’alias et la réparation atterrira sur le mauvais adaptateur. Elle semblera fonctionner jusqu’à la prochaine reconnexion, quand l’entrée propre au tunnel reviendra.

La question est de savoir quels serveurs se sont retrouvés devant et s’ils sont arrivés comme entrées statiques ou comme bail DHCP. Les deux faits décident de la réparation dont vous disposez.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Lisez la sortie pour l’adaptateur du tunnel et pour l’adaptateur physique, et notez chaque adresse sur chacun. Une entrée statique peut être supprimée par une stratégie ou un script ; une entrée fournie par DHCP est liée au bail et reviendra, ce qui change la réparation à choisir. Les noms du réseau distant sont résolus par le résolveur annoncé, ceux du LAN local par l’adaptateur physique, et la requête va à la liste consultée en premier.

Supprimez les serveurs poussés, ou classez-les plus bas

Supprimez les serveurs poussés quand rien dans le tunnel n’en a besoin, car les résolveurs de l’adaptateur physique reprennent la main. Ne les gardez que si le réseau distant possède des zones que seuls ses serveurs peuvent résoudre, et dans ce cas placez un résolveur local devant eux. Les deux commandes ci-dessous couvrent les deux choix, choisissez donc celle qui correspond à la situation plutôt que d’exécuter les deux.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

L’index 1 est consulté en premier, les adresses poussées restent donc disponibles mais cessent d’être la réponse par défaut à chaque requête. L’indicateur validate=no saute un test d’accessibilité qui échoue souvent pendant que le tunnel se stabilise, confirmez donc le résultat avec la commande show au lieu de faire confiance au code de sortie.

Deux limites valent d’être connues avant de s’y fier. Windows ne supprimera pas les serveurs arrivés par DHCP via netsh, et ces valeurs persistent comme DhcpNameServer sous la clé de registre de l’interface, une modification du registre est donc un dernier recours à revérifier après le prochain bail. L’ordre de liaison des adaptateurs n’est pas non plus un mécanisme de classement fiable, car un client VPN peut insérer sa propre entrée en tête de liste.

Où le push peut être filtré

Une meilleure réparation retire l’option avant qu’elle ne soit appliquée. Le client Community OpenVPN peut filtrer une directive poussée par nom, ce qui laisse la configuration du serveur intacte.

pull-filter ignore "dhcp-option DNS "

L’espace final appartient à la correspondance et le filtre nomme l’option plutôt qu’une adresse de serveur. Si le profil contient aussi une directive block-outside-dns, la retirer change la protection contre les fuites et non la résolution de noms, décidez donc cela séparément au lieu de regrouper les deux modifications.

Pour un seul nom d’hôte obstiné, une ligne dans le fichier hosts de Windows est plus stable que de réordonner les résolveurs pour toute la machine. Elle est aussi invisible pour la personne suivante, notez-la donc là où la configuration de la machine est documentée.

Faites survivre la réparation à une reconnexion

La résolution doit être testée deux fois, une fois contre un serveur choisi et une fois dans la forme qu’utilise une application. Cette paire sépare un problème d’ordre de résolveurs d’un serveur qui ne répond pas du tout. Sauter le premier test laisse les deux causes emmêlées.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Reconnectez le tunnel et répétez les deux commandes. Ce que vous avez changé à la main ne dure que jusqu’à la prochaine connexion, car le client reconstruit son état de résolveurs en montant l’adaptateur. Placez les lignes netsh dans le script de connexion pris en charge de votre client, laissez ce script se terminer avec succès et ajoutez une courte attente avant son exécution. Un client qui applique le DNS après le script écrasera le résultat de toute façon.

Si les noms publics se résolvent et que les internes échouent encore après la réparation, la liste de résolveurs n’est plus le suspect. La requête n’atteint probablement pas du tout le serveur, ce qui pointe vers le routage ou une règle de pare-feu et non vers un autre réglage DNS. Notez l’alias de l’interface et les adresses sur lesquelles vous vous êtes arrêté, car les deux diffèrent d’une machine à l’autre et aucun ne survit seul à une reconstruction.