Les noms d’hôtes VPN échouent, les adresses IP fonctionnent : où chercher

Vous pouvez ouvrir le partage par adresse et le même partage par nom échoue, ce qui signifie que le tunnel transporte des paquets et pas la couche de noms. Cette seule observation évite un détour par des changements de pare-feu et de routes. Les noms ont besoin d’un suffixe, d’un résolveur et d’un chemin pour la requête, et un client VPN peut installer une route sans installer aucun des trois. Parcourez les quatre vérifications ci-dessous dans l’ordre et arrêtez-vous à la première qui casse.

Un nom pose une question qu’une adresse ne pose pas

Une adresse est une destination que la pile peut utiliser immédiatement. Un nom court est une question qu’il faut étendre avec un suffixe, envoyer à un résolveur et faire répondre par quelque chose qui connaît la zone. Un tunnel qui installe des routes mais aucun résolveur laisse la première fonctionner et la seconde cassée. C’est pourquoi le symptôme paraît si cohérent sur des produits VPN très différents.

Travaillez de l’adresse vers l’extérieur : d’abord le nom complet, puis le nom d’hôte nu, et notez lequel des trois fonctionne. Le motif vous dit quelle couche inspecter avant d’ouvrir un seul écran de configuration. Deviner des routes quand le FQDN se résout est un effort perdu.

Lisez le résolveur que le tunnel a réellement installé

Demandez au système d’exploitation quel résolveur traite les requêtes de la zone interne, pas lequel l’interface du client VPN annonce. Un serveur qui pousse un résolveur public sans zone interne produit exactement cette défaillance, et c’est une erreur de configuration et non une panne de routage.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

Sur un client Windows joint au domaine, la stratégie de routage de l’espace de noms décide quelles requêtes vont à quel résolveur, et les réglages DNS propres à l’adaptateur VPN apparaissent dans les détails de l’adaptateur. Lisez la stratégie effective plutôt que le profil, car une stratégie mise en cache peut survivre à la connexion qui l’a installée. Si le résolveur répond au nom complet et pas au nom court, le problème a déjà glissé vers la liste des suffixes.

Get-DnsClientNrptPolicy
ipconfig /all

Arrêtez-vous si la zone interne se résout par le bon serveur. Le résolveur n’est pas votre problème.

Les suffixes expliquent les noms courts qui échouent

Un nom à une seule étiquette est étendu avec la liste de suffixes de la connexion avant l’envoi de la requête. Si le VPN ne livre pas le suffixe interne, fileserver ne devient jamais fileserver.corp.example, et la requête sort comme un nom qu’aucun résolveur public ne connaît. Imposer le suffixe, ou taper le nom complet, teste l’hypothèse sans rien changer sur le serveur.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Sous Linux, le service de résolution lie un serveur DNS à un lien et à un ensemble de domaines de routage, si bien qu’un serveur poussé qui n’est pas associé au lien du tunnel se comporte comme s’il n’était pas là. Vérifiez l’état par lien plutôt que le fichier stub, qui peut ne pointer que vers le résolveur local. La même coupure apparaît dans l’autre sens : un domaine de recherche présent mais non appliqué à l’interface du tunnel produit des échecs de nom court qui semblent aléatoires.

Si l’ajout du suffixe corrige le problème, il reste à livrer ce suffixe par le profil VPN au lieu de demander à chaque utilisateur de le taper.

NetBIOS et WINS sont un autre mécanisme

L’ancien SMB peut encore chercher un nom nu avec le service de noms NetBIOS, qui répond par diffusion ou via un serveur WINS. La diffusion reste dans un domaine de diffusion et s’arrête au premier routeur, elle ne peut donc pas traverser un tunnel ; WINS fonctionne parce que le client dispose d’une adresse unicast pour s’enregistrer et interroger. C’est pourquoi un VPN ne transportant que de l’IP peut encore prendre en charge les anciens noms quand WINS est configuré et joignable.

nbtstat -n
nbtstat -R

Pour le SMB moderne, fiez-vous au DNS et au nom complet, et mettez l’ancien chemin à la retraite. S’il est vraiment ancien, fournissez WINS ou remplacez l’application ; le juste milieu est une file d’assistance qui ne se vide jamais.

Le parcours s’achève quand vous pouvez dire quelle couche a échoué : résolveur, suffixe ou découverte ancienne. Notez le résolveur qui a répondu et la forme de nom qui a fonctionné, car la personne suivante partira du même symptôme.