Din CIFS-montering misslyckas över VPN på grund av ordningen i nsswitch

Delningen svarar på adress och hänger på namn, så uppslaget dör innan SMB börjar. Jämför getent med host och läs sedan hosts-raden i ordning.

Tunneln är uppe. Filservern svarar på ping via adress. Sedan sitter mount.cifs med värdnamnet där ett tag och rapporterar att värden är onåbar, och du börjar bygga om en VPN-profil som aldrig var problemet. På Linux löses namnet av glibc innan något SMB-paket existerar, och ordningen i den resolvern kan avsluta uppslaget innan DNS ens har tillfrågats. Här är vägen jag går, med utgångspunkt i kommandot som misslyckades och inte i klienten.

Läs felet på rätt ställe

Två verktyg går olika vägar till samma namn, och att jämföra dem kostar ett kommando. getent går genom den konfigurerade namnservicestacken; host och dig frågar DNS direkt och ignorerar den stacken. Om den direkta frågan returnerar en adress och getent ingenting, är DNS-servern nåbar och det är din resolverkonfiguration som misslyckas.

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

Det tredje kommandot är avgörandet: det tvingar DNS-källan och hoppar över resten av stacken. När det fungerar och det vanliga getent inte gör det, har du bevisat att ordningen är felet, inte tunneln och inte servern.

hosts-raden är en sekvens som stannar tidigt

glibc-resolvern läser /etc/nsswitch.conf och går igenom hosts:-posten från vänster till höger. Många distributioner levererar en rad där multicast-sökningen kommer först med en tidig retur-åtgärd kopplad till sig. Åtgärden är ingen dekoration: när mDNS svarar “not found” avslutar [NOTFOUND=return] hela uppslaget, så företagsnamnet skickas aldrig till den resolver som VPN:et tryckte på. Ingenting loggar det, eftersom ingen fråga någonsin skickades som resolvern kunde avvisa. Därför verkar monteringen hänga och rapporterar sedan en onåbar värd.

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

Flytta DNS före åtgärden för tidig retur i stället för att radera mDNS, och ändra det via konfigurationshantering. En handredigering överlever till nästa image-bygge, och sedan kommer samma ärende från en annan maskin som inte minns fixen.

En resolver är inte en sökdomän

Uppslag kräver också att namnet provas. Ett okvalificerat namn som fileserver blir först fileserver.corp.example när en sökdomän är kopplad till det gränssnitt som bär frågan. Ett VPN som trycker på en DNS-server utan söklista ger en mycket bestämd delning: det fullt kvalificerade namnet löses och varje kortnamn misslyckas.

Testa båda formerna innan du redigerar profilen, för de två felen pekar i olika riktningar. På en systemd-resolved-värd äger tunnellänken sina egna servrar och routingdomäner, så läs länken och inte den globala filen.

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

Om frågan tillskrivs en länk som inte bär tunneln saknas routingdomänen även om DNS-adressen finns. Det är ett policyproblem i resolved-konfigurationen, inte ett routingproblem i tunneln.

Containrar bär sin egen kopia av svaret

En container byggd från en generisk image levererar vanligtvis en fast resolv.conf. Resolverändringar på värden når den inte, och inte heller sökdomänen, så ett build-jobb som monterar en delning över tunneln misslyckas medan samma kommando fungerar utanför containern. Ge containern egna DNS- och sökinställningar i compose-filen eller i run-argumenten, inte bara i värdprofilen.

Kontrollera inne i containern innan du skyller på imagen. Två kommandon återskapar hela diagnosen på några sekunder, och det andra bevisar vilken resolver som faktiskt svarade.

Först då tittar du på delningen och filtret

När namnet är löst är de återstående felen vanliga nätverksfel. SMB behöver TCP 445 till servern, och att bläddra i en arbetsgruppslista beror på namnservicer som tunneln förmodligen inte vidarebefordrar. Mappa efter värdnamn i stället för att vänta på att en lista fylls, och låt klienten berätta vilket steg den nådde. En avvisad anslutning och en tyst timeout är också värda att skilja åt, eftersom den första oftast betyder att något svarade och den andra att 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 adress med port 445 avvisad eller utlupen är ett brandväggs- eller lyssnarproblem på andra sidan. Ett olöst namn är resolverproblemet. Och en montering som autentiserar men returnerar behörighetsfel är inget av dem, så öppna inte nätverksfrågan igen när sessionen väl är etablerad.

Håll slutsatsen lika snäv som bevisen. När adressen fungerar och namnet inte, gör tunneln sitt jobb och fixen hör hemma i resolverordningen, sökdomänen eller containerns egen konfiguration.

Relaterade artiklar