CIFS-mountet ditt feiler over VPN på grunn av rekkefølgen i nsswitch

Tunnelen er oppe. Filserveren svarer på ping via adresse. Så sitter mount.cifs med vertsnavnet der en stund og melder at verten ikke er tilgjengelig, og du begynner å bygge på nytt en VPN-profil som aldri var problemet. På Linux løses navnet av glibc før noen SMB-pakke finnes, og rekkefølgen i den resolveren kan avslutte oppslaget før DNS i det hele tatt blir spurt. Her er veien jeg går, med utgangspunkt i kommandoen som feilet og ikke i klienten.

Les feilen på riktig sted

To verktøy går ulike veier til samme navn, og å sammenligne dem koster én kommando. getent går gjennom den konfigurerte navnetjenestestakken; host og dig spør DNS direkte og ignorerer den stakken. Hvis det direkte oppslaget returnerer en adresse og getent ingenting, er DNS-serveren tilgjengelig, og det er resolverkonfigurasjonen din som feiler.

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

Den tredje kommandoen er avgjørelsen: den tvinger DNS-kilden og hopper over resten av stakken. Når den virker og den vanlige getent ikke gjør det, har du bevist at rekkefølgen er feilen, ikke tunnelen og ikke serveren.

hosts-linjen er en sekvens som stopper tidlig

glibc-resolveren leser /etc/nsswitch.conf og går gjennom hosts:-oppføringen fra venstre mot høyre. Mange distribusjoner leverer en linje der multicast-oppslag kommer først med en tidlig-retur-handling festet til seg. Handlingen er ikke pynt: når mDNS svarer “not found”, avslutter [NOTFOUND=return] hele oppslaget, så bedriftsnavnet aldri sendes til resolveren VPN-en dyttet på. Ingenting logger det, fordi ingen spørring ble sendt som resolveren kunne avvise. Derfor ser mountet ut til å henge og melder deretter en utilgjengelig 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 foran tidlig-retur-handlingen i stedet for å slette mDNS, og endre det via konfigurasjonsstyring. En håndretting overlever til neste image-bygg, og så kommer samme sak fra en annen maskin som ikke husker rettelsen.

En resolver er ikke et søkedomene

Oppslag krever også at navnet blir prøvd. Et ukvalifisert navn som fileserver blir først fileserver.corp.example når et søkedomene er knyttet til grensesnittet som bærer spørringen. En VPN som dytter en DNS-server uten søkeliste, gir en svært bestemt deling: det fullt kvalifiserte navnet løses og hvert kortnavn feiler.

Test begge former før du redigerer profilen, for de to feilene peker i hver sin retning. På en systemd-resolved-vert eier tunnellinken sine egne servere og rutingsdomener, så les linken i stedet for den globale filen.

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

Hvis spørringen tilskrives en link som ikke bærer tunnelen, mangler rutingsdomenet selv om DNS-adressen er der. Det er et policyproblem i resolved-konfigurasjonen, ikke et rutingsproblem i tunnelen.

Containere bærer sin egen kopi av svaret

En container bygget fra et generisk image leverer vanligvis en fast resolv.conf. Resolverendringer på verten når ikke inn, og det gjør heller ikke søkedomenet, så en byggejobb som mounter en deling over tunnelen feiler mens samme kommando virker utenfor containeren. Gi containeren egne DNS- og søkeinnstillinger i compose-filen eller i run-argumentene, ikke bare i vertsprofilen.

Kontroller inne i containeren før du klandrer image-et. To kommandoer gjenskaper hele diagnosen på noen sekunder, og den andre beviser hvilken resolver som faktisk svarte.

Først da ser du på delingen og filteret

Når navnet er løst, er de gjenværende feilene vanlige nettverksfeil. SMB trenger TCP 445 til serveren, og å bla i en arbeidsgruppeliste avhenger av navnetjenester tunnelen sannsynligvis ikke videresender. Map etter vertsnavn i stedet for å vente på at en liste fylles, og la klienten fortelle deg hvilket trinn den nådde. En avvist tilkobling og en stille timeout er også verdt å skille, for den første betyr vanligvis at noe svarte 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

En løst adresse med port 445 avvist eller utløpt er et brannmur- eller lytterproblem på den andre siden. Et uløst navn er resolverproblemet. Og et mount som autentiserer men returnerer tilgangsfeil, er ingen av delene, så ikke åpne nettverksspørsmålet igjen når økten først står.

Hold konklusjonen like smal som beviset. Når adressen virker og navnet ikke, gjør tunnelen jobben sin, og rettelsen hører i resolverrekkefølgen, søkedomenet eller containerens egen konfigurasjon.