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

Přidali jste jméno do /etc/hosts, připojili VPN a očekávali, že se záznam objeví všem. To se nestane a překvapení obvykle přichází s druhým příznakem: jméno se přeloží na vašem stroji a u kolegy selže, což vypadá jako rozbitá služba DNS ve VPN, a přitom soubor hosts dělá přesně to, k čemu byl navržen. Soubor hosts je místní konfigurace překladu jmen, nikoli aktualizace zóny, a nic v běžném připojení k VPN jej nenahrává.

Hosts je místní přepis, nikoli aktualizace zóny

Soubor je seznam mapování, která knihovny jmenné služby konzultují před dotazem na server DNS nebo místo něj. Řádek jako 10.40.0.20 build.corp.example mění to, k čemu dospějí aplikace na onom jediném stroji. Nevytváří záznam, necestuje tunelem a server DNS, na který tunel ukazuje, o jeho existenci nemá tušení.

Proto je selhání asymetrické. Váš klient dostane odpověď ze souboru. Jiný klient se zeptá serveru DNS VPN, který nic nevrátí, a aplikace hlásí, že jméno neexistuje. Oba stroje se chovají správně; jen jeden z nich má přepis, který druhý nikdy neviděl.

Dva příkazy, dvě různé komponenty

Nejrychlejší způsob, jak ukončit hádku, je ukázat rozdíl ve dvou příkazech, oba spuštěné na klientovi, který má záznam v hosts:

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

První se ptá vlastní cesty vyhledávání systému, která na typickém systému glibc čte místní soubory před DNS. Druhý posílá dotaz DNS přímo serveru na dané adrese a místní soubory vůbec nekonzultuje. Když první vrátí váš záznam a druhý vrátí NXDOMAIN, dokázali jste, že záznam v DNS neexistuje a že váš stroj odpovídá z místního přepisu.

Pořadí je konfigurovatelné a stojí za to ho ověřit, než o konkrétní distribuci cokoli uzavřete. Podívejte se na řádek hosts: v /etc/nsswitch.conf; hosts: files dns konzultuje soubory jako první. Neopisujte tento příklad do funkční konfigurace jen kvůli změně pořadí, protože skutečné systémy často uvádějí další zdroje a podmíněné položky služeb, které příklad neobsahuje.

systemd-resolved zamlžuje test

Na systému se systemd-resolved obsluhuje místní stub také jména z databáze hosts. Dotaz na 127.0.0.53 proto není nezávislým testem vzdáleného serveru, i když vypadá jako dotaz DNS a chová se jako on. Co resolver zná a na které servery by se ptal, potvrdíte takto:

resolvectl query build.corp.example
resolvectl status

Výstup status uvádí servery DNS pro každé spojení, a tak zjistíte, zda spojení VPN vůbec dostalo resolver. Tato otázka je oddělená od záznamu v hosts a je tou, kterou stojí za to položit, když soukromé jméno selhává všem uživatelům, ne jednomu.

Aplikace mohou přidat další vrstvu. Prohlížeč s vlastním nastavením DNS-over-HTTPS, kontejner s vlastní konfigurací resolveru nebo runtime, který kešuje vyhledávání po celou dobu života procesu, mohou každý odpovídat jinak než systém. Testujte aplikaci, na které vám záleží, místo abyste předpokládali, že jeden příkaz popisuje každý program na stroji.

Co vlastně sdílí jméno přes VPN

Pokud má soukromé jméno fungovat pro všechny, potřebuje vlastníka, na kterého dosáhne resolver každého. Čistá odpověď je publikovat záznam ve spravované zóně a učinit tuto zónu přeložitelnou zamýšlenou cestou DNS přes VPN. Záznam pak má jeden zdroj pravdy, auditní stopu a životní cyklus a nikdo si nemusí pamatovat, který notebook nese místní přepis.

Distribuce souborů hosts je legitimní alternativa a je to správa koncových bodů, nikoli jmenná služba. Pokud ji zvolíte, soubor musí nasadit, verzovat a odstranit to, co spravuje fleet, a v návrhu to tak má být popsáno. „VPN to řeší“ není popis toho procesu.

Dynamická registrace DNS je třetí mechanismus s vlastními oprávněními, ověřováním aktualizací a životností záznamu. Nevyplývá ze záznamu v hosts a nevyplývá ani z pouhého připojení klienta, pokud server i klient nebyli oba nakonfigurováni, aby to dělali. Záznam, který se objeví sám, je signál, že někdo povolil zabezpečené aktualizace a klient, který se sám registruje, a tato konfigurace patří do záznamu návrhu, nikoli do vlákna řešení potíží. Pokud nikdo nedokáže pojmenovat vlastníka tohoto nastavení, považujte automatický záznam za neověřený a držte spravovanou zónu jako zdroj pravdy.

Přeložené jméno není trasa

Překlad jmen a dosažitelnost jsou oddělené a zastaralé místní mapování je klasický způsob, jak je splést. Záznam v hosts, který ukazuje na adresu, jež se přestěhovala, bude vybírat zastaralý hostitel dlouho poté, co bylo DNS opraveno, a příznak vypadá jako selhání směrování u jména, které se přeloží bez problémů.

Když tedy zpráva zní „jméno se přeloží, ale služba je nedostupná“, porovnejte systémové vyhledávání s explicitním dotazem na server DNS VPN a poté zkontrolujte adresu, kterou jste dostali, proti té, kterou služba skutečně používá. Reference systemd-resolved dokumentuje místní zdroje, které konzultuje, a to je mapa, kterou pro toto srovnání potřebujete.

Potom přepis opravte přes jeho vlastníka. Odebrání řádku z vašeho vlastního souboru hosts nic neudělá pro dvanáct notebooků, které stejný řádek dostaly z nasazovacího skriptu, a to je verze tohoto problému, kterou lidé skutečně mají.