DNS scindé sur OpenVPN : ce qu’un domaine de routage doit faire sur chaque système

Toute demande de DNS scindé commence par la même phrase : les noms de l’entreprise vont au DNS de l’entreprise, tout le reste continue de fonctionner. Transformer cette phrase en configuration suppose de répondre à trois questions par système d’exploitation, et les réponses reposent sur des mécanismes différents selon le système. Des profils qui fonctionnent sur un portable Linux échouent souvent sous Windows pour des raisons qui n’ont rien à voir avec le tunnel. L’écart tient généralement à un réglage de résolveur pris pour une route.

Nommez d’abord la politique, puis choisissez la primitive de la plateforme qui l’exprime.

Trois réglages faciles à confondre

Un suffixe de recherche développe un nom court : taper files devient files.corp.example lorsque le résolveur essaie les suffixes dans l’ordre. Un domaine de routage choisit quel résolveur répond aux requêtes à l’intérieur d’un espace de noms. Une route IP rend seulement le résolveur choisi joignable. Ces trois éléments vivent dans des couches différentes, et remplacer l’un par l’autre donne une configuration qui semble correcte et ne résout rien.

La confusion a un coût : ajouter un suffixe de recherche envoie chaque nom court au résolveur du travail, y compris des noms qui appartiennent ailleurs. Choisir un domaine de routage garde les requêtes sans rapport sur le résolveur local tout en envoyant *.corp.example par le tunnel.

Linux : un domaine de routage seul, pas un suffixe de recherche

Sur systemd-resolved, un domaine préfixé par un tilde est un domaine de routage seul, ce qui signifie que les requêtes de cet espace de noms vont au résolveur lié sans devenir aussi un suffixe de recherche. resolvectl domain tun0 '~corp.example' le définit, et resolvectl dns tun0 10.8.0.1 nomme le serveur. Les deux réglages appartiennent à l’interface, donc ils disparaissent avec elle. Le tilde est la partie que les gens omettent, et sans lui les noms courts commencent à se résoudre via le résolveur du travail.

N’installez pas non plus le même domaine comme suffixe de recherche global. Les deux réglages ne sont pas redondants ; l’un achemine et l’autre réécrit ce que vous avez tapé.

Windows exige une politique d’espace de noms, pas un suffixe

Windows conserve la politique de DNS scindé dans la Name Resolution Policy Table, et non dans le suffixe DNS de la carte réseau. Une règle associe un espace de noms à des serveurs précis : Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Régler le suffixe seul change l’apparence des noms courts ; cela n’oriente pas la requête vers un autre serveur.

Vérifiez la politique effective avec Get-DnsClientNrptPolicy après la connexion, car une règle d’une connexion précédente peut survivre au tunnel. Supprimez les règles par nom lorsque le tunnel tombe, et gardez le nom d’affichage stable pour que le nettoyage vise la bonne entrée.

Un seul propriétaire du résolveur par plateforme

Un gestionnaire de bureau, un script up d’OpenVPN et un démon de résolveur local peuvent tous essayer d’écrire la même configuration. Quand ils se contredisent, le dernier écrivain gagne et le résultat dépend de l’ordre de démontage. Choisissez un composant pour posséder l’état du résolveur, laissez les autres rapporter plutôt qu’écrire, et testez une reconnexion : la politique devrait y survivre sans dupliquer les règles. Testez aussi une déconnexion, car c’est l’état résiduel qui fait que la connexion suivante se comporte différemment.

Les applications qui embarquent leur propre résolveur chiffré ignorent entièrement la politique du système d’exploitation. C’est une propriété de l’application, pas un défaut du tunnel.

Vérifiez le résultat, pas le texte du profil

Résolvez un nom qui doit passer par le tunnel et un qui ne doit pas, sur chaque plateforme, et confirmez quel serveur a répondu. resolvectl query host.corp.example et Resolve-DnsName host.corp.example indiquent tous deux le serveur qui a répondu. Répétez après une reconnexion. Confirmez ensuite que le résolveur du tunnel est joignable à l’adresse que le profil pousse, car une politique correcte pointant vers un serveur injoignable échoue de la même façon que pas de politique du tout.

Notez le comportement voulu dans les notes du profil : quel suffixe achemine, quel serveur y répond et ce qui arrive à tout le reste. La prochaine plateforme que vous prendrez en charge aura plus besoin de cette phrase que du fichier de configuration.