DNS vo VPN funguje, ale názvy .local stále zlyhávajú: kto ich rieši?

Dva počítače v tej istej VPN, rovnaký názov hostiteľa, a predsa ho rieši len jeden z nich: rozdiel zvyčajne nie je v tuneli, ale v tom, ktorý resolver odpovedal. Na linuxovom desktope môže tento názov prejsť cez prepínač menných služieb, cez stub systemd-resolved alebo cez resolver, ktorý si aplikácia priniesla, a každý z nich uplatňuje svoje vlastné pravidlo na rovnakú príponu. Práve na prípone sa pravidlá rozchádzajú, pretože .local nie je neutrálne označenie. Zistite, ktorou cestou skutočne ide zlyhávajúci program, skôr než zmeníte poradie, v akom sa čokoľvek spúšťa.

Dva resolvery, dve rôzne odpovede

Tradičné hľadanie v glibc prechádza riadok hosts: v nsswitch.conf a pýta sa každého modulu po poradí, kým jeden neodpovie. Klient, ktorý hovorí so systemd-resolved cez stub listener, sa namiesto toho pýta jedného procesu, a ten proces uplatňuje politiku pre každé spojenie plus svoje vlastné špeciálne prípady. Aplikácia, ktorá si prináša vlastný resolver alebo linkuje knižnicu, ktorá to robí, môže obísť oba. Jedno meno hostiteľa tak môže mať na jednom stroji troch vlastníkov a len jeden z nich vie, čo VPN zamýšľala.

Než čokoľvek zmeníte, určite vlastníka, pretože oprava je pre každého z tých troch iná. Prehliadač a nástroj príkazového riadka na tej istej ploche môžu legitímne nesúhlasiť a ten nesúlad je stopa, nie chyba. Ak prehliadač názov rieši a nástroj nie, ladíte cestu resolvera a nie trasu VPN. Potvrďte trasu osobitne, aby sa porucha smerovania nezamenila s poruchou mennej služby. Keď sa oba zhodnú, porucha je nad hostiteľom a konfigurácia resolvera tu nestojí za ďalšiu úpravu.

Ktorý príkaz sa skutočne spýtal vášho resolvera

Dva príkazy iba na čítanie odpovedajú na príbuzné otázky a ich porovnanie lokalizuje problém rýchlejšie ako čítanie konfigurácie. Použite skutočné interné meno a výstup udržte v súkromí, pretože interné záznamy zostávajú interné. Spustite oba v tej istej relácii, v ktorej beží zlyhávajúci program:

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

Prvý sa pýta cez nakonfigurované moduly, čo bežný program zažíva. Druhý sa pýta systemd-resolved priamo a hlási spojenie, protokol a server, ktorý odpovedal. Opýtať sa firemného servera podľa adresy dokazuje len to, že server záznam má, pretože nič nehovorí o tom, či sa ho aplikácia vôbec niekedy opýtala. Prečítajte si spojenie, ktoré nesie VPN, a domény, ktoré deklaruje, a potom tento zoznam porovnajte s príponou v zlyhávajúcom názve.

Prečo .local obchádza vašu unicast zónu

referencia systemd-resolved uvádza, že viacdielne názvy končiace na .local zvyčajne idú na multicast DNS, keď je mDNS zapnuté, namiesto bežného unicast DNS. RFC 6762 vyhradzuje tento menný priestor pre link-local multicast, takže firemná zóna môže mať správny záznam, na ktorý sa pre túto príponu nikdy nepýta. Tunel môže resolver smerovať bezchybne a napriek tomu prehrať preteky. Úspešný ping z cache nič nehovorí o vyhľadaní, ktoré práve prebehlo.

Existuje dokumentovaná výnimka a tá rieši väčšinu týchto prípadov: keď spojenie deklaruje túto príponu ako doménu vyhľadávania alebo doménu smerovania, démon ju udrží na unicast ceste a špeciálny prípad multicastu preskočí. To je politika pre každé spojenie, nie globálna preferencia. Dva počítače s rovnakým serverom VPN sa môžu správať odlišne, keď jeden sieťový profil doménu deklaruje a druhý nie, preto čítajte aktívny profil, a nie ten, o ktorom si pamätáte, že ste ho upravovali.

Úzka výnimka poráža globálne preusporiadanie

Pre existujúcu zónu, ktorú nemôžete premenovať, nechajte vlastníkov resolvera a VPN deklarovať doménu na spojení, ktoré ju nesie. Záznam domény smerovania pre tú jednu príponu plus zamýšľaná adresa servera je malá zmena s pomenovaným vlastníkom a žije so spojením, nie v ručne upravenom súbore.

Prežije aj odpojenie, pretože politika spojenia sa znova uplatní, keď sa spojenie vráti. Úprava zdieľaného nsswitch.conf je lákavá a drahšia alternatíva, pretože mení správanie vyhľadávania pre každé meno na stroji, vrátane miestneho objavovania. Vypnutie multicast démona tiež nie je rovnocenné: odstraňuje miestne správanie bez toho, aby niektorý resolver naučil firemnú zónu. Ak je služba nová a nie zdedená, umiestnite ju pod subdoménu, ktorú kontroluje vaša organizácia, a súťaž úplne preskočte. Zvoľte úzku výnimku, keď je názov pevne daný vo firmware alebo vytlačený na etikete, a novú subdoménu, keď ešte kontrolujete klienta.

Čo po zmene preukázať

Preukážte opravu vlastným vyhľadaním aplikácie, nie nástrojom, ktorý ste nainštalovali na testovanie, a vyčistite každú cache, ktorá by za ňu mohla odpovedať. Potom potvrďte cestu resolvera a spojenie, ktoré odpoveď poskytlo. Nakoniec skontrolujte, či sa miestne objavovanie správa ako pred zmenou, pretože tlačiareň, ktorá prestane prichádzať, je tá časť, ktorú si ľudia všimnú najneskôr. Tieto tri príkazy kontrolujú názov, cestu a identitu TLS v tomto poradí:

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ávna adresa s nesprávnym certifikátom stále zlyhá u striktného klienta, preto skontrolujte názov, ktorý aplikácia očakáva, keď preklad funguje. Potvrďte, že služba prijíma spojenia z adresy VPN, a nie len z kancelárskeho rozsahu. Zapíšte rozsah domény, server a vlastníka do dokumentácie spojenia. Inak sa ďalší človek, ktorý na túto poruchu narazí, chopí tej istej globálnej úpravy, ktorej ste práve unikli.