Proč resolv.conf zobrazuje DNS vaší VPN, ale dotazy ho ignorují

V protokolech nic nevypadá špatně: rozhraní je aktivní, resolver hlásí DNS server VPN a soubor na disku ho uvádí. Přesto se interní název hostitele stále překládá přes místní router. Tato tři tvrzení si neodporují, protože soubor, stav jednotlivého spojení a cesta dotazu jsou různé objekty, které náhodou sdílejí jméno. Následuje cesta, kterou dotaz skutečně prochází na hostiteli se systemd-resolved.

Tři objekty zvané resolv.conf

Na hostiteli s resolved je /etc/resolv.conf obvykle symbolický odkaz na /run/systemd/resolve/stub-resolv.conf. Tento cíl obsahuje adresu místního stub posluchače, 127.0.0.53, a také vyhledávací domény, které resolved vypočetl. Je to pohled na stav, ne stav sám.

Stav žije v konfiguraci resolved pro jednotlivá spojení, a proto se resolvectl status může rozcházet se souborem a přesto mít pravdu. Spojení nese vlastní servery a vlastní směrovací domény a stub tyto údaje konzultuje, když dorazí dotaz. Manuál systemd-resolved popisuje generované soubory a model jednotlivých spojení; rozdělení na pohled a stav je část, kterou stojí za to si zapamatovat. Úprava cíle symbolického odkazu mění to, co čtou tradiční klienti, ne to, co resolver ví.

Třetí objekt, /run/systemd/resolve/resolv.conf, zplošťuje každé spojení do jednoho seznamu serverů. Program nasměrovaný na tento soubor posílá dotazy přímo na uvedené servery a obchází stub, takže se na něj už politika jednotlivých spojení nevztahuje. Dva programy na stejném stroji proto mohou na stejné jméno odpovědět různě a ani jeden není rozbitý.

Sledujte jeden dotaz přes NSS

glibc čte /etc/nsswitch.conf, aby rozhodl, kdo na jméno odpoví. Řádek hosts obsahující resolve směruje otázku na nss-resolve, který se ptá resolved přes D-Bus a dostane odpověď pro dané spojení. Řádek jen s files dns posílá dotaz na adresu, kterou drží /etc/resolv.conf.

Tento jediný řádek vysvětluje většinu neshod mezi prohlížečem a dig. dig čte resolv.conf přímo a NSS se nikdy nedotkne, takže testuje stub nebo nadřazený server, ne cestu, kterou aplikace používá. getent hosts internal.example prochází přes NSS a srovnání jeho odpovědi s odpovědí dig je první užitečné měření.

Aplikace, které si nesou vlastní resolver nebo mluví DNS přes HTTPS s pevným koncovým bodem, obcházejí obě cesty. Nic v resolv.conf ani ve stavu resolved je neomezuje.

Zkontrolujte, kdo soubor vlastní a kam ukazuje

Přečtěte řetězec odkazů, než cokoli změníte, protože vlastnictví rozhoduje, který soubor je směrodatný. Každý příkaz níže pouze čte stav.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

První řádek vypíše odkaz i jeho cíl společně a obyčejný soubor vlastněný skriptem VPN znamená, že resolver tento zápis nikdy nepovažuje za vstup. Výstup stavu uvádí servery jednotlivých spojení a směrovací domény, které rozhodují, kam každý dotaz jde. Řádek nsswitch říká, zda se stub vůbec konzultuje, takže adresa stub v souboru bez resolve znamená, že dotazy dorazí k místnímu posluchači, zatímco rozdělení nikdo neřídí. I poslední výpis je důležitý, protože hostitel bez stub-resolv.conf neprovozuje zde popsané uspořádání.

Pokud řetězec končí souborem, který spravuje jiný balíček, jsou klient VPN a tento balíček dva vlastníci, které je třeba sladit. Nahrazení odkazu zahodí práci jednoho vlastníka a práci druhého ponechá na místě.

Oprava u vlastníka odkazu

Připojení VPN by mělo registrovat své servery a domény na vlastním spojení a při odpojení je zase stáhnout. Integrace resolved v NetworkManageru i vlastní pomocník klienta fungují právě tak; skript, který jen přepisuje resolv.conf, ne.

Na spojení, které už existuje, ukazuje mechanismus běhové nastavení. resolvectl dns tun0 10.40.0.53 připojí server a resolvectl domain tun0 '~corp.example' připojí směrovací doménu. Vlnovka je nosný znak: omezuje dotazy pro tuto příponu na toto spojení a zbytek nechává být, zatímco stejná hodnota bez ní se stane vyhledávací doménou a rozdělení se vypaří. Tyto adresy jsou laboratorní příklady, ne trvalá konfigurace. Potvrďte pomocí resolvectl query host.corp.example a přečtěte, které spojení odpovědělo.

Registrovaný server stále potřebuje trasu. Když dotaz dorazí na správné spojení a vyprší časový limit, závada je v dosažitelnosti tunelem, ne ve vlastnictví resolveru.

Jak vypadá funkční stav

Zdravý výsledek je konzistentní ve všech třech pohledech: servery jednotlivých spojení odpovídají tomu, co VPN přidělila, směrovací domény pokrývají jen interní přípony a aplikace, na které záleží, přeloží interní jméno, zatímco veřejné jméno stále sleduje místní cestu. Jeden úspěšný dotaz dokazuje méně než tato shoda.

Potom se odpojte a oba dotazy zopakujte. Klient, který po ukončení ponechá své domény registrované, vytvoří stroj, kterému interní překlady selžou až za hodiny, bez otevřeného tunelu a bez zjevné příčiny.