Le DNS du VPN fonctionne, mais les noms .local échouent encore : qui les résout ?

Deux machines sur le même VPN, le même nom d’hôte, et une seule le résout : la différence n’est généralement pas le tunnel mais quel résolveur a répondu. Sur un bureau Linux, ce nom peut passer par le commutateur de services de noms, par le stub de systemd-resolved ou par un résolveur que l’application a apporté avec elle, et chacun applique sa propre règle au même suffixe. C’est sur le suffixe que les règles divergent, car .local n’est pas une étiquette neutre. Déterminez quel chemin le programme qui échoue emprunte réellement avant de changer l’ordre dans lequel quoi que ce soit s’exécute.

Deux résolveurs, deux réponses différentes

Une recherche glibc classique parcourt la ligne hosts: de nsswitch.conf et interroge chaque module tour à tour jusqu’à ce que l’un réponde. Un client qui parle à systemd-resolved via le stub listener interroge plutôt un seul processus, et ce processus applique une politique par lien plus ses propres cas particuliers. Une application qui embarque son propre résolveur, ou qui lie une bibliothèque qui le fait, peut contourner les deux. Un nom d’hôte peut donc avoir trois propriétaires sur une même machine, et un seul sait ce que le VPN voulait.

Identifiez le propriétaire avant de changer quoi que ce soit, car le correctif diffère pour chacun des trois. Un navigateur et un outil en ligne de commande sur le même bureau peuvent légitimement être en désaccord, et ce désaccord est l’indice, pas le bug. Si le navigateur résout le nom et que l’outil ne le fait pas, vous déboguez un chemin de résolveur et non une route VPN. Confirmez la route séparément, pour qu’une panne de routage ne soit pas confondue avec une panne de service de noms. Quand les deux sont d’accord, la panne est en amont de l’hôte et la configuration du résolveur ici ne vaut pas une autre modification.

Quelle commande a réellement interrogé votre résolveur

Deux commandes en lecture seule répondent à des questions liées, et les comparer localise le problème plus vite que lire la configuration. Utilisez un vrai nom interne et gardez la sortie privée, car les enregistrements internes restent internes. Lancez les deux dans la même session que celle où tourne le programme qui échoue :

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

La première interroge via les modules configurés, ce qu’un programme typique expérimente. La seconde interroge directement systemd-resolved et rapporte le lien, le protocole et le serveur qui a répondu. Interroger le serveur d’entreprise par adresse prouve seulement que le serveur détient l’enregistrement, car cela ne dit rien sur le fait que l’application l’ait jamais interrogé. Lisez le lien qui porte le VPN et les domaines qu’il revendique, puis comparez cette liste au suffixe du nom qui échoue.

Pourquoi .local contourne votre zone unicast

la référence de systemd-resolved indique que les noms à plusieurs étiquettes se terminant par .local vont normalement vers DNS multicast lorsque mDNS est activé, plutôt que vers le DNS unicast ordinaire. Le RFC 6762 réserve cet espace de noms au multicast lien-local, si bien qu’une zone d’entreprise peut détenir un enregistrement correct qui n’est jamais consulté pour ce suffixe. Le tunnel peut router le résolveur parfaitement et perdre la course quand même. Un ping qui réussit depuis un cache ne dit rien sur la recherche qui vient d’avoir lieu.

Il existe une exception documentée, et elle règle la plupart de ces cas : lorsqu’un lien déclare ce suffixe comme domaine de recherche ou domaine de routage, le démon le garde sur le chemin unicast et saute le cas particulier multicast. C’est une politique par lien et non une préférence globale. Deux machines avec le même serveur VPN peuvent se comporter différemment si un profil réseau déclare le domaine et l’autre non, alors lisez le profil actif plutôt que celui dont vous vous souvenez l’avoir modifié.

L’exception étroite bat un réordonnancement global

Pour une zone existante que vous ne pouvez pas renommer, faites déclarer le domaine par les responsables du résolveur et du VPN sur la connexion qui le porte. Une entrée de domaine de routage pour ce seul suffixe plus l’adresse de serveur prévue est un petit changement avec un propriétaire nommé, et elle vit avec le lien plutôt que dans un fichier modifié à la main.

Elle survit aussi à une déconnexion, car la politique du lien est réappliquée quand le lien revient. Modifier le nsswitch.conf partagé est l’alternative tentante et la plus coûteuse, car elle change le comportement de recherche pour chaque nom de la machine, y compris la découverte locale. Désactiver le démon multicast n’est pas équivalent non plus : cela retire le comportement local sans apprendre la zone d’entreprise à aucun résolveur. Si le service est nouveau plutôt qu’hérité, placez-le sous un sous-domaine que votre organisation contrôle et sautez la compétition entièrement. Choisissez l’exception étroite quand le nom est figé dans le micrologiciel ou imprimé sur une étiquette, et choisissez un nouveau sous-domaine quand vous contrôlez encore le client.

Ce qu’il faut prouver après le changement

Prouvez le correctif avec la recherche propre à l’application plutôt qu’avec un outil installé pour tester, et videz tout cache qui pourrait répondre à sa place. Confirmez ensuite le chemin du résolveur et le lien qui a servi la réponse. Enfin vérifiez que la découverte locale se comporte comme avant le changement, car l’imprimante qui cesse d’apparaître est la partie que les gens remarquent en dernier. Ces trois commandes vérifient le nom, le chemin et l’identité TLS dans cet ordre :

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Une adresse correcte avec le mauvais certificat fait toujours échouer un client strict, alors vérifiez le nom attendu par l’application une fois la résolution fonctionnelle. Confirmez que le service accepte les connexions depuis l’adresse VPN et pas seulement depuis la plage du bureau. Écrivez la portée du domaine, le serveur et le propriétaire dans la documentation de la connexion. Sinon, la prochaine personne confrontée à cette panne se tournera vers la même modification globale que vous venez d’éviter.