Vaš mount CIFS ne uspe prek VPN zaradi vrstnega reda v nsswitch

Tunel je vzpostavljen. Datotečni strežnik odgovori na ping po naslovu. Nato mount.cifs z imenom gostitelja nekaj časa stoji in sporoči, da je gostitelj nedosegljiv, vi pa začnete znova graditi profil VPN, ki nikoli ni bil težava. V Linuxu ime razreši glibc, preden obstaja kakršen koli paket SMB, in vrstni red v tem razreševalniku lahko konča iskanje, preden je DNS sploh vprašan. To je pot, ki jo hodim, začenši s ukazom, ki ni uspel, ne s odjemalcem.

Preberite napako na pravem mestu

Dve orodji hodita po različnih poteh do istega imena in njuna primerjava stane en ukaz. getent gre skozi nastavljeni sklad imenskih storitev; host in dig sprašujeta DNS neposredno in ta sklad ignorirata. Če neposredna poizvedba vrne naslov, getent pa nič, je strežnik DNS dosegljiv in ne uspeva vaša konfiguracija razreševalnika.

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

Tretji ukaz je odločilen: vsili vir DNS in preskoči preostanek sklada. Ko ta deluje, običajni getent pa ne, ste dokazali, da je kriv vrstni red, ne tunel in ne strežnik.

Vrstica hosts je zaporedje, ki se ustavi zgodaj

Razreševalnik glibc prebere /etc/nsswitch.conf in gre skozi vnos hosts: od leve proti desni. Mnoge distribucije dobavijo vrstico, v kateri je iskanje multicast prvo z dodanim dejanjem zgodnjega vračanja. To dejanje ni okras: ko mDNS odgovori “not found”, [NOTFOUND=return] konča celotno iskanje, zato se korporativno ime nikoli ne pošlje razreševalniku, ki ga je vsilil VPN. Nič tega ne zabeleži, ker ni bila poslana nobena poizvedba, ki bi jo razreševalnik lahko zavrnil. Zato se zdi, da se mount obesi, in nato sporoči nedosegljivega gostitelja.

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

Premaknite DNS pred dejanje zgodnjega vračanja, namesto da bi izbrisali mDNS, in to spreminjajte prek upravljanja konfiguracije. Ročni popravek preživi do naslednje gradnje slike, nato pa pride ista zahteva z drugega stroja, ki se popravka ne spomni.

Razreševalnik ni iskalna domena

Za razrešitev je treba tudi poskusiti ime. Nekvalificirano ime, kot je fileserver, postane fileserver.corp.example šele, ko je iskalna domena pripeta vmesniku, ki nosi poizvedbo. VPN, ki vsili strežnik DNS brez iskalnega seznama, ustvari zelo določeno delitev: polno kvalificirano ime se razreši in vsako kratko ime ne uspe.

Pred urejanjem profila preizkusite obe obliki, ker obe napaki kažeta v različne smeri. Na gostitelju s systemd-resolved ima povezava tunela svoje strežnike in usmerjevalne domene, zato berite povezavo, ne globalne datoteke.

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

Če je poizvedba pripisana povezavi, ki ne nosi tunela, usmerjevalne domene ni, čeprav je naslov DNS prisoten. To je problem politike v konfiguraciji resolved, ne problem usmerjanja v tunelu.

Vsebniki nosijo svojo kopijo odgovora

Vsebnik, zgrajen iz splošne slike, običajno prinese fiksni resolv.conf. Spremembe razreševalnika na gostitelju ne dosežejo vanj, prav tako ne iskalna domena, zato opravilo build, ki pripne deljeni vir prek tunela, ne uspe, medtem ko isti ukaz zunaj vsebnika deluje. Dajte vsebniku lastne nastavitve DNS in iskanja v datoteki compose ali v argumentih run, ne le v profilu gostitelja.

Preden obtožite sliko, preverite v vsebniku. Dva ukaza znova ustvarita celotno diagnozo v nekaj sekundah, drugi pa dokaže, kateri razreševalnik je dejansko odgovoril.

Šele nato poglejte deljeni vir in filter

Ko se ime razreši, so preostale napake običajne omrežne težave. SMB potrebuje TCP 445 do strežnika, brskanje po seznamu delovne skupine pa je odvisno od imenskih storitev, ki jih tunel verjetno ne posreduje. Preslikajte po imenu gostitelja, namesto da čakate, da se seznam napolni, in pustite odjemalcu, da pove, do katere faze je prišel. Zavrnjena povezava in tihi timeout sta tudi vredna ločevanja, ker prvi običajno pomeni, da je nekaj odgovorilo, drugi pa, da ni nič.

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

Razrešen naslov z zavrnjenim ali poteklim vratom 445 je težava požarnega zidu ali poslušalca na drugi strani. Nerazrešeno ime je težava razreševalnika. In mount, ki se overi, a vrne napake dovoljenj, ni ne eno ne drugo, zato ne odpirajte omrežnega vprašanja znova, ko je seja vzpostavljena.

Držite sklep tako ozek, kot so dokazi. Ko naslov deluje, ime pa ne, tunel opravlja svoje delo, popravek pa spada v vrstni red razreševalnika, iskalno domeno ali lastno konfiguracijo vsebnika.