Dit CIFS-mount fejler over VPN på grund af rækkefølgen i nsswitch

Tunnelen er oppe. Fileserveren svarer på ping via adresse. Så sidder mount.cifs med værtsnavnet der et stykke tid og melder, at værten ikke kan nås, og du begynder at genopbygge en VPN-profil, som aldrig var problemet. På Linux opløses navnet af glibc, før nogen SMB-pakke findes, og rækkefølgen i den resolver kan afslutte opslaget, før DNS overhovedet bliver spurgt. Her er den vej, jeg går, med udgangspunkt i kommandoen, der fejlede, i stedet for i klienten.

Læs fejlen på det rigtige sted

To værktøjer bruger forskellige veje til det samme navn, og at sammenligne dem koster én kommando. getent går gennem den konfigurerede navnetjenestestak; host og dig spørger DNS direkte og ignorerer den stak. Hvis det direkte opslag returnerer en adresse, og getent intet returnerer, er DNS-serveren tilgængelig, og det er din resolverkonfiguration, der fejler.

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

Den tredje kommando er afgørelsen: den tvinger DNS-kilden og springer resten af stakken over. Når den virker, og den almindelige getent ikke gør, har du bevist, at rækkefølgen er fejlen, ikke tunnelen og ikke serveren.

hosts-linjen er en sekvens, der stopper tidligt

glibc-resolveren læser /etc/nsswitch.conf og går gennem hosts:-posten fra venstre mod højre. Mange distributioner leverer en linje, hvor multicast-opslag kommer først med en tidlig-tilbage-handling hængt på. Handlingen er ikke pynt: når mDNS svarer “not found”, afslutter [NOTFOUND=return] hele opslaget, så det virksomhedsnavn, VPN’en har skubbet, aldrig bliver sendt til den resolver. Intet logger det, fordi der aldrig blev sendt et opslag, som resolveren kunne afvise. Derfor ser mountet ud til at hænge og melder derefter en uopnåelig vært.

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

Flyt DNS foran tidlig-tilbage-handlingen i stedet for at slette mDNS, og ændr det via konfigurationsstyring. En håndrettelse overlever til næste image-build, og så kommer den samme sag fra en anden maskine uden erindring om rettelsen.

En resolver er ikke et søgedomæne

Opslag kræver også, at navnet bliver prøvet. Et ukvalificeret navn som fileserver bliver først fileserver.corp.example, når et søgedomæne er knyttet til det interface, der bærer forespørgslen. En VPN, der skubber en DNS-server uden en søgeliste, giver en meget bestemt opdeling: det fuldt kvalificerede navn opløses, og hvert kort navn fejler.

Test begge former, før du redigerer profilen, for de to fejl peger i hver sin retning. På en systemd-resolved-vært ejer tunnel-linket sine egne servere og routingdomæner, så læs linket i stedet for den globale fil.

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

Hvis forespørgslen henføres til et link, der ikke bærer tunnelen, mangler routingdomænet, selv om DNS-adressen er der. Det er et politikproblem i resolved-konfigurationen, ikke et routingproblem i tunnelen.

Containere bærer deres egen kopi af svaret

En container bygget fra et generisk image leverer normalt en fast resolv.conf. Resolverændringer på værten når ikke ind, og det gør søgedomænet heller ikke, så et build-job, der mounter en deling over tunnelen, fejler, mens den samme kommando virker uden for containeren. Giv containeren sine egne DNS- og søgeindstillinger i compose-filen eller i run-argumenterne, ikke kun i værtens profil.

Kontroller inde i containeren, før du bebrejder image'et. To kommandoer genskaber hele diagnosen på få sekunder, og den anden beviser, hvilken resolver der faktisk svarede.

Først derefter se på delingen og filteret

Når navnet er opløst, er de resterende fejl almindelige netværksfejl. SMB kræver TCP 445 til serveren, og browsing af en arbejdsgruppeliste afhænger af navnetjenester, som tunnelen sandsynligvis ikke videresender. Map efter værtsnavn i stedet for at vente på, at en liste fyldes, og lad klienten fortælle, hvilket trin den nåede. En afvist forbindelse og en tavs timeout er også værd at skelne, for den første betyder som regel, at noget svarede, og den anden at intet gjorde.

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 opløst adresse med port 445 afvist eller timeout er et firewall- eller listenerproblem på den anden side. Et uopløst navn er resolverproblemet. Og et mount, der autentificerer, men returnerer tilladelsesfejl, er ingen af delene, så genåbn ikke netværksspørgsmålet, når sessionen er etableret.

Hold konklusionen så snæver som beviset. Når adressen virker, og navnet ikke gør, passer tunnelen sit arbejde, og rettelsen hører i resolverrækkefølgen, søgedomænet eller containerens egen konfiguration.