Pripojenie CIFS cez VPN zlyháva kvôli poradiu v nsswitch

Tunel je hore. Súborový server odpovedá na ping podľa adresy. Potom mount.cifs s názvom hostiteľa chvíľu stojí a ohlási, že hostiteľ je nedostupný, a vy začnete prestavovať profil VPN, ktorý nikdy nebol problém. V Linuxe meno rozlišuje glibc skôr, než existuje akýkoľvek SMB paket, a poradie v tom resolveri môže vyhľadávanie ukončiť skôr, než sa DNS vôbec opýta. Tu je postup, ktorý robím, začínajúc príkazom, ktorý zlyhal, nie klientom.

Čítajte zlyhanie na správnom mieste

Dva nástroje idú k tomu istému menu rôznymi cestami a ich porovnanie stojí jeden príkaz. getent prechádza nakonfigurovaným zásobníkom menných služieb; host a dig sa pýtajú DNS priamo a ten zásobník ignorujú. Ak priamy dotaz vráti adresu a getent nevráti nič, DNS server je dostupný a zlyháva vaša konfigurácia resolvera.

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

Tretí príkaz je rozhodujúci: vynúti zdroj DNS a zvyšok zásobníka preskočí. Keď funguje a obyčajný getent nie, dokázali ste, že vinné je poradie, nie tunel a nie server.

Riadok hosts je postupnosť, ktorá sa zastaví skoro

Resolver glibc číta /etc/nsswitch.conf a prechádza záznam hosts: zľava doprava. Mnohé distribúcie dodávajú riadok, kde multicastové vyhľadávanie ide prvé a má pri sebe akciu skorého návratu. Tá akcia nie je ozdoba: keď mDNS odpovie “not found”, [NOTFOUND=return] ukončí celé vyhľadávanie, takže podnikové meno sa k resolveru, ktorý VPN pretlačila, nikdy neodošle. Nič to nezaloguje, pretože nebol odoslaný žiadny dotaz, ktorý by resolver mohol odmietnuť. Preto sa pripojenie zdá visieť a potom ohlási nedostupného hostiteľa.

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

Posuňte DNS pred akciu skorého návratu namiesto mazania mDNS a meňte to cez správu konfigurácie. Ručná úprava prežije do ďalšieho buildu image a potom príde ten istý tiket z iného stroja, ktorý o oprave nevie.

Resolver nie je vyhľadávacia doména

Na rozlíšenie je tiež potrebné, aby sa meno vyskúšalo. Nekvalifikované meno ako fileserver sa stane fileserver.corp.example len vtedy, keď je k rozhraniu nesúcemu dotaz pripojená vyhľadávacia doména. VPN, ktorá pretlačí DNS server bez zoznamu vyhľadávania, vytvorí veľmi konkrétne rozdelenie: plne kvalifikované meno sa preloží a každé krátke meno zlyhá.

Pred úpravou profilu otestujte obe podoby, pretože obe zlyhania ukazujú inam. Na hostiteľovi so systemd-resolved má odkaz tunela vlastné servery a smerovacie domény, takže čítajte odkaz, nie globálny súbor.

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

Ak sa dotaz priradí odkazu, ktorý tunel nenesie, smerovacia doména chýba, aj keď je adresa DNS prítomná. To je problém politiky v konfigurácii resolved, nie problém smerovania v tuneli.

Kontajnery nesú vlastnú kópiu odpovede

Kontajner postavený zo všeobecného image zvyčajne dodáva pevný resolv.conf. Zmeny resolvera na hostiteľovi sa k nemu nedostanú, rovnako ako vyhľadávacia doména, takže build úloha, ktorá pripája zdieľaný priečinok cez tunel, zlyhá, zatiaľ čo ten istý príkaz mimo kontajnera funguje. Dajte kontajneru vlastné nastavenia DNS a vyhľadávania v compose súbore alebo v argumentoch spustenia, nie len v profile hostiteľa.

Pred obvinením image skontrolujte vnútro kontajnera. Dva príkazy zopakujú celú diagnostiku za pár sekúnd a druhý dokáže, ktorý resolver skutočne odpovedal.

Až potom sa pozrite na zdieľaný priečinok a filter

Keď sa meno preloží, zostávajúce zlyhania sú bežné sieťové. SMB potrebuje TCP 445 k serveru a prechádzanie zoznamu pracovnej skupiny závisí od menných služieb, ktoré tunel pravdepodobne nepreposiela. Mapujte podľa názvu hostiteľa namiesto čakania, kým sa zoznam naplní, a nechajte klienta povedať, do ktorej fázy sa dostal. Odmietnuté spojenie a tichý timeout je tiež dobré oddeliť, pretože prvý zvyčajne znamená, že niečo odpovedalo, a druhý, že neodpovedalo 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

Preložená adresa s odmietnutým alebo vypršaným portom 445 je problém firewallu alebo listenera na druhej strane. Nepreložené meno je problém resolvera. A pripojenie, ktoré sa autentizuje, ale vracia chyby oprávnení, nie je ani jedno, takže znovu neotvárajte sieťovú otázku, keď je relácia nadviazaná.

Držte záver tak úzky, ako sú dôkazy. Keď adresa funguje a meno nie, tunel robí svoju prácu a oprava patrí do poradia resolvera, vyhľadávacej domény alebo vlastnej konfigurácie kontajnera.