A CIFS-csatolásod VPN-en keresztül az nsswitch sorrendje miatt hiúsul meg

A megosztás cím szerint válaszol és név szerint akad el, így a keresés még az SMB indulása előtt meghal. Hasonlítsd össze a getentet a hosttal, majd olvasd el a hosts sort sorrendben.

Az alagút áll. A fájlszerver cím szerint válaszol a pingre. Aztán mount.cifs a gazdagépnévvel ott ül egy ideig, és jelenti, hogy a gazdagép nem érhető el, te pedig elkezdesz újraépíteni egy VPN-profilt, amely soha nem volt a probléma. Linuxon a glibc oldja fel a nevet, mielőtt bármilyen SMB-csomag létezne, és a sorrend abban a feloldóban befejezheti a keresést, mielőtt a DNS-t egyáltalán megkérdeznék. Íme az az útvonal, amelyet járok, a meghiúsult parancstól indulva, nem a kliens felől.

A hibát a megfelelő helyen olvasd

Két eszköz különböző útvonalon jut ugyanahhoz a névhez, és összehasonlításuk egy parancsba kerül. getent a beállított névszolgáltatás-vermen halad végig; host és dig közvetlenül a DNS-t kérdezik, és figyelmen kívül hagyják ezt a vermet. Ha a közvetlen lekérdezés címet ad vissza, és getent semmit, akkor a DNS-kiszolgáló elérhető, és a te feloldókonfigurációd az, amelyik meghiúsul.

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

A harmadik parancs a döntő: kényszeríti a DNS-forrást, és átugorja a verem többi részét. Amikor az működik, a sima getent pedig nem, bebizonyítottad, hogy a sorrend a hibás, nem az alagút és nem a kiszolgáló.

A hosts sor egy korán megálló sorozat

A glibc feloldója olvassa a /etc/nsswitch.conf fájlt, és balról jobbra halad a hosts: bejegyzésen. Sok disztribúció olyan sort szállít, amelyben a multicast-keresés jön először, korai visszatérési művelettel összekapcsolva. A művelet nem díszítés: amikor az mDNS “not found” választ ad, a [NOTFOUND=return] befejezi az egész keresést, így a vállalati nevet soha nem küldi el a VPN által kényszerített feloldónak. Semmi nem naplózza, mert nem küldtek olyan lekérdezést, amelyet a feloldó elutasíthatott volna. Ezért tűnik úgy, hogy a csatolás megakad, majd elérhetetlen gazdagépet jelent.

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

A DNS-t tedd a korai visszatérési művelet elé ahelyett, hogy törölnéd az mDNS-t, és konfigurációkezeléssel változtasd meg. A kézi szerkesztés a következő image-buildig él, aztán ugyanaz a ticket más gépről érkezik, amely nem emlékszik a javításra.

A feloldó nem keresési tartomány

A feloldáshoz az is kell, hogy a nevet kipróbálják. Egy nem minősített név, mint a fileserver, csak akkor lesz fileserver.corp.example, ha a lekérdezést hordozó interfészhez keresési tartomány kapcsolódik. Az a VPN, amely keresési lista nélkül kényszerít DNS-kiszolgálót, nagyon sajátos felosztást hoz létre: a teljesen minősített név feloldódik, és minden rövid név meghiúsul.

A profil szerkesztése előtt teszteld mindkét formát, mert a két hiba különböző irányba mutat. Egy systemd-resolved gazdagépen az alagút linkje saját kiszolgálókkal és útválasztási tartományokkal rendelkezik, ezért a linket olvasd, ne a globális fájlt.

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

Ha a lekérdezés olyan linkhez rendelődik, amely nem hordozza az alagutat, hiányzik az útválasztási tartomány, pedig a DNS-cím jelen van. Ez szabályzatprobléma a resolved konfigurációjában, nem útválasztási probléma az alagútban.

A konténerek a saját másolatukat hordozzák a válaszból

Egy általános image-ből épített konténer általában fix resolv.conf fájlt szállít. A gazdagépen végzett feloldómódosítások nem érnek el hozzá, és a keresési tartomány sem, ezért az alagúton megosztást csatoló build-feladat meghiúsul, miközben ugyanaz a parancs a konténeren kívül működik. Adj a konténernek saját DNS- és keresési beállításokat a compose-fájlban vagy a run argumentumokban, ne csak a gazdagép profiljában.

A konténeren belül ellenőrizd, mielőtt az image-et hibáztatnád. Két parancs másodpercek alatt megismétli az egész diagnózist, a második pedig bebizonyítja, melyik feloldó válaszolt valójában.

Csak ezután nézd meg a megosztást és a szűrőt

Amint a név feloldódik, a fennmaradó hibák közönséges hálózati hibák. Az SMB-nek TCP 445 kell a kiszolgáló felé, a munkacsoport-lista böngészése pedig olyan névszolgáltatásoktól függ, amelyeket az alagút valószínűleg nem továbbít. Gazdagépnév szerint csatolj, ahelyett hogy a lista feltöltésére várnál, és hagyd, hogy a kliens megmondja, melyik szakaszig jutott. Az elutasított kapcsolat és a csendes timeout szétválasztása is megéri, mert az első általában azt jelenti, hogy valami válaszolt, a második pedig azt, hogy semmi.

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

A feloldott cím elutasított vagy lejárt 445-ös porttal tűzfal- vagy listener-probléma a túloldalon. A feloldatlan név a feloldó problémája. Az pedig, hogy a csatolás hitelesít, de jogosultsági hibákat ad vissza, egyik sem, ezért ne nyisd újra a hálózati kérdést, amikor a munkamenet már áll.

Tartsd a következtetést olyan szűken, mint a bizonyítékot. Amikor a cím működik és a név nem, az alagút teszi a dolgát, és a javítás a feloldó sorrendjébe, a keresési tartományba vagy a konténer saját konfigurációjába tartozik.

Kapcsolódó cikkek