Votre montage CIFS échoue sur le VPN à cause de l’ordre dans nsswitch

Le tunnel est monté. Le serveur de fichiers répond à un ping par adresse. Puis mount.cifs avec le nom d’hôte reste planté un moment et signale que l’hôte est injoignable, et vous commencez à reconstruire un profil VPN qui n’a jamais été le problème. Sous Linux, glibc résout le nom avant qu’aucun paquet SMB n’existe, et l’ordre dans ce résolveur peut terminer la résolution avant même que DNS soit interrogé. Voici la démarche que je suis, en partant de la commande qui a échoué plutôt que du client.

Lisez la panne au bon endroit

Deux outils suivent des chemins différents vers le même nom, et les comparer coûte une commande. getent parcourt la pile de services de noms configurée ; host et dig interrogent DNS directement et ignorent cette pile. Si la requête directe renvoie une adresse et que getent ne renvoie rien, le serveur DNS est joignable et c’est votre configuration de résolveur qui échoue.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

La troisième commande est l’arbitre : elle force la source DNS et saute le reste de la pile. Quand elle fonctionne et que le getent simple ne fonctionne pas, vous avez prouvé que c’est l’ordre qui est en cause, ni le tunnel ni le serveur.

La ligne hosts est une séquence qui s’arrête tôt

Le résolveur glibc lit /etc/nsswitch.conf et parcourt l’entrée hosts: de gauche à droite. Beaucoup de distributions livrent une ligne où la recherche multicast vient en premier avec une action de retour anticipé attachée. L’action n’est pas décorative : quand mDNS répond « not found », [NOTFOUND=return] met fin à toute la résolution, donc le nom d’entreprise n’est jamais envoyé au résolveur que le VPN a poussé. Rien ne le journalise, parce qu’aucune requête n’a été envoyée que le résolveur aurait pu rejeter. C’est pourquoi le montage semble bloquer puis signale un hôte injoignable.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

Placez DNS avant l’action de retour anticipé plutôt que de supprimer mDNS, et changez-le par gestion de configuration. Une modification manuelle survit jusqu’au prochain build d’image, et ensuite le même ticket arrive depuis une autre machine qui ne se souvient pas du correctif.

Un résolveur n’est pas un domaine de recherche

La résolution exige aussi que le nom soit essayé. Un nom non qualifié comme fileserver ne devient fileserver.corp.example que lorsqu’un domaine de recherche est attaché à l’interface qui porte la requête. Un VPN qui pousse un serveur DNS sans liste de recherche produit un découpage très précis : le nom pleinement qualifié se résout et tous les noms courts échouent.

Testez les deux formes avant de modifier le profil, car les deux échecs pointent dans des directions différentes. Sur un hôte systemd-resolved, le lien du tunnel possède ses propres serveurs et domaines de routage, donc lisez le lien plutôt que le fichier global.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Si la requête est attribuée à un lien qui ne porte pas le tunnel, le domaine de routage manque alors même que l’adresse DNS est présente. C’est un problème de politique dans la configuration de resolved, pas un problème de routage dans le tunnel.

Les conteneurs portent leur propre copie de la réponse

Un conteneur construit à partir d’une image générique livre généralement un resolv.conf figé. Les changements de résolveur faits sur l’hôte ne l’atteignent pas, et le domaine de recherche non plus, donc une tâche de build qui monte un partage par le tunnel échoue alors que la même commande fonctionne hors du conteneur. Donnez au conteneur ses propres réglages DNS et de recherche dans le fichier compose ou dans les arguments d’exécution, pas seulement dans le profil de l’hôte.

Vérifiez à l’intérieur du conteneur avant d’accuser l’image. Deux commandes reproduisent tout le diagnostic en quelques secondes, et la seconde prouve quel résolveur a réellement répondu.

C’est seulement ensuite qu’il faut regarder le partage et le filtre

Une fois le nom résolu, les échecs restants sont des problèmes réseau ordinaires. SMB a besoin de TCP 445 vers le serveur, et parcourir une liste de groupe de travail dépend de services de noms que le tunnel ne relaie probablement pas. Mappez par nom d’hôte au lieu d’attendre qu’une liste se remplisse, et laissez le client vous dire à quelle étape il est arrivé. Une connexion refusée et un silence par expiration méritent aussi d’être distingués, car la première signifie généralement que quelque chose a répondu et le second que rien ne l’a fait.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Une adresse résolue avec le port 445 refusé ou expiré est un problème de pare-feu ou d’écouteur de l’autre côté. Un nom non résolu est le problème du résolveur. Et un montage qui s’authentifie mais renvoie des erreurs de permissions n’est ni l’un ni l’autre, alors ne rouvrez pas la question réseau une fois la session établie.

Gardez la conclusion aussi étroite que la preuve. Quand l’adresse fonctionne et que le nom non, le tunnel fait son travail et le correctif relève de l’ordre du résolveur, du domaine de recherche ou de la configuration propre au conteneur.