Prečo váš záznam v /etc/hosts nedorazí do DNS VPN

Pridali ste meno do /etc/hosts, pripojili sa k VPN a očakávali, že záznam sa objaví všetkým. Nestane sa to a prekvapenie zvyčajne prichádza s druhým príznakom: meno sa preloží na vašom stroji a zlyhá u kolegu, čo vyzerá ako pokazená služba DNS vo VPN, a pritom súbor hosts robí presne to, na čo bol navrhnutý. Súbor hosts je miestna konfigurácia prekladu mien, nie aktualizácia zóny, a nič v bežnom pripojení k VPN ho nenahráva.

Hosts je miestny prepis, nie aktualizácia zóny

Súbor je zoznam mapovaní, ktoré knižnice mennej služby konzultujú pred dopytom na server DNS alebo namiesto neho. Riadok ako 10.40.0.20 build.corp.example mení to, k čomu dospejú aplikácie na onom jedinom stroji. Nevytvára záznam, necestuje tunelom a server DNS, na ktorý tunel ukazuje, o jeho existencii netuší.

Preto je zlyhanie asymetrické. Váš klient dostane odpoveď zo súboru. Iný klient sa opýta servera DNS VPN, ktorý nič nevráti, a aplikácia hlási, že meno neexistuje. Oba stroje sa správajú správne; len jeden z nich má prepis, ktorý druhý nikdy nevidel.

Dva príkazy, dve rôzne komponenty

Najrýchlejší spôsob, ako ukončiť hádku, je ukázať rozdiel v dvoch príkazoch, oba spustené na klientovi, ktorý má záznam v hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Prvý sa pýta vlastnej cesty vyhľadávania systému, ktorá na typickom systéme glibc číta miestne súbory pred DNS. Druhý posiela dopyt DNS priamo serveru na danej adrese a miestne súbory vôbec nekonzultuje. Keď prvý vráti váš záznam a druhý vráti NXDOMAIN, dokázali ste, že záznam v DNS neexistuje a že váš stroj odpovedá z miestneho prepisu.

Poradie je konfigurovateľné a stojí za to ho overiť, než o konkrétnej distribúcii čokoľvek uzavriete. Pozrite sa na riadok hosts: v /etc/nsswitch.conf; hosts: files dns konzultuje súbory ako prvý. Neopisujte tento príklad do funkčnej konfigurácie len kvôli zmene poradia, pretože skutočné systémy často uvádzajú ďalšie zdroje a podmienené položky služieb, ktoré príklad neobsahuje.

systemd-resolved zamlžuje test

Na systéme so systemd-resolved obsluhuje miestny stub aj mená z databázy hosts. Dopyt na 127.0.0.53 preto nie je nezávislým testom vzdialeného servera, aj keď vyzerá ako dopyt DNS a správa sa ako on. Čo resolver pozná a na ktoré servery by sa pýtal, potvrdíte takto:

resolvectl query build.corp.example
resolvectl status

Výstup status uvádza servery DNS pre každé spojenie, a tak zistíte, či spojenie VPN vôbec dostalo resolver. Táto otázka je oddelená od záznamu v hosts a je tou, ktorú stojí za to položiť, keď súkromné meno zlyháva všetkým používateľom, nie jednému.

Aplikácie môžu pridať ďalšiu vrstvu. Prehliadač s vlastným nastavením DNS-over-HTTPS, kontajner s vlastnou konfiguráciou resolvera alebo runtime, ktorý kešuje vyhľadávania po celý čas života procesu, môžu každý odpovedať inak než systém. Testujte aplikáciu, na ktorej vám záleží, namiesto predpokladu, že jeden príkaz opisuje každý program na stroji.

Čo vlastne zdieľa meno cez VPN

Ak má súkromné meno fungovať pre všetkých, potrebuje vlastníka, na ktorého dosiahne resolver každého. Čistá odpoveď je publikovať záznam v spravovanej zóne a urobiť túto zónu preložiteľnou zamýšľanou cestou DNS cez VPN. Záznam potom má jeden zdroj pravdy, auditnú stopu a životný cyklus a nikto si nemusí pamätať, ktorý notebook nesie miestny prepis.

Distribúcia súborov hosts je legitímna alternatíva a je to správa koncových bodov, nie menná služba. Ak ju zvolíte, súbor musí nasadiť, verzovať a odstrániť to, čo spravuje flotilu, a v návrhu to tak má byť opísané. „VPN to rieši“ nie je opis toho procesu.

Dynamická registrácia DNS je tretí mechanizmus s vlastnými oprávneniami, overovaním aktualizácií a životnosťou záznamu. Nevyplýva zo záznamu v hosts a nevyplýva ani z obyčajného pripojenia klienta, pokiaľ server aj klient neboli obaja nakonfigurovaní, aby to robili. Záznam, ktorý sa objaví sám, je signál, že niekto povolil zabezpečené aktualizácie a klient, ktorý sa sám registruje, a táto konfigurácia patrí do záznamu návrhu, nie do vlákna riešenia problémov. Ak nikto nedokáže pomenovať vlastníka tohto nastavenia, považujte automatický záznam za neoverený a držte spravovanú zónu ako zdroj pravdy.

Preložené meno nie je trasa

Preklad mien a dosiahnuteľnosť sú oddelené a zastarané miestne mapovanie je klasický spôsob, ako ich pomýliť. Záznam v hosts, ktorý ukazuje na adresu, ktorá sa presťahovala, bude vyberať zastaraného hostiteľa dlho po tom, čo bolo DNS opravené, a príznak vyzerá ako zlyhanie smerovania pri mene, ktoré sa dobre preloží.

Keď teda správa znie „meno sa preloží, ale služba je nedostupná“, porovnajte systémové vyhľadávanie s explicitným dopytom na server DNS VPN a potom skontrolujte adresu, ktorú ste dostali, proti tej, ktorú služba skutočne používa. Referencia systemd-resolved dokumentuje miestne zdroje, ktoré konzultuje, a to je mapa, ktorú pre toto porovnanie potrebujete.

Potom prepis opravte cez jeho vlastníka. Odstránenie riadku z vášho vlastného súboru hosts nič neurobí pre dvanásť notebookov, ktoré ten istý riadok dostali z nasadzovacieho skriptu, a to je verzia tohto problému, ktorú ľudia skutočne majú.