Jūsų CIFS prijungimas per VPN žlunga dėl tvarkos nsswitch faile

Tunelis veikia. Failų serveris atsako į ping pagal adresą. Tada mount.cifs su hosto vardu kurį laiką stovi ir praneša, kad hostas nepasiekiamas, o jūs pradedate per naują kurti VPN profilį, kuris niekada nebuvo problema. Linux aplinkoje vardą išsprendžia glibc dar prieš atsirandant bet kokiam SMB paketui, o tvarka tame resolveryje gali užbaigti paiešką dar nepaklausus DNS. Štai kelias, kuriuo einu, pradedant nuo nepavykusios komandos, o ne nuo kliento.

Skaitykite klaidą tinkamoje vietoje

Du įrankiai eina skirtingais keliais iki to paties vardo, o jų palyginimas kainuoja vieną komandą. getent eina per sukonfigūruotą vardų tarnybų steką; host ir dig klausia DNS tiesiogiai ir tos stekos nepaiso. Jei tiesioginė užklausa grąžina adresą, o getent negrąžina nieko, DNS serveris pasiekiamas, o nepavyksta jūsų resolverio konfigūracija.

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

Trečioji komanda yra sprendėja: ji priverčia DNS šaltinį ir praleidžia likusią steką. Kai ji veikia, o paprastas getent ne, jūs įrodėte, kad kaltė yra tvarkoje, o ne tunelyje ir ne serveryje.

hosts eilutė yra seka, kuri sustoja anksti

glibc resolveris skaito /etc/nsswitch.conf ir eina per hosts: įrašą iš kairės į dešinę. Daugelis distribucijų pateikia eilutę, kurioje multicast paieška eina pirma su prikabintu ankstyvo grįžimo veiksmu. Tas veiksmas nėra puošmena: kai mDNS atsako “not found”, [NOTFOUND=return] baigia visą paiešką, todėl įmonės vardas niekada nesiunčiamas resolveriui, kurį primetė VPN. Niekas to neįrašo į žurnalą, nes nebuvo išsiųsta jokia užklausa, kurią resolveris galėtų atmesti. Štai kodėl prijungimas atrodo užstrigęs, o paskui praneša nepasiekiamą hostą.

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

Perkelkite DNS prieš ankstyvo grįžimo veiksmą, o ne ištrinkite mDNS, ir keiskite tai per konfigūracijos valdymą. Rankinis pataisymas išlieka iki kito image kūrimo, o tada tas pats bilietas atkeliauja iš kitos mašinos, kuri pataisymo neprisimena.

Resolveris nėra paieškos domenas

Sprendimui taip pat reikia, kad vardas būtų išbandytas. Nekvalifikuotas vardas kaip fileserver tampa fileserver.corp.example tik tada, kai prie sąsajos, kuri neša užklausą, prikabintas paieškos domenas. VPN, kuris primeta DNS serverį be paieškos sąrašo, sukuria labai konkrečią skirtybę: pilnai kvalifikuotas vardas išsprendžiamas, o kiekvienas trumpas vardas nepavyksta.

Prieš redaguodami profilį išbandykite abi formas, nes abi klaidos rodo skirtingomis kryptimis. systemd-resolved hoste tunelio saitą turi savo serverius ir maršrutizavimo domenus, todėl skaitykite saitą, o ne globalų failą.

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

Jei užklausa priskiriama saitui, kuris neneša tunelio, maršrutizavimo domeno trūksta, nors DNS adresas yra. Tai politikos problema resolved konfigūracijoje, o ne maršrutizavimo problema tunelyje.

Konteineriai nešasi savo atsakymo kopiją

Konteineris, pastatytas iš bendro image, paprastai pateikia fiksuotą resolv.conf. Resolverio pakeitimai hoste jo nepasiekia, kaip ir paieškos domenas, todėl build užduotis, kuri prijungia bendrinamą išteklių per tunelį, nepavyksta, o ta pati komanda už konteinerio ribų veikia. Duokite konteineriui savo DNS ir paieškos nustatymus compose faile arba run argumentuose, o ne tik hosto profilyje.

Patikrinkite konteinerio viduje, prieš kaltindami image. Dvi komandos atkuria visą diagnostiką per kelias sekundes, o antroji įrodo, kuris resolveris iš tikrųjų atsakė.

Tik tada žiūrėkite į bendrinamą išteklių ir filtrą

Kai vardas išsprendžiamas, likę nepavykimai yra įprastos tinklo problemos. SMB reikia TCP 445 iki serverio, o darbo grupės sąrašo naršymas priklauso nuo vardų tarnybų, kurių tunelis greičiausiai neperduoda. Susiekite pagal hosto vardą, o ne laukite, kol sąrašas prisipildys, ir leiskite klientui pasakyti, kurią stadiją jis pasiekė. Atmestas ryšys ir tylus timeout irgi verti atskyrimo, nes pirmasis paprastai reiškia, kad kažkas atsakė, o antrasis – kad niekas neatsakė.

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

Išspręstas adresas su atmestu arba pasibaigusiu 445 prievadu yra ugniasienės arba listenerio problema kitoje pusėje. Neišspręstas vardas yra resolverio problema. O prijungimas, kuris autentifikuojasi, bet grąžina teisių klaidas, nėra nei viena, nei kita, todėl neatverkite tinklo klausimo iš naujo, kai sesija jau nustatyta.

Laikykite išvadą tokią siaurą, kaip įrodymai. Kai adresas veikia, o vardas ne, tunelis daro savo darbą, o pataisymas priklauso resolverio tvarkai, paieškos domenui arba paties konteinerio konfigūracijai.