El muntatge CIFS falla per VPN per l’ordre de nsswitch

El túnel està aixecat. El servidor de fitxers respon un ping per adreça. Llavors mount.cifs amb el nom d’amfitrió s’hi està una estona i informa que l’amfitrió no és accessible, i comenceu a refer un perfil VPN que mai no era el problema. A Linux, glibc resol el nom abans que existeixi cap paquet SMB, i l’ordre d’aquell resolutor pot acabar la consulta abans que es pregunti mai DNS. Aquest és el camí que faig, començant per l’ordre que va fallar i no pel client.

Llegiu la fallada al lloc correcte

Dues eines segueixen camins diferents cap al mateix nom, i comparar-les costa una ordre. getent recorre la pila de serveis de noms configurada; host i dig consulten DNS directament i ignoren aquesta pila. Si la consulta directa torna una adreça i getent no torna res, el servidor DNS és accessible i el que falla és la vostra configuració del resolutor.

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

La tercera ordre és la que decideix: força la font DNS i salta la resta de la pila. Quan funciona i el getent simple no, heu demostrat que la culpa és de l’ordre, no del túnel ni del servidor.

La línia hosts és una seqüència que s’atura aviat

El resolutor glibc llegeix /etc/nsswitch.conf i recorre l’entrada hosts: d’esquerra a dreta. Moltes distribucions porten una línia on la consulta multicast va primer amb una acció de retorn primerenc enganxada. L’acció no és decoració: quan mDNS respon “not found”, [NOTFOUND=return] acaba tota la consulta, així que el nom corporatiu no s’envia mai al resolutor que ha empès la VPN. Res ho registra, perquè no s’ha enviat cap consulta que el resolutor pugui rebutjar. Per això el muntatge sembla que s’encalli i després informa d’un amfitrió inaccessible.

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

Poseu DNS abans de l’acció de retorn primerenc en lloc d’esborrar mDNS, i canvieu-ho a través de la gestió de configuració. Una edició manual sobreviu fins a la propera compilació de la imatge, i llavors el mateix tiquet arriba des d’una altra màquina que no recorda la correcció.

Un resolutor no és un domini de cerca

La resolució també necessita que el nom es provi. Un nom no qualificat com fileserver només es converteix en fileserver.corp.example quan un domini de cerca s’adjunta a la interfície que porta la consulta. Una VPN que empeny un servidor DNS sense llista de cerca produeix una divisió molt concreta: el nom completament qualificat es resol i tots els noms curts fallen.

Proveu les dues formes abans d’editar el perfil, perquè les dues fallades assenyalen direccions diferents. En un amfitrió amb systemd-resolved l’enllaç del túnel té els seus propis servidors i dominis d’encaminament, així que llegiu l’enllaç i no el fitxer global.

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

Si la consulta s’atribueix a un enllaç que no porta el túnel, falta el domini d’encaminament encara que l’adreça DNS hi sigui. És un problema de política a la configuració de resolved, no un problema d’encaminament al túnel.

Els contenidors porten la seva pròpia còpia de la resposta

Un contenidor construït amb una imatge genèrica normalment porta un resolv.conf fix. Els canvis de resolutor fets a l’amfitrió no hi arriben, ni tampoc el domini de cerca, així que un treball de compilació que munta el recurs pel túnel falla mentre la mateixa ordre funciona fora del contenidor. Doneu al contenidor la seva pròpia configuració DNS i de cerca al fitxer compose o als arguments d’execució, no només al perfil de l’amfitrió.

Comproveu dins del contenidor abans de culpar la imatge. Dues ordres reprodueixen tot el diagnòstic en uns segons, i la segona demostra quin resolutor ha respost realment.

Només llavors mireu el recurs i el filtre

Un cop el nom es resol, les fallades restants són de xarxa ordinàries. SMB necessita TCP 445 cap al servidor, i navegar per una llista de grup de treball depèn de serveis de noms que la VPN probablement no reenvia. Mapeu pel nom d’amfitrió en lloc d’esperar que s’ompli una llista, i deixeu que el client us digui a quina etapa ha arribat. Una connexió rebutjada i un temps d’espera silenciós també val la pena separar-los, perquè la primera sol voler dir que alguna cosa ha respost i el segon que no ha respost res.

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

Una adreça resolta amb el port 445 rebutjat o esgotat és un problema de tallafocs o d’oient a l’altre costat. Un nom sense resoldre és el problema del resolutor. I un muntatge que s’autentica però retorna errors de permisos no és ni una cosa ni l’altra, així que no torneu a obrir la qüestió de xarxa quan la sessió ja està establerta.

Manteniu la conclusió tan estreta com l’evidència. Quan l’adreça funciona i el nom no, el túnel fa la seva feina i la correcció pertany a l’ordre del resolutor, al domini de cerca o a la configuració pròpia del contenidor.