DNS poussé par OpenVPN ignoré : quel composant l’applique

Le journal montre l’option poussée par le serveur, le tunnel est monté, et les noms internes échouent encore. Une requête directe au résolveur répond, donc le serveur est correct, mais chaque application continue d’interroger le routeur local. Ce qui est arrivé au client est une offre, pas un changement du résolveur, et le composant qui possède la résolution de noms diffère sous Linux, Windows et macOS. Dès que vous séparez l’option de son propriétaire, quatre défauts couvrent presque tous les rapports : aucun hook, deux hooks concurrents, un DNS scindé qui fonctionne comme prévu, ou un nom court qui a besoin d’un suffixe plutôt que d’un serveur.

Une option poussée est une offre, pas une installation

Sur le serveur, deux directives décrivent une intention, pas un effet :

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Le client ne reçoit pas un résolveur configuré. Il reçoit des variables d’environnement, foreign_option_1 et suivantes, une par ligne poussée, et quelque chose de local doit les lire et réécrire l’état du résolveur du système. Sous Linux, rien ne le fait par défaut, c’est pourquoi un serveur correct et un client connecté peuvent encore résoudre via le LAN.

Trois étapes séparent les deux extrémités : le push doit voyager, le client doit l’exposer et un hook doit l’appliquer. Lisez l’étape intermédiaire dans le journal du client et la dernière dans l’état du résolveur, jamais l’inverse, car une ligne de journal ne prouve que les deux premières.

Confirmez que le push est arrivé et trouvez le propriétaire

Commencez par nommer le lanceur : une commande openvpn nue, une instance systemd, NetworkManager ou un client d’éditeur. Cela décide où un hook peut vivre. Sur un hôte avec systemd-resolved, resolvectl status liste chaque lien avec les serveurs DNS et les domaines de recherche qu’il utilise réellement, et le lien du tunnel ne s’appelle pas toujours tun0.

Si l’adresse poussée apparaît dans le journal mais sur aucun lien, l’intégration manque. Si elle apparaît sur le lien et que les requêtes partent encore ailleurs, le problème est quelles requêtes sélectionnent ce lien. NetworkManager dns=dnsmasq dans le fichier /etc/NetworkManager/NetworkManager.conf lance un redirecteur local qui implémente le DNS scindé à dessein : les noms du domaine VPN vont au résolveur VPN, tout le reste garde son chemin précédent. Ce comportement ressemble à un défaut quand vous attendiez un déplacement de tout le trafic ; vérifiez les réglages par connexion avec nmcli connection show "My VPN", où ipv4.dns et ipv4.dns-search portent les valeurs derrière ce que le périphérique rapporte, avant de le déclarer cassé. Si chaque requête doit vraiment atteindre le résolveur VPN, retirez dns=dnsmasq de NetworkManager.conf et redémarrez NetworkManager, ce qui rend la résolution aux réglages de la connexion ; sinon, gardez le DNS scindé et corrigez la liste de domaines poussée.

Linux : confiez les options au résolveur

Les paquets des distributions fournissent un hook pour cela, et le client doit être autorisé à l’exécuter. Une disposition typique sur un hôte sans systemd-resolved :

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Avec systemd-resolved, l’ancien script resolv.conf peut ne rien changer d’important, car le résolveur stub conserve un état par lien. update-systemd-resolved l’assistant documente une forme de hook qui utilise up-restart et down-pre, ce qui compte quand une interface survit à une seule tentative de connexion. Quoi que vous choisissiez, un composant doit posséder l’état. Ajouter un hook étranger à côté de NetworkManager donne deux écrivains au même lien, et le résultat dépend alors de l’ordre et non de votre configuration.

Il existe aussi le cas où NetworkManager a ignoré l’option poussée jusqu’à ce que l’adresse du serveur soit saisie dans les réglages IPv4 de la connexion, après quoi l’état du résolveur l’a montrée utilisée. Cela vaut la peine d’être essayé avant de réécrire des scripts, car cela déplace le problème d’un hook shell vers le profil de connexion qui porte déjà le tunnel.

Windows et macOS appliquent des parties différentes

Le client Windows définit bien les serveurs DNS de l’adaptateur VPN, mais Windows choisit toujours une interface par métrique et a toujours besoin d’un suffixe pour développer un nom court. Vérifiez l’état de l’adaptateur plutôt que le profil :

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Si l’adresse manque, définissez-la avec Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, puis ajoutez le suffixe aux propriétés IPv4 de l’adaptateur pour que fileserver devienne fileserver.corp.example. Une valeur SearchList à l’échelle de la machine sous Tcpip\Parameters fait de même. Là où le nom long résout et le nom nu non, le résolveur est déjà correct et la liste de recherche est en cause. Les correctifs, dans l’ordre : poussez un DOMAIN pour que le client apprenne le suffixe, ajoutez ce suffixe à la liste de recherche de l’adaptateur ou de la connexion, et comme mesure temporaire fixez le nom dans hosts, ou LMHOSTS sous Windows ; la navigation NetBIOS ne traverse pas un routeur, donc la diffusion qui trouve un nom court sur le LAN du bureau n’atteint jamais un client de tunnel.

block-outside-dns block-outside-dns est un comportement du client Windows, pas une ligne de profil portable, et le copier dans un profil Linux ou macOS ne le reproduit pas là. Si les noms publics fonctionnent et les internes échouent sous Windows, comparez l’ordre des adaptateurs dans Paramètres avancés avec ipconfig /all. Sous macOS, l’ordre des résolveurs par service appartient au système, utilisez donc scutil --dns pour voir quel résolveur est consulté pour quel domaine, et traitez tout correctif de profil isolé comme dépendant du client plutôt que général.

Une machine virtuelle sur le même portable n’hérite de rien de tout cela. Donnez à l’invité sa propre entrée de résolveur pour le domaine interne, ou laissez le NAT de l’hyperviseur transmettre ses requêtes via l’hôte, ce qui n’est correct que tant que le tunnel de l’hôte est monté.

L’historique est la troisième cause. Des serveurs DNS ou des réglages de suffixe d’un profil antérieur peuvent survivre aux reconnexions, donc quand l’adaptateur semble correct et que les recherches échouent encore, comparez l’adaptateur actif avec Get-VpnConnection et effacez ou écrasez l’entrée périmée avant de toucher au serveur.

Prouvez où la requête est allée

Une capture pendant une recherche tranche le débat : tcpdump -ni eth0 port 53 montre des requêtes sur l’interface physique, ce qui signifie qu’elles sortent hors du tunnel et que le résolveur n’a jamais été changé. dig @10.8.0.1 name.corp.example sépare ensuite les deux cas restants. Si la requête directe répond, le résolveur fonctionne et le client ne l’utilise pas ; si elle expire, le résolveur est injoignable via le tunnel et aucun changement local n’aidera.

Si le résolveur encore utilisé est celui distribué par le fournisseur, le tunnel chiffre le trafic tandis que les noms restent visibles pour ce fournisseur. C’est une question de fuite et non de fonctionnement, et la même capture y répond : une requête sur l’interface physique va à quelqu’un hors du tunnel.

L’accessibilité inclut le pare-feu de l’hôte VPN, qui doit autoriser UDP et TCP 53 depuis le pool. Un port bloqué ressemble exactement à un push cassé, et un résolveur qui ne répond que depuis l’intérieur du réseau du tunnel aussi. Répétez la capture après une déconnexion et une reconnexion, car des réglages qui apparaissent à la première connexion et disparaissent à la seconde sont un défaut de cycle de vie du hook, pas une option absente.

Gardez un seul propriétaire et vérifiez dans l’ordre

Un script qui réécrit le DNS de l’adaptateur d’après un état de tunnel supposé duplique une configuration que le profil porte déjà, et il échoue silencieusement la première fois que la supposition est fausse. Préférez les réglages DNS de la connexion elle-même ou un seul hook documenté, et notez lequel vous avez choisi pour que la personne suivante n’en ajoute pas un second.

Bouclez avec quatre contrôles : l’adresse poussée présente sur le lien du tunnel, le nom interne résolu comme nom pleinement qualifié, le même nom résolu sans le suffixe, et les deux encore vrais après une reconnexion. Une capture vous dit lequel des quatre a échoué. Le manuel d’OpenVPN 2.6 liste dhcp-option et les directives de script avec leurs notes de plateforme.