OpenVPN pousse le DNS, mais votre résolveur ne le verra peut-être jamais

Le journal du client affiche le serveur DNS poussé, le tunnel est connecté, et un nom interne ne se résout toujours pas. Rien n’est cassé dans le push lui-même. L’option est arrivée et le résolveur du système d’exploitation ne l’a jamais utilisée, car sur la plupart des clients Unix, OpenVPN transmet la valeur et laisse l’application à la plateforme.

Le symptôme : le journal affiche du DNS et les noms échouent encore

OpenVPN dhcp-option transporte des informations DNS et de domaine, et le client consigne ce qu’il a reçu. Dans certaines implémentations, le client applique ces réglages en interne ; dans d’autres, il les exporte pour qu’un script d’intégration ou un service réseau les consomme. La ligne du journal ne décrit que la première moitié de l’histoire. La seconde moitié se produit là où le client n’a pas la main. C’est là que réside généralement la panne.

Voilà pourquoi un tunnel connecté et un nom interne défaillant coexistent si souvent. La valeur est présente, le consommateur manque ou est mal configuré, et le résolveur continue discrètement d’utiliser le serveur public qu’il employait avant la connexion.

Reçu n’est pas appliqué

Un client peut consigner une valeur DNS poussée alors que le résolveur système appartient encore à un autre service. Un navigateur peut aussi avoir sa propre politique de DNS chiffré qui contourne entièrement le résolveur système, ce qui produit la situation mémorable où une application résout des noms internes et une autre non.

Vérifiez l’intégration prise en charge par l’implémentation au lieu de supposer que tous les clients Unix réécrivent le même fichier. Cette supposition est la raison pour laquelle les gens modifient une configuration de résolveur que rien ne lit.

Trouvez le propriétaire du résolveur selon la plateforme

Sous Windows, la table de stratégie de résolution de noms peut diriger des suffixes précis vers des serveurs précis, et le client VPN peut y installer des règles. Vérifiez la stratégie, pas seulement la liste DNS de la carte réseau. Sous Linux, NetworkManager ou systemd-resolved peuvent posséder la configuration, et lequel la possède détermine ce qu’une reconnexion préservera.

Lisez l’état effectif avec l’outil qui répond réellement aux requêtes : resolvectl query internal.example.net sur un hôte systemd-resolved, ou l’équivalent de la plateforme. Comparez ensuite cette réponse avec le serveur DNS que le journal du client prétend avoir poussé.

Évitez de faire tourner plusieurs services qui écrasent les réglages du résolveur sans coordination. Deux propriétaires produisent un résultat qui semble intermittent, et chaque reconnexion semble le corriger ou le casser au hasard.

Scripts et foreign_option

OpenVPN exporte les options poussées vers des scripts via des variables nommées foreign_option_N, et un script peut les traduire en commandes de résolveur. Cet agencement est une intégration prise en charge, pas un comportement automatique, et il doit être installé et invoqué sur le client.

Si vous dépendez d’un script, consignez son exécution et son code de sortie. Un script qui s’exécute mais échoue silencieusement laisse le même symptôme qu’aucun script, et il est plus difficile à remarquer car la configuration paraît complète. Vérifiez la sortie du script, pas le fichier du script. Un fichier qui existe n’est pas un script qui a tourné.

Testez le nom, pas le journal

Interrogez un nom d’hôte uniquement interne depuis le client après la connexion, puis interrogez un nom public, puis vérifiez quel serveur a répondu. Dans une installation qui fonctionne, les deux réponses viennent d’endroits différents, et les deux devraient correspondre à la conception.

Si le nom se résout mais que le service échoue, passez au routage et à l’accès des applications au lieu de changer encore le DNS. Le manuel OpenVPN documente dhcp-option et l’environnement de script ; utilisez-le pour confirmer ce que votre client est censé appliquer avant de modifier un autre fichier de résolveur.