CIFS-mountet ditt feilar over VPN på grunn av rekkjefølgja i nsswitch

Tunnelen er oppe. Filserveren svarar på ping via adresse. Så sit mount.cifs med vertsnamnet der ei stund og melder at verten ikkje er tilgjengeleg, og du byrjar å byggje på nytt ein VPN-profil som aldri var problemet. På Linux blir namnet løyst av glibc før nokon SMB-pakke finst, og rekkjefølgja i den resolvaren kan avslutte oppslaget før DNS i det heile blir spurt. Her er vegen eg går, med utgangspunkt i kommandoen som feila og ikkje i klienten.

Les feilen på rett stad

To verktøy går ulike vegar til same namn, og å samanlikne dei kostar éin kommando. getent går gjennom den konfigurerte namnetenestestakken; host og dig spør DNS direkte og ignorerer den stakken. Viss det direkte oppslaget returnerer ei adresse og getent ingenting, er DNS-serveren tilgjengeleg, og det er resolverkonfigurasjonen din som feilar.

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

Den tredje kommandoen er avgjerda: han tvingar DNS-kjelda og hoppar over resten av stakken. Når han verkar og den vanlege getent ikkje gjer det, har du vist at rekkjefølgja er feilen, ikkje tunnelen og ikkje serveren.

hosts-linja er ein sekvens som stoppar tidleg

glibc-resolvaren les /etc/nsswitch.conf og går gjennom hosts:-oppføringa frå venstre mot høgre. Mange distribusjonar leverer ei linje der multicast-oppslag kjem først med ei tidleg-retur-handling fest til seg. Handlinga er ikkje pynt: når mDNS svarar “not found”, avsluttar [NOTFOUND=return] heile oppslaget, så firmanamnet aldri blir sendt til resolvaren VPN-en dytta på. Ingenting loggar det, fordi ingen spørjing vart send som resolvaren kunne avvise. Derfor ser mountet ut til å henge og melder deretter ein utilgjengeleg vert.

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

Flytt DNS framfor tidleg-retur-handlinga i staden for å slette mDNS, og endre det via konfigurasjonsstyring. Ei handretting overlever til neste image-bygg, og så kjem same sak frå ein annan maskin som ikkje hugser rettinga.

Ein resolver er ikkje eit søkjedomene

Oppslag krev òg at namnet blir prøvd. Eit ukvalifisert namn som fileserver blir først fileserver.corp.example når eit søkjedomene er knytt til grensesnittet som ber spørjinga. Ein VPN som dyttar ein DNS-server utan søkjeliste, gjev ei svært bestemd deling: det fullt kvalifiserte namnet blir løyst og kvart kortnamn feilar.

Test begge former før du redigerer profilen, for dei to feila peikar i kvar si retning. På ein systemd-resolved-vert eig tunnellenkja sine eigne serverar og rutingsdomene, så les lenkja i staden for den globale fila.

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

Viss spørjinga blir tilskriven ei lenkje som ikkje ber tunnelen, manglar rutingsdomenet sjølv om DNS-adressa er der. Det er eit policyproblem i resolved-konfigurasjonen, ikkje eit rutingsproblem i tunnelen.

Containarar ber si eiga kopi av svaret

Ein container bygd frå eit generisk image leverer vanlegvis ein fast resolv.conf. Resolverendringar på verten når ikkje inn, og det gjer heller ikkje søkjedomenet, så ein byggjejobb som mountar ei deling over tunnelen feilar medan same kommando verkar utanfor containaren. Gje containaren eigne DNS- og søkjeinnstillingar i compose-fila eller i run-argumenta, ikkje berre i vertsprofilen.

Kontroller inne i containaren før du klandrar image-et. To kommandoar attskapar heile diagnosen på nokre sekund, og den andre viser kva resolver som faktisk svara.

Først då ser du på delinga og filteret

Når namnet er løyst, er dei attverande feila vanlege nettverksfeil. SMB treng TCP 445 til serveren, og å bla i ei arbeidsgruppeliste avheng av namnetenester tunnelen truleg ikkje sender vidare. Map etter vertsnamn i staden for å vente på at ei liste blir fylt, og la klienten fortelje deg kva trinn han nådde. Ei avvist tilkopling og ein stille timeout er òg verd å skilje, for den første tyder vanlegvis at noko svara og den andre at ingenting gjorde det.

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

Ei løyst adresse med port 445 avvist eller utløpt er eit brannmur- eller lyttarproblem på den andre sida. Eit uløyst namn er resolverproblemet. Og eit mount som autentiserer men returnerer tilgangsfeil, er ingen av delane, så ikkje opne nettverksspørsmålet igjen når økta først står.

Hald konklusjonen like smal som provet. Når adressa verkar og namnet ikkje, gjer tunnelen jobben sin, og rettinga høyrer i resolverrekkjefølgja, søkjedomenet eller containaren si eiga konfigurering.