Montimi CIFS juaj dështon përmes VPN për shkak të rendit në nsswitch

Tuneli është lart. Serveri i skedarëve përgjigjet ndaj ping me adresë. Pastaj mount.cifs me emrin e hostit qëndron aty për një kohë dhe raporton se hosti është i paarritshëm, dhe ju filloni të rindërtoni një profil VPN që nuk ishte kurrë problemi. Në Linux emri zgjidhet nga glibc para se të ekzistojë ndonjë paketë SMB, dhe rendi në atë zgjidhës mund ta përfundojë kërkimin para se DNS të pyetet fare. Kjo është rruga që ndjek, duke filluar nga komanda që dështoi dhe jo nga klienti.

Lexojeni dështimin në vendin e duhur

Dy mjete ndjekin rrugë të ndryshme drejt të njëjtit emër, dhe krahasimi i tyre kushton një komandë. getent kalon nëpër stivën e konfiguruar të shërbimeve të emrave; host dhe dig pyesin DNS drejtpërdrejt dhe e injorojnë atë stivë. Nëse pyetja e drejtpërdrejtë kthen një adresë dhe getent nuk kthen asgjë, serveri DNS është i arritshëm dhe konfigurimi juaj i zgjidhësit është ai që dështon.

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

Komanda e tretë është vendimtarja: detyron burimin DNS dhe kalon pjesën tjetër të stivës. Kur ajo punon dhe getent i thjeshtë nuk punon, ju keni vërtetuar se faji është te rendi, jo te tuneli dhe jo te serveri.

Rreshti hosts është një sekuencë që ndalon herët

Zgjidhësi glibc lexon /etc/nsswitch.conf dhe kalon zërin hosts: nga e majta në të djathtë. Shumë shpërndarje sjellin një rresht ku kërkimi multicast vjen i pari me një veprim kthimi të hershëm të bashkangjitur. Veprimi nuk është zbukurim: kur mDNS përgjigjet “not found”, [NOTFOUND=return] e përfundon të gjithë kërkimin, kështu që emri i korporatës nuk dërgohet kurrë te zgjidhësi që VPN imponoi. Asgjë nuk e regjistron, sepse nuk u dërgua asnjë pyetje që zgjidhësi mund ta refuzonte. Kjo është arsyeja pse montimi duket se varet dhe pastaj raporton një host të paarritshëm.

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

Zhvendoseni DNS para veprimit të kthimit të hershëm në vend që të fshini mDNS, dhe ndryshojeni atë përmes menaxhimit të konfigurimit. Një redaktim me dorë mbijeton deri në ndërtimin e ardhshëm të imazhit, dhe pastaj i njëjti tiket vjen nga një makinë tjetër që nuk e mban mend rregullimin.

Një zgjidhës nuk është një domen kërkimi

Zgjidhja kërkon gjithashtu që emri të provohet. Një emër i pakualifikuar si fileserver bëhet fileserver.corp.example vetëm kur një domen kërkimi është bashkangjitur ndërfaqes që mban pyetjen. Një VPN që imponon një server DNS pa listë kërkimi prodhon një ndarje shumë specifike: emri plotësisht i kualifikuar zgjidhet dhe çdo emër i shkurtër dështon.

Testoni të dyja format para se të redaktoni profilin, sepse dy dështimet tregojnë drejtime të ndryshme. Në një host systemd-resolved lidhja e tunelit ka serverat dhe domenet e rrugëtimit të vetë, kështu që lexoni lidhjen dhe jo skedarin global.

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

Nëse pyetja i atribuohet një lidhjeje që nuk e mban tunelin, domeni i rrugëtimit mungon edhe pse adresa DNS është e pranishme. Ky është një problem politike në konfigurimin resolved, jo një problem rrugëtimi në tunel.

Kontejnerët mbajnë kopjen e tyre të përgjigjes

Një kontejner i ndërtuar nga një imazh i përgjithshëm zakonisht sjell një resolv.conf fiks. Ndryshimet e zgjidhësit të bëra në host nuk arrijnë në të, dhe as domeni i kërkimit, kështu që një punë build që monton një ndarje përmes tunelit dështon, ndërsa e njëjta komandë punon jashtë kontejnerit. Jepini kontejnerit cilësimet e veta DNS dhe të kërkimit në skedarin compose ose në argumentet run, jo vetëm në profilin e hostit.

Kontrolloni brenda kontejnerit para se të fajësoni imazhin. Dy komanda e riprodhojnë të gjithë diagnozën në pak sekonda, dhe e dyta vërteton cili zgjidhës përgjigjet në të vërtetë.

Vetëm atëherë shikoni ndarjen dhe filtrin

Pasi emri të zgjidhet, dështimet e mbetura janë probleme të zakonshme rrjeti. SMB kërkon TCP 445 drejt serverit, dhe shfletimi i një liste të grupit të punës varet nga shërbime emrash që tuneli ndoshta nuk i përcjell. Hartoni sipas emrit të hostit në vend që të prisni që një listë të mbushet, dhe lëreni klientin t'ju thotë në cilën fazë mbërriti. Një lidhje e refuzuar dhe një timeout i heshtur gjithashtu meritojnë të ndahen, sepse i pari zakonisht do të thotë se diçka u përgjigj dhe i dyti se asgjë nuk u përgjigj.

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

Një adresë e zgjidhur me portin 445 të refuzuar ose të skaduar është një problem firewalls ose dëgjuesi në anën tjetër. Një emër i pazgjidhur është problemi i zgjidhësit. Dhe një montim që autentikohet por kthen gabime lejeje nuk është as njëra as tjetra, prandaj mos e rihapni pyetjen e rrjetit pasi sesioni është vendosur.

Mbani përfundimin aq të ngushtë sa provat. Kur adresa punon dhe emri jo, tuneli po bën punën e vet, dhe rregullimi i përket rendit të zgjidhësit, domenit të kërkimit ose konfigurimit të vetë kontejnerit.