Il tuo mount CIFS fallisce sul VPN per l’ordine in nsswitch

Il tunnel è su. Il file server risponde a un ping per indirizzo. Poi mount.cifs con il nome host resta lì un po’ e segnala che l’host non è raggiungibile, e tu cominci a ricostruire un profilo VPN che non è mai stato il problema. Su Linux glibc risolve il nome prima che esista un solo pacchetto SMB, e l’ordine in quel resolver può chiudere la ricerca prima che DNS venga mai interrogato. Ecco il percorso che faccio, partendo dal comando che ha fallito e non dal client.

Leggi il guasto nel posto giusto

Due strumenti seguono percorsi diversi verso lo stesso nome, e confrontarli costa un comando. getent percorre lo stack dei servizi di nome configurato; host e dig interrogano DNS direttamente e ignorano quello stack. Se la query diretta restituisce un indirizzo e getent non restituisce nulla, il server DNS è raggiungibile ed è la tua configurazione del resolver a fallire.

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

Il terzo comando è quello decisivo: forza la sorgente DNS e salta il resto dello stack. Quando funziona e il semplice getent no, hai dimostrato che è l’ordine il colpevole, non il tunnel e non il server.

La riga hosts è una sequenza che si ferma presto

Il resolver glibc legge /etc/nsswitch.conf e percorre la voce hosts: da sinistra a destra. Molte distribuzioni forniscono una riga in cui la ricerca multicast viene per prima con un’azione di ritorno anticipato collegata. L’azione non è decorazione: quando mDNS risponde “not found”, [NOTFOUND=return] chiude tutta la ricerca, così il nome aziendale non viene mai inviato al resolver che il VPN ha imposto. Nulla lo registra, perché non è stata inviata alcuna query che il resolver potesse rifiutare. Per questo il mount sembra bloccarsi e poi segnala un host irraggiungibile.

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

Metti DNS prima dell’azione di ritorno anticipato invece di eliminare mDNS, e cambialo tramite gestione della configurazione. Una modifica manuale sopravvive fino alla prossima build dell’immagine, e poi lo stesso ticket arriva da un’altra macchina che non ricorda la correzione.

Un resolver non è un dominio di ricerca

La risoluzione richiede anche che il nome venga provato. Un nome non qualificato come fileserver diventa fileserver.corp.example solo quando un dominio di ricerca è agganciato all’interfaccia che porta la query. Un VPN che impone un server DNS senza lista di ricerca produce una divisione molto precisa: il nome completamente qualificato si risolve e ogni nome breve fallisce.

Prova entrambe le forme prima di modificare il profilo, perché i due guasti puntano in direzioni diverse. Su un host con systemd-resolved il link del tunnel ha i propri server e domini di routing, quindi leggi il link e non il file globale.

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

Se la query è attribuita a un link che non porta il tunnel, manca il dominio di routing anche se l’indirizzo DNS è presente. È un problema di policy nella configurazione di resolved, non un problema di routing nel tunnel.

I container portano la propria copia della risposta

Un container costruito da un’immagine generica di solito fornisce un resolv.conf fisso. Le modifiche al resolver fatte sull’host non lo raggiungono, e nemmeno il dominio di ricerca, quindi un job di build che monta una condivisione sul tunnel fallisce mentre lo stesso comando funziona fuori dal container. Dai al container le sue impostazioni DNS e di ricerca nel file compose o negli argomenti di run, non solo nel profilo dell’host.

Controlla dentro il container prima di dare la colpa all’immagine. Due comandi riproducono tutta la diagnosi in pochi secondi, e il secondo dimostra quale resolver ha risposto davvero.

Solo allora guarda la condivisione e il filtro

Una volta risolto il nome, i guasti rimasti sono di rete ordinari. SMB ha bisogno di TCP 445 verso il server, e sfogliare un elenco di gruppo di lavoro dipende da servizi di nome che il tunnel probabilmente non inoltra. Mappa per nome host invece di aspettare che un elenco si popoli, e lascia che il client ti dica a quale fase è arrivato. Una connessione rifiutata e un silenzio per timeout meritano anch’essi di essere separati, perché il primo di solito significa che qualcosa ha risposto e il secondo che non ha risposto nulla.

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

Un indirizzo risolto con la porta 445 rifiutata o scaduta è un problema di firewall o di listener dall’altra parte. Un nome non risolto è il problema del resolver. E un mount che si autentica ma restituisce errori di permessi non è né l’uno né l’altro, quindi non riaprire la questione di rete una volta stabilita la sessione.

Tieni la conclusione stretta quanto la prova. Quando l’indirizzo funziona e il nome no, il tunnel fa il suo lavoro e la correzione sta nell’ordine del resolver, nel dominio di ricerca o nella configurazione propria del container.