Le nom d’hôte du LAN échoue via le VPN : suffixe, mDNS ou zone ?

À côté de l’appareil, l’imprimante répond à un nom court et le serveur de fichiers à un surnom. À travers le tunnel, les deux noms expirent alors que leurs adresses fonctionnent toujours. La route fait son travail ; le chemin de nommage qui faisait fonctionner ces noms courts n’a jamais traversé le tunnel. Trois mécanismes produisent ce comportement, et chacun demande une correction différente.

Commencez par déterminer de quel mécanisme dépend le nom.

Trois sortes de noms qui se comportent différemment

Un nom à une seule étiquette comme fileserver repose généralement sur un suffixe de recherche DNS ajouté par le résolveur. Ce suffixe arrive souvent avec le bail DHCP local, si bien qu’un client distant qui obtient son adressage du VPN n’a aucune raison de le connaître. Ajouter une route ne livre pas le suffixe. Le nom court cesse simplement d’exister en tant que nom, même si l’adresse derrière lui est joignable.

Un nom qui se termine par .local est normalement résolu par DNS multicast sur le lien local, comme le décrit la RFC 6762. Le multicast ne traverse pas un tunnel routé à moins que quelque chose ne le ponte ou n’en fasse un proxy délibérément, donc le nom cesse d’être résolu dès que vous quittez le segment.

Un nom d’entreprise pleinement qualifié appartient à une zone interne servie par les résolveurs de l’organisation. Celui-là fonctionne à distance quand le VPN pousse ces résolveurs et que le client est configuré pour les utiliser. Et localhost est à usage spécial selon la RFC 6761 : il désigne la machine devant vous, jamais un service distant.

Lisez le résolveur avant de changer la route

Demandez quel serveur de noms a répondu et quel suffixe a été ajouté. La même requête via des résolveurs différents donne des réponses différentes, et cette différence est la preuve qu’il vous faut.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Si la requête pleinement qualifiée est résolue mais pas la courte, la panne est dans le suffixe, pas dans le serveur. Si aucune des deux n’est résolue et que l’adresse fonctionne, le client n’utilise pas du tout le résolveur interne. Comparez la liste des résolveurs avec ce que le VPN est censé pousser, car un client qui garde son résolveur local pour chaque requête ne verra jamais la zone interne.

Amenez le bon nom au client

Demandez à l’administrateur le nom d’accès distant documenté, en entier, et utilisez-le dans le profil au lieu de deviner des suffixes. Si le déploiement prend en charge le DNS scindé, configurez le domaine interne pour qu’il soit résolu par les serveurs internes pendant que tout le reste garde le résolveur local. Poussez le domaine de recherche via la configuration VPN là où le client le prend en charge.

Vérifiez le résultat sur le client plutôt que sur la passerelle. Un réglage appliqué sur le serveur qui n’atteint jamais le client ne change rien.

Préservez l’identité du certificat

Un test basé sur l’adresse qui ignore l’erreur de certificat ne prouve qu’une chose : que le socket s’est ouvert. Le certificat du service est émis pour un nom, et le client continuera de refuser la divergence à juste titre. Si le certificat ne liste que le nom interne, utilisez ce nom et corrigez la résolution, ou obtenez un certificat qui couvre l’adresse que vous comptez utiliser.

Notez le nom, le résolveur et le suffixe qui ont produit une connexion réussie. Cette note évite à la personne suivante de répéter le contournement basé sur l’adresse qui masque le vrai problème.