Montarea CIFS eșuează prin VPN din cauza ordinii din nsswitch

Tunelul este activ. Serverul de fișiere răspunde la ping după adresă. Apoi mount.cifs cu numele gazdei stă acolo o vreme și raportează că gazda este inaccesibilă, iar dumneavoastră începeți să reconstruiți un profil VPN care nu a fost niciodată problema. Pe Linux numele este rezolvat de glibc înainte să existe vreun pachet SMB, iar ordinea din acel resolver poate încheia căutarea înainte ca DNS să fie măcar întrebat. Iată drumul pe care îl urmez, pornind de la comanda care a eșuat, nu de la client.

Citiți eșecul în locul potrivit

Două unelte merg pe căi diferite către același nume, iar compararea lor costă o singură comandă. getent parcurge stiva de servicii de nume configurată; host și dig interoghează DNS direct și ignoră acea stivă. Dacă interogarea directă returnează o adresă, iar getent nu returnează nimic, serverul DNS este accesibil și configurația resolverului este cea care eșuează.

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

A treia comandă este decisivă: forțează sursa DNS și sare peste restul stivei. Când aceasta funcționează, iar getent simplu nu, ați dovedit că vina este a ordinii, nu a tunelului și nu a serverului.

Linia hosts este o secvență care se oprește devreme

Resolverul glibc citește /etc/nsswitch.conf și parcurge intrarea hosts: de la stânga la dreapta. Multe distribuții livrează o linie în care căutarea multicast vine prima, cu o acțiune de întoarcere timpurie atașată. Acțiunea nu este decor: când mDNS răspunde “not found”, [NOTFOUND=return] încheie întreaga căutare, așa că numele corporativ nu este trimis niciodată resolverului impus de VPN. Nimic nu înregistrează asta, pentru că nu a fost trimisă nicio interogare pe care resolverul să o poată respinge. De aceea montarea pare să se blocheze și apoi raportează o gazdă inaccesibilă.

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

Mutați DNS înaintea acțiunii de întoarcere timpurie în loc să ștergeți mDNS, și schimbați asta prin managementul configurației. O modificare manuală supraviețuiește până la următoarea construcție de imagine, iar apoi același tichet sosește de la o altă mașină care nu își amintește remedierea.

Un resolver nu este un domeniu de căutare

Rezolvarea are nevoie și ca numele să fie încercat. Un nume necalificat precum fileserver devine fileserver.corp.example doar când un domeniu de căutare este atașat interfeței care poartă interogarea. Un VPN care impune un server DNS fără listă de căutare produce o împărțire foarte specifică: numele complet calificat se rezolvă și fiecare nume scurt eșuează.

Testați ambele forme înainte de a edita profilul, pentru că cele două eșecuri indică direcții diferite. Pe o gazdă cu systemd-resolved legătura tunelului are propriile servere și domenii de rutare, așa că citiți legătura, nu fișierul global.

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

Dacă interogarea este atribuită unei legături care nu poartă tunelul, domeniul de rutare lipsește chiar dacă adresa DNS este prezentă. Aceasta este o problemă de politică în configurația resolved, nu o problemă de rutare în tunel.

Containerele poartă propria copie a răspunsului

Un container construit dintr-o imagine generică aduce de obicei un resolv.conf fix. Modificările de resolver făcute pe gazdă nu ajung la el, nici domeniul de căutare, așa că un job de build care montează o partajare prin tunel eșuează, în timp ce aceeași comandă funcționează în afara containerului. Dați containerului propriile setări DNS și de căutare în fișierul compose sau în argumentele run, nu doar în profilul gazdei.

Verificați în interiorul containerului înainte de a da vina pe imagine. Două comenzi reproduc întregul diagnostic în câteva secunde, iar a doua dovedește care resolver a răspuns de fapt.

Abia apoi priviți partajarea și filtrul

Odată ce numele se rezolvă, eșecurile rămase sunt probleme obișnuite de rețea. SMB are nevoie de TCP 445 către server, iar navigarea într-o listă de grup de lucru depinde de servicii de nume pe care tunelul probabil nu le transmite. Maparea după numele gazdei în loc de așteptarea umplerii unei liste, și lăsați clientul să spună la ce etapă a ajuns. O conexiune refuzată și un timeout tăcut merită și ele separate, pentru că primul înseamnă de obicei că ceva a răspuns, iar al doilea că nimic nu a răspuns.

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

O adresă rezolvată cu portul 445 refuzat sau expirat este o problemă de firewall sau de listener de cealaltă parte. Un nume nerezolvat este problema resolverului. Iar o montare care se autentifică dar returnează erori de permisiune nu este nici una, nici alta, așa că nu redeschideți întrebarea de rețea odată ce sesiunea este stabilită.

Păstrați concluzia la fel de îngustă ca dovezile. Când adresa funcționează și numele nu, tunelul își face treaba, iar remedierea ține de ordinea resolverului, de domeniul de căutare sau de configurația proprie a containerului.