mDNS derrière un VPN : pourquoi les noms .local ne se résolvent pas

L’imprimante du bureau apparaît dans toutes les applications de votre poste et disparaît sur le VPN, alors même que vous pouvez pinguer l’adresse que vous savez qu’elle possède. Rien dans le tunnel n’est cassé : la découverte et l’accessibilité sont des services distincts, et un seul d’entre eux traverse un tunnel routé par défaut. Les vérifications ci-dessous les séparent avant que vous n’ajoutiez des routes. Une route ne peut pas corriger une requête qui n’a jamais quitté le lien.

Vérifiez ce qui se résout aujourd’hui et ce qui semble seulement résolu

Séparez d’abord les deux questions : une requête unicast pour un nom d’hôte interroge un résolveur, tandis qu’une recherche de _ipp._tcp interroge le lien local. Sous Linux, avahi-browse -a montre ce que le DNS multicast peut voir, et resolvectl query name.local montre ce que la pile de résolution fait de ce nom. Sous macOS, dns-sd -B _ipp._tcp liste les services découverts sans avoir d’abord besoin d’une adresse.

Si l’adresse répond et que le nom ne répond pas, le routage fonctionne et la découverte non. Un nom .local peut aussi être résolu sur l’hôte lui-même via nss-mdns sans que avahi-browse soit installé, donc un getent ou un ping réussi vers ce nom ne prouve pas que la découverte a traversé le tunnel ; le résultat de la recherche et celui du résolveur sont des preuves différentes. Les applications mettent en cache ce qu’elles ont découvert, ce qui explique que la panne apparaisse souvent des heures après la connexion plutôt qu’à la connexion. Fermez et rouvrez l’application, puis vérifiez si l’entrée en cache contient un nom ou une adresse, car une adresse continue de fonctionner longtemps après l’arrêt de la découverte.

Pourquoi la requête ne traverse jamais le tunnel

Le DNS multicast envoie ses requêtes à 224.0.0.251, à l’intérieur du bloc de contrôle du réseau local, sur le port UDP 5353. Les routeurs ne transmettent pas les adresses de ce bloc, donc la requête reste sur le lien où elle a été envoyée. Les émetteurs fixent aussi le TTL IP, ou la limite de sauts IPv6, à 255 pour qu’un récepteur puisse rejeter un paquet qui a déjà traversé un routeur ; c’est ainsi que le protocole détecte l’usurpation hors lien, et non ainsi qu’il reste local. La localité vient de l’adresse de destination, pas d’un TTL d’un seul saut.

Le type de tunnel compte aussi. Une interface de type tun ne transporte que des paquets IP, donc aucun groupe multicast n’y survit. Un pont de type tap étend le domaine de diffusion lui-même, ce qui explique que certaines conceptions anciennes aient ponté au lieu de router, et hérité de tous les problèmes que le pont apporte.

Une exception pour un LAN de confiance ne change rien à cela, car elle décide quel trafic peut utiliser le tunnel au lieu d’apprendre au tunnel à transmettre le multicast. Le paquet n’a toujours aucun segment partagé où être entendu.

Choisissez une conception de nommage que vous pouvez maintenir

Pour les ressources de l’entreprise, la réponse durable est un nom d’hôte routé, servi par le résolveur que le VPN pousse, avec un DNS scindé pour que les noms internes aillent aux serveurs internes et que tout le reste n’y aille pas. Windows l’expose sous forme de table de stratégie de résolution de noms, macOS utilise des résolveurs restreints par interface, et la plupart des clients disposent d’un réglage de poussée équivalent. L’appareil garde son nom habituel dans le DNS interne, et la découverte cesse de faire partie du chemin.

Un proxy de découverte ou un réflecteur mDNS peut combler l’écart, et c’est une conception réelle avec son propre hôte, sa propre exposition et ses propres exigences côté client. Elle n’apparaît pas parce que vous avez ajouté une route. Ne transmettez jamais de requêtes .local à un résolveur public : le domaine est réservé à un usage multicast local par RFC 6762, et l’envoyer vers l’extérieur produit des échecs lents et une divulgation inutile de données.

Vérifiez le service, pas le nom

Un nom dans une liste de recherche prouve l’étape de découverte, pas que le service répond. Ouvrez la file d’impression ou l’interface web et effectuez une opération réelle, puis répétez-la après une reconnexion.

La découverte met agressivement les noms en cache, si bien qu’une entrée obsolète peut ressembler à un succès. Si un certificat ou une demande d’authentification apparaît, c’est la couche suivante et un problème distinct. Notez quel mécanisme vous avez modifié, résolveur ou découverte, pour que la personne suivante n’ait pas à rouvrir toute la question.