Připojení CIFS přes VPN selhává kvůli pořadí v nsswitch

Sdílená složka odpovídá na adresu a na jméno visí, takže vyhledávání umře dřív, než SMB začne. Porovnejte getent s host a pak čtěte řádek hosts popořadě.

Tunel je nahoru. Souborový server odpovídá na ping podle adresy. Pak mount.cifs s názvem hostitele chvíli stojí a ohlásí, že hostitel je nedostupný, a vy začnete přestavovat profil VPN, který nikdy nebyl problém. V Linuxu jméno rozlišuje glibc dřív, než existuje jakýkoli SMB paket, a pořadí v tom resolveru může vyhledávání ukončit dřív, než se DNS vůbec zeptá. Tady je postup, který dělám, počínaje příkazem, který selhal, ne klientem.

Čtěte selhání na správném místě

Dva nástroje jdou k témuž jménu různými cestami a jejich porovnání stojí jeden příkaz. getent prochází nakonfigurovaný zásobník jmenných služeb; host a dig se ptají DNS přímo a ten zásobník ignorují. Pokud přímý dotaz vrátí adresu a getent nevrátí nic, DNS server je dostupný a selhává vaše konfigurace resolveru.

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

Třetí příkaz je rozhodující: vynutí zdroj DNS a zbytek zásobníku přeskočí. Když funguje a prostý getent ne, dokázali jste, že vinna je pořadí, ne tunel a ne server.

Řádek hosts je posloupnost, která se zastaví brzy

Resolver glibc čte /etc/nsswitch.conf a prochází záznam hosts: zleva doprava. Mnoho distribucí dodává řádek, kde multicastové vyhledávání jde první a má u sebe akci raného návratu. Ta akce není ozdoba: když mDNS odpoví “not found”, [NOTFOUND=return] ukončí celé vyhledávání, takže podnikové jméno se k resolveru, který VPN protlačila, nikdy nepošle. Nic to nezaloguje, protože žádný dotaz nebyl odeslán, aby ho resolver mohl odmítnout. Proto se připojení zdá viset a pak ohlásí nedostupného hostitele.

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 před akci raného návratu, místo abyste mDNS mazali, a měňte to přes správu konfigurace. Ruční úprava přežije do dalšího buildu image a pak přijde stejný tiket z jiného stroje, který o opravě neví.

Resolver není vyhledávací doména

K rozlišení je také potřeba, aby se jméno zkusilo. Nekvalifikované jméno jako fileserver se stane fileserver.corp.example jen tehdy, když je k rozhraní nesoucímu dotaz připojena vyhledávací doména. VPN, která protlačí DNS server bez seznamu hledání, vytvoří velmi konkrétní rozdělení: plně kvalifikované jméno se přeloží a každé krátké jméno selže.

Před úpravou profilu otestujte obě podoby, protože obě selhání ukazují jinam. Na hostiteli se systemd-resolved má odkaz tunelu vlastní servery a směrovací domény, takže čtěte odkaz, ne globální soubor.

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

Pokud se dotaz přiřadí odkazu, který tunel nenese, směrovací doména chybí, i když je adresa DNS přítomná. To je problém politiky v konfiguraci resolved, ne problém směrování v tunelu.

Kontejnery nesou vlastní kopii odpovědi

Kontejner postavený z obecného image obvykle dodává pevný resolv.conf. Změny resolveru na hostiteli se k němu nedostanou, stejně jako vyhledávací doména, takže build úloha, která připojuje sdílenou složku přes tunel, selže, zatímco stejný příkaz mimo kontejner funguje. Dejte kontejneru vlastní nastavení DNS a hledání v compose souboru nebo v argumentech spuštění, ne jen v profilu hostitele.

Než obviníte image, zkontrolujte to uvnitř kontejneru. Dva příkazy zopakují celou diagnostiku za pár sekund a druhý dokáže, který resolver skutečně odpověděl.

Teprve pak se podívejte na sdílenou složku a filtr

Když se jméno přeloží, zbývající selhání jsou běžná síťová. SMB potřebuje TCP 445 k serveru a procházení seznamu pracovní skupiny závisí na jmenných službách, které tunel pravděpodobně nepředává. Mapujte podle názvu hostitele místo čekání, až se seznam naplní, a nechte klienta říct, do které fáze se dostal. Odmítnuté spojení a tichý timeout je také dobré oddělit, protože první obvykle znamená, že něco odpovědělo, a druhý, že neodpovědělo nic.

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

Přeložená adresa s odmítnutým nebo vypršelým portem 445 je problém firewallu nebo listeneru na druhé straně. Nepřeložené jméno je problém resolveru. A připojení, které se autentizuje, ale vrací chyby oprávnění, není ani jedno, takže znovu neotvírejte síťovou otázku, když je relace navázaná.

Držte závěr tak úzký, jako jsou důkazy. Když adresa funguje a jméno ne, tunel dělá svou práci a oprava patří do pořadí resolveru, vyhledávací domény nebo vlastní konfigurace kontejneru.

Související články