Pourquoi le DNS cesse de fonctionner après la connexion d’OpenVPN sous Windows

Un ping vers le résolveur du bureau répond encore après la connexion d’"OpenVPN", et pourtant chaque recherche de nom échoue. L’adresse est joignable alors que le port ne l’est pas, une combinaison qui a du sens dès que l’on sait que Windows peut filtrer le DNS par adaptateur. Avec block-outside-dns dans le profil, ce filtre est le premier suspect et la table de routage est le mauvais endroit où chercher. Les deux tests ci-dessous séparent les couches en quelques secondes.

Adresse joignable, port mort

Un ping réussi prouve que l’hôte est actif et qu’un chemin existe. Il ne dit rien sur l’autorisation d’atteindre le port 53, car le filtre en question travaille à une autre couche et dépend de l’adaptateur. C’est pourquoi la même machine peut répondre à ICMP et refuser chaque requête envoyée à la même adresse. Exécutez les deux tests dans la même session avant de modifier une configuration.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Le couple est le diagnostic. Le trafic ordinaire vers le sous-réseau continue de fonctionner pendant que la résolution de noms meurt, et l’on conclut que le serveur est en panne ou que le DNS n’a jamais été poussé. Les deux explications coûtent cher à poursuivre, et les preuves pointent vers quelque chose de plus étroit. Confirmez le couple avant de toucher à un réglage.

L’option est une règle de la plateforme de filtrage

La référence OpenVPN décrit block-outside-dns comme une restriction de Windows Filtering Platform qui empêche les applications d’atteindre le DNS sur des adaptateurs hors du tunnel. Elle couvre TCP et UDP sur le port 53. Comme le filtre vit dans WFP et non dans la liste habituelle des règles du pare-feu, ajouter une règle d’autorisation ailleurs ne change pas forcément le résultat. C’est pourquoi le conseil courant d’autoriser le DNS continue d’échouer.

Le réglage peut venir du profil importé ou du serveur, et le fichier que vous avez modifié en dernier "ne prouve pas ce que le client a chargé". Lisez la configuration effective et le journal de connexion ensemble. L’option est aussi propre à Windows, et la traiter comme portable produit des conseils qui ne s’appliquent pas.

Cherchez le composant client qui possède la restriction au lieu d’ajouter des règles. Le propriétaire est ce qui peut réellement la retirer.

Un filtre n’est pas un résolveur

Bloquer le trafic hors du tunnel n’installe pas un résolveur fonctionnel à l’intérieur. L’option retire un chemin et laisse la configuration DNS du tunnel à celui qui a monté le profil. Un profil qui n’a jamais poussé de résolveur n’en a désormais aucun.

Passez par trois vérifications dans l’ordre. D’abord, quel résolveur l’application en échec utilise réellement. Ensuite, si le client a appliqué les réglages DNS du VPN. Enfin, quelle interface transporte le trafic vers ce résolveur.

1. Résolveur utilisé : comparez Resolve-DnsName -Server <resolver-ip> <name> avec les serveurs DNS que ipconfig /all liste.
2. DNS du VPN appliqué : examinez les entrées DNS de l’adaptateur du tunnel dans la même sortie de ipconfig /all.
3. Interface utilisée : Find-NetRoute -RemoteIPAddress <resolver-ip> nomme l’interface de sortie pour cette destination.

Un résolveur de LAN devient injoignable par conception sous cette politique, même lorsque d’autre trafic LAN fonctionne. C’est l’option qui fait son travail. Si la conception a besoin du DNS par VPN, corrigez l’enregistrement du résolveur et le chemin du tunnel ; si un split DNS avec des exceptions locales est requis, le propriétaire de la configuration doit exprimer ces exceptions d’une manière prise en charge.

Ce que l’option ne couvre pas

Le port 53 n’est pas toute la résolution de noms. DNS over HTTPS et DNS over TLS utilisent d’autres transports, et certaines applications exécutent leur propre logique de résolveur quels que soient les réglages système. Un navigateur peut donc résoudre des noms alors que la ligne de commande ne le peut pas.

Traitez cette différence comme un diagnostic et non comme une contradiction. Comparez les deux avant de décider que le résolveur système est en panne.

Gardez la conclusion étroite quand vous la rédigez. Cette option contraint un transport sur une plateforme, et le reste du chemin de résolution est une question de conception distincte avec son propre propriétaire.

Vérifiez l’état avant et après la déconnexion

Exécutez la même recherche pendant la connexion et de nouveau après que le client propriétaire s’est déconnecté. La première devrait échouer pour un résolveur externe tant que le tunnel est actif, et la seconde devrait réussir une fois le filtre retiré. Si elle échoue encore après la déconnexion, le filtre n’a pas été nettoyé.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Redémarrer le service client ou la machine nettoie généralement un filtre obsolète. Cela confirme le diagnostic sans prouver un correctif durable. Notez ce que vous avez vu, car un filtre qui survit à une déconnexion le refera, et c’est la note qui justifie un rapport de bogue.

Ce n’est qu’après ces vérifications qu’il est sensé de remplacer le résolveur ou de reconstruire la politique du pare-feu. Les deux sont des changements plus importants que ce que les preuves soutiennent.