Noms internes en échec sur le VPN alors que les sites publics se résolvent

Un utilisateur signale que le nom d'hôte de l'intranet ne se résout pas par le VPN. Un second rapport, depuis le même portable, indique qu'un test de fuite montre encore des requêtes résolues par le résolveur local. Les deux symptômes ressemblent à un seul problème et en sont deux, avec des preuves différentes, et la réparation habituelle du premier aggrave le second. Séparez-les avant de toucher au moindre réglage.

Deux symptômes qui ne font pas une seule panne

Échouer à résoudre un nom interne signifie que la question est allée là où personne ne peut y répondre. Des requêtes qui quittent le tunnel signifient que la question est allée au mauvais endroit même quand la réponse était disponible. Ce sont des échecs opposés : l'un est une réponse manquante, l'autre une destination en trop.

Le piège est que l'ajout du résolveur du bureau partout corrige le premier et garantit le second. L'ajout d'un résolveur public partout fait l'inverse.

Notez les deux observations avec un horodatage, puis passez les quatre vérifications ci-dessous dans l'ordre.

Quel résolveur d'adaptateur reçoit la question

Sous Windows, le client DNS choisit les serveurs selon l'ordre de liaison des adaptateurs, et l'adaptateur du tunnel n'est pas automatiquement le premier. Ouvrez les paramètres avancés de l'adaptateur, placez la connexion d'accès à distance au-dessus de l'adaptateur physique, puis reconnectez-vous pour que le changement s'applique à une nouvelle session.

L'ordre de liaison n'est que la première moitié. Le client doit aussi savoir quels noms appartiennent à cet adaptateur, et c'est une question de suffixe, pas d'ordre.

Placez le ipconfig /all de la machine qui fonctionne à côté de celui du portable, les deux pris tunnel actif. La machine qui fonctionne affichera un suffixe DNS propre à la connexion sur son adaptateur de bureau, et le portable peut n'en afficher aucun sur le tunnel. Cette différence explique toute une classe de rapports où le serveur est juste là et le nom échoue quand même, car sans suffixe le nom court n'est jamais complété dans la zone que sert le résolveur du bureau.

Un nom court a besoin d'un suffixe avant d'avoir besoin d'une route

Taper un nom d'hôte non qualifié demande au résolveur de deviner un domaine. La supposition vient de la liste de suffixes attachée à la connexion, et si cette liste est vide, la requête part comme une étiquette unique qu'aucune zone privée ne reconnaîtra.

Copiez le suffixe de la machine qui fonctionne dans les propriétés IPv4 de l'adaptateur VPN, onglet DNS, puis reconnectez. Sous Linux, l'équivalent est le domaine de recherche sur le lien du tunnel, que systemd-resolved expose par lien et non globalement.

Gardez les deux réglages séparés dans vos notes. Un suffixe change ce qui est demandé ; l'adresse du résolveur change à qui on le demande. Corriger l'un alors que l'autre est faux produit un résultat qui semble aléatoire.

Interrogez le résolveur directement, puis le nom

Une requête directe au résolveur du bureau sépare un problème de nom d'un problème de chemin, car elle contourne entièrement la sélection de résolveur du client.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

La première commande demande un nom pleinement qualifié à un serveur précis. Si elle répond, le résolveur et la route vers lui vont bien et la panne est dans la sélection ou le suffixe. Si elle expire, l'adresse est fausse ou injoignable et le problème est le routage, pas le DNS. La deuxième commande montre ce qui se passe avec le nom court, et la troisième affiche la configuration du résolveur par lien sur un hôte systemd.

Surveillez les réponses génériques, que certains réseaux renvoient pour des noms inconnus. Une réponse plausible ne prouve pas que le serveur visé a répondu, alors comparez l'adresse retournée avec celle que le service interne utilise réellement. Si l'adresse appartient à une page de stationnement ou à un proxy, le résolveur a répondu mais la réponse n'a jamais été la vôtre. Cette distinction épargne une heure passée à traquer un tunnel qui fonctionnait depuis le début.

Sous Linux, un client VPN qui réécrit /etc/resolv.conf remplace entièrement les résolveurs locaux. vpnc expose DNSUpdate no pour l'empêcher, et systemd-resolved peut router uniquement les domaines listés vers le lien du tunnel. Les deux approches gardent les noms publics sur le résolveur local tout en envoyant les noms internes au bureau.

Les fuites sont une règle, pas une case à cocher

La résolution de noms est un échange UDP vers le port 53, donc un tunnel qui transporte le web mais pas l'UDP laisse la requête sur le chemin physique. Prouvez-le en capturant sur la carte physique pendant qu'un nom public est résolu. Une requête visible en clair sur cette interface signifie que le tunnel ne la transporte pas.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Si la requête apparaît en clair sur cette interface, le tunnel ne la transporte pas. La réparation est une règle qui n'autorise le port 53 que vers le résolveur poussé par le VPN et rejette les autres destinations, plus une configuration client qui n'écarte pas silencieusement l'option poussée.

Ce dernier point compte plus qu'il n'y paraît. Démarrez OpenVPN avec route-nopull et l'option DNS poussée disparaît avec les routes, à moins d'élargir le filtre de récupération pour la conserver. Un client qui ignore dhcp-option DNS continuera d'utiliser ce qu'il avait avant. Tout changement côté serveur exige une nouvelle session pour prendre effet, car la liste des résolveurs est livrée à l'ouverture du tunnel et une session périmée continue d'afficher l'ancien état.

Notez quelle panne vous avez réellement observée avant de clôturer le ticket. Une réponse interne manquante et une requête qui s'échappe du tunnel appellent des réparations différentes, et un changement de suffixe qui corrige la première peut discrètement aggraver la seconde. La prochaine personne qui reprend le ticket fera confiance à l'étiquette, alors rendez l'étiquette exacte.