DNS scindé et VPN : les règles de domaine ne sont pas des routes IP

Votre ordinateur portable résout intranet.corp via le tunnel pendant que gitlab.com continue vers le résolveur du fournisseur, et c’est là l’agencement qui fonctionne comme prévu. Deux décisions distinctes l’ont produit : une règle de correspondance de nom a choisi le résolveur, et une route a rapporté la réponse. Cassez l’une ou l’autre et le navigateur affiche une panne qui, de l’extérieur, semble identique. La plupart des rapports sur le DNS scindé décrivent la seconde panne tout en citant des preuves sur la première.

Les deux moitiés vivent à des endroits différents et sont généralement modifiées par des personnes différentes. L’une est une politique DNS attachée au profil VPN, l’autre une route que le tunnel installe ou retient. Le débogage s’arrête quand personne n’établit quelle moitié a réellement bougé.

Deux décisions cachées dans une requête

La moitié du nom est un objet de politique, pas une route. Sous Windows, c’est une politique de résolution de noms sur le profil VPN ; sur les plateformes Apple, un ensemble de domaines correspondants sur un objet de réglages DNS ; sous Linux, un domaine de routage, une ligne de résolveur scindé ou l’ordre du commutateur de services de noms. La moitié du chemin est du routage ordinaire, installé par le tunnel ou à la main, et elle n’a aucune idée de ce qu’est un nom d’hôte. Un profil qui admet un suffixe décide seulement qui répond ; il ne rend jamais la réponse joignable.

Un test de symptôme rapide les sépare : remplacez le nom par une adresse. Si l’adresse fonctionne, le chemin est bon et la règle fausse. Si l’adresse échoue aussi, la règle peut être correcte et le chemin manquer.

Comment chaque plateforme exprime la même règle de nom

L’intention est identique et les noms de champs ne le sont pas. Un exemple copié d’un client à l’autre s’analyse proprement et ne correspond jamais. Les trois formes ressemblent à ceci :

Un domaine de correspondance ou de routage est un test de suffixe, donc intranet.corp couvre git.intranet.corp et ne couvre pas corp.intranet, et l’inverser est l’erreur la plus courante de toute la configuration. Windows porte la correspondance comme une politique de résolution de noms attachée au profil, avec son propre ordre de priorité face à toute liste de suffixes que l’interface avait déjà. Les plateformes Apple attachent les domaines correspondants à l’objet de réglages DNS de l’extension réseau, et le système les applique par résolveur délimité. Aucune de ces formes n’est une route, et aucune ne peut rendre joignable une adresse injoignable. La référence politique de résolution de noms de Windows énumère les noms de champs et les règles de priorité pour cette plateforme, et ce ne sont pas celles qu’utilisent les documents Apple ou systemd.

Une réponse correcte a encore besoin d’un chemin

La réponse d’un résolveur n’est qu’une adresse, et l’application doit encore l’atteindre. Une conception de tunnel scindé pousse souvent 10.20.0.0/16 et retient la route par défaut, si bien que le nom interne se résout et que la connexion se bloque ensuite. Le cas inverse est tout aussi courant : la route existe, un résolveur public répond au nom privé par NXDOMAIN, et la panne est classée comme problème de routage. Tester le chemin d’abord vous laisse fixer des routes pour un nom qui n’allait jamais se résoudre.

Il existe aussi une troisième porte qu’aucune moitié ne couvre. Une ACL sur la passerelle, une règle de pare-feu ou une politique côté client peuvent abandonner la connexion après que les deux décisions étaient correctes. Quand le nom se résout, que la route existe et que la connexion expire encore, cessez de tester le DNS.

Tester les noms et les chemins dans un ordre fixe

Choisissez un ordre et tenez-vous-y, sinon vous courrez après l’étape qui a échoué le plus récemment. Résolvez le nom interne complet documenté, confirmez que la réponse est une adresse que la table de routage peut porter, puis répétez avec un nom public pour prouver que le tunnel n’a pas tout capturé. Sur un hôte systemd, la requête et le domaine de routage du résolveur sont à une commande l’un de l’autre :

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Un client Windows pose les mêmes deux questions avec d’autres cmdlets. Le second indique l’interface que le système utiliserait réellement :

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Si la recherche renvoie une adresse et que la vérification du chemin nomme l’interface physique, la règle de nom a fonctionné et la route non. Si le nom court échoue alors que le nom complet se résout, la liste de suffixes est fausse et non le résolveur.

Où la comparaison se trompe habituellement

La première erreur est d’interroger un résolveur public sans rapport sur un nom privé et de lire le refus comme une preuve sur le VPN. La deuxième est de supposer qu’une recherche publique qui fonctionne prouve le chemin de résolveur du tunnel. La troisième est de traiter le tunnel scindé et le DNS scindé comme une seule décision de conception, alors qu’un déploiement peut être correct dans l’un et cassé dans l’autre. Chaque erreur produit des conclusions assurées à partir d’un test qui n’a jamais exercé la partie mise en cause.

Un navigateur doté de son propre DNS sécurisé peut aussi contourner la règle du système, c’est pourquoi le fait qu’un navigateur échoue alors qu’un autre réussit n’est pas une contradiction. Comparez le résolveur qui a répondu, pas le navigateur qui s’est plaint.

Une fois les deux moitiés visibles, la question restante est une question de politique et non technique : quels espaces de noms appartiennent à l’organisation, qui possède chaque réponse et lesquels devraient quitter la machine. Écrivez-le à côté du profil, car la prochaine personne qui touchera la règle en aura besoin.