DNS přes VPN funguje, ale jména .local stále selhávají: kdo je řeší?

Dva počítače na stejné VPN, stejné jméno hostitele, a přesto je řeší jen jeden z nich: rozdíl obvykle není v tunelu, ale v tom, který resolver odpověděl. Na linuxovém desktopu může toto jméno projít přepínačem jmenných služeb, stubem systemd-resolved nebo resolverem, který si aplikace přinesla, a každý z nich uplatňuje své vlastní pravidlo na stejnou příponu. Právě na příponě se pravidla rozcházejí, protože .local není neutrální označení. Zjistěte, kterou cestou selhávající program skutečně jde, než změníte pořadí, v jakém se co spouští.

Dva resolvery, dvě různé odpovědi

Tradiční hledání v glibc prochází řádek hosts: v nsswitch.conf a ptá se každého modulu po řadě, dokud jeden neodpoví. Klient, který mluví se systemd-resolved přes stub listener, se místo toho ptá jednoho procesu a ten proces uplatňuje politiku pro každé spojení plus své vlastní zvláštní případy. Aplikace, která si nese vlastní resolver nebo linkuje knihovnu, jež to dělá, může obejít oba. Jedno jméno hostitele tak může mít na jednom stroji tři vlastníky a jen jeden z nich ví, co VPN zamýšlela.

Než cokoli změníte, určete vlastníka, protože oprava je pro každého z těch tří jiná. Prohlížeč a nástroj příkazové řádky na stejné ploše mohou legitimně nesouhlasit a ten nesoulad je stopa, ne chyba. Pokud prohlížeč jméno řeší a nástroj ne, ladíte cestu resolveru, ne trasu VPN. Ověřte trasu zvlášť, aby se porucha směrování nepletla s poruchou jmenné služby. Když se oba shodnou, porucha je výše než hostitel a konfigurace resolveru tady nestojí za další úpravu.

Který příkaz se skutečně zeptal vašeho resolveru

Dva příkazy jen pro čtení odpovídají na příbuzné otázky a jejich porovnání lokalizuje problém rychleji než čtení konfigurace. Použijte skutečné interní jméno a výstup udržte v soukromí, protože interní záznamy zůstávají interní. Spusťte oba ve stejné relaci, ve které běží selhávající program:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

První se ptá přes nakonfigurované moduly, což je to, co zažívá typický program. Druhý se ptá systemd-resolved přímo a hlásí spojení, protokol a server, který odpověděl. Dotaz na firemní server podle adresy dokazuje jen to, že server záznam drží, protože nic neříká o tom, zda se ho aplikace vůbec ptala. Přečtěte si spojení, které nese VPN, a domény, které deklaruje, a potom tento seznam porovnejte s příponou v selhávajícím jménu.

Proč .local obchází vaši unicast zónu

reference systemd-resolved uvádí, že vícedílná jména končící na .local obvykle jdou na multicast DNS, když je mDNS zapnuté, místo na běžné unicast DNS. RFC 6762 vyhrazuje tento jmenný prostor pro link-local multicast, takže firemní zóna může mít správný záznam, na který se pro tuto příponu nikdy neptá. Tunel může resolver směrovat bezchybně a přesto prohrát závod. Úspěšný ping z cache nic neříká o vyhledání, které právě proběhlo.

Existuje dokumentovaná výjimka a ta řeší většinu těchto případů: když spojení deklaruje tuto příponu jako vyhledávací doménu nebo směrovací doménu, démon ji udrží na unicast cestě a zvláštní případ multicastu přeskočí. To je politika pro každé spojení, ne globální preference. Dva počítače se stejným serverem VPN se mohou chovat různě, když jeden síťový profil doménu deklaruje a druhý ne, proto čtěte aktivní profil, a ne ten, o kterém si pamatujete, že jste ho upravovali.

Úzká výjimka poráží globální přeskupení

U existující zóny, kterou nemůžete přejmenovat, nechte vlastníky resolveru a VPN deklarovat doménu na spojení, které ji nese. Záznam směrovací domény pro tuto jednu příponu plus zamýšlená adresa serveru je malá změna s pojmenovaným vlastníkem a žije se spojením, ne v ručně upravovaném souboru.

Přežije i odpojení, protože politika spojení se znovu použije, když se spojení vrátí. Úprava sdíleného nsswitch.conf je lákavá a dražší alternativa, protože mění chování vyhledávání pro každé jméno na stroji, včetně místního objevování. Vypnutí multicast démona také není ekvivalentní: odstraní místní chování, aniž by naučilo kterýkoli resolver firemní zónu. Pokud je služba nová, a ne zděděná, umístěte ji pod subdoménu, kterou vaše organizace ovládá, a soutěži se úplně vyhněte. Zvolte úzkou výjimku, když je jméno pevně dáno firmwarem nebo vytištěno na štítku, a zvolte novou subdoménu, když klienta ještě ovládáte.

Co po změně prokázat

Prokažte opravu vlastním vyhledáním aplikace, ne nástrojem, který jste nainstalovali na testování, a vyčistěte každou cache, která by za ni mohla odpovědět. Potom potvrďte cestu resolveru a spojení, které odpověď poskytlo. Nakonec zkontrolujte, že místní objevování se chová jako před změnou, protože tiskárna, která přestane přicházet, je ta část, které si lidé všimnou nejpozději. Tyto tři příkazy kontrolují jméno, cestu a identitu TLS v tomto pořadí:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Správná adresa se špatným certifikátem stále selže u striktního klienta, proto zkontrolujte jméno, které aplikace očekává, jakmile překlad funguje. Potvrďte, že služba přijímá spojení z adresy VPN, a ne jen z kancelářského rozsahu. Zapište rozsah domény, server a vlastníka do dokumentace spojení. Jinak se příští člověk, který na tuto poruchu narazí, chopí stejné globální úpravy, které jste právě unikli.