Quel lien répond : domaines de routage pour le DNS d’un VPN à tunnel divisé

Gardez la navigation ordinaire sur le lien local pendant que les noms de l’entreprise se résolvent via le serveur DNS fourni par le tunnel. Désactiver la route par défaut du VPN vous donne la première moitié et laisse la seconde non construite. Ce qui suit est le réglage manquant, la ponctuation qui en change le sens, et la seule commande qui montre quel lien a réellement répondu. NetworkManager et systemd-resolved sont supposés tout du long, car c’est dans ce couple que la confusion commence habituellement.

Première étape : séparez la route du résolveur

ipv4.never-default répond à une question de routage, en empêchant NetworkManager d’installer cette connexion comme chemin pour tout le trafic IPv4. Un domaine de routage DNS répond à une autre question : quels serveurs de noms de quel lien reçoivent une requête pour un suffixe correspondant. Ni l’un ni l’autre n’implique l’autre, et un profil peut porter l’un pendant des années en manquant l’autre. Route seule signifie que le tunnel transporte les sous-réseaux de l’entreprise et que son résolveur répond aux noms de l’entreprise, tout le reste étant laissé tranquille.

Réglez seulement la propriété de route et les noms internes échouent, souvent avec un délai d’attente qui ressemble à un tunnel cassé. Réglez seulement le domaine et vous avez silencieusement ajouté un suffixe de recherche à chaque nom court de la machine. Les deux erreurs envoient le ticket au serveur VPN, qui est rarement la partie en cause.

Deuxième étape : ajoutez un domaine de routage seul au profil

Supposons que la connexion s’appelle corp-vpn, que le suffixe de l’entreprise soit internal.example et que le résolveur du tunnel soit déjà joignable. Lisez d’abord les valeurs actuelles, car les commandes ci-dessous modifient des propriétés qui peuvent déjà contenir des entrées.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Remplacez par votre propre nom de connexion et votre suffixe, car les valeurs ci-dessus sont illustratives. Le signe plus compte plus qu’il n’y paraît : avec lui la valeur est ajoutée à la liste existante, alors que sans lui la propriété est remplacée et des domaines sans rapport disparaissent d’un profil qui fonctionnait hier. Le tilde change le comportement et non le style, et le paragraphe ci-dessous précise ce qu’il sélectionne. Gardez la lecture avant l’écriture, pour que la forme de remplacement ne vous surprenne jamais.

Un tilde initial marque un domaine de routage seul, donc les requêtes correspondantes vont aux serveurs de ce lien et le suffixe n’est pas ajouté aux noms courts. Retirez le tilde et la même chaîne devient aussi un suffixe de recherche, un résultat différent que les gens visent rarement. Les deux réglages ci-dessus sont IPv4, donc un profil double pile a besoin de ipv6.never-default et du même domaine de routage dans ipv6.dns-search, sinon le côté IPv6 continue d’utiliser la route par défaut et les noms internes y échouent.

Troisième étape : demandez à resolvectl quel lien a répondu

Exécutez resolvectl status et lisez les serveurs DNS et les domaines de chaque lien, puis exécutez resolvectl query host.internal.example contre un vrai nom interne que vous êtes autorisé à interroger. La seconde commande est la seule preuve directe que le domaine de routage fait son travail, car elle nomme le lien qui a répondu. Une liste d’état seule prouve la configuration ; la requête prouve la résolution.

systemd-resolved choisit le domaine de routage le plus proche, donc un domaine plus spécifique sur un autre lien peut encore gagner la course. Si la requête revient d’un lien que vous n’attendiez pas, lisez les listes de domaines avant de toucher au serveur DNS du VPN. Un domaine racine de ~. correspond à tout, et s’il est déjà présent votre domaine spécifique gagne encore pour ses propres noms pendant que le lien répond bien plus que demandé. Supprimez ou resserrez cette entrée racine lorsque l’intention était seulement les noms de l’entreprise.

Si le lien VPN ne liste aucun serveur DNS, le client n’en a jamais enregistré un. Un domaine de routage sans serveur derrière échoue différemment d’un domaine absent, donc corrigez d’abord l’enregistrement.

Quatrième étape : quand le nom se résout mais pas le service

Une réponse correcte prouve seulement que la résolution a fonctionné, et l’application a encore besoin d’une route vers l’adresse reçue. Cette route doit survivre à la route par défaut divisée que vous venez de configurer, vérifiez-la avant de blâmer DNS à nouveau. Vérifiez ensuite l’accessibilité sur le port du service, car un partage de fichiers ou un service d’annuaire échoue à la résolution, au routage ou à l’authentification et produit des messages très similaires dans chaque cas. Gardez ces trois couches séparées lorsque vous rapportez le résultat, sinon la personne suivante revérifie un DNS déjà correct.

Le changement Samba qui circule à côté de cette question concerne la couche d’accès, pas le choix DNS. L’appliquer à une panne de résolution de noms est ainsi qu’un petit problème en acquiert un second.

Cinquième étape : ne remplacez pas le résolveur pour corriger un domaine manquant

Le conseil qui écrase le fichier du résolveur ou installe un autre gestionnaire de résolveur résout un autre problème. Ce sont des changements d’intégration système avec leurs propres modes de défaillance, et aucun n’ajoute un domaine de routage qui n’a jamais été configuré. Déterminez quel composant possède la résolution de noms sur la machine avant de le remplacer, car sur un bureau NetworkManager avec systemd-resolved cette propriété est déjà définie. Lutter contre elle est ainsi qu’une installation qui fonctionne devient quelque chose que personne ne peut reproduire.

Ordre du travail : confirmez que le tunnel fournit un résolveur, ajoutez le domaine de routage seul, reconnectez-vous via les contrôles du profil, vérifiez le lien qui répond, puis testez le service sur son port. Cette séquence laisse un résultat que vous pouvez transmettre à la personne suivante sans second entretien.