OpenVPN poslal DNS server, ale Linux jej ignoruje

Odeslaný DNS server je v logu, tunel je nahoře a interní jména stále selhávají. Na samotném odeslání nic rozbité není; nastavení dorazilo a tam se zastavilo. Odeslaná volba DNS je zpráva klientovi, nikoli pokyn resolveru operačního systému, a právě předání mezi nimi je místem, kde většina těchto případů končí. Pět kontrol v pořadí najde předání, které se neuskutečnilo.

Kontrola první: jak se připojení spouští

Vlastník připojení určuje, kdo může použít nastavení resolveru. Přímý příkaz openvpn z shellu nevlastní nic kromě svého procesu, zatímco jednotka systemd, NetworkManager nebo klientský program výrobce má každý svůj způsob publikování DNS. Než některý z nich předpokládáte, přečtěte si seznam procesů a název jednotky.

Proces z příkazové řádky není automaticky připojením NetworkManageru a připojení NetworkManageru není automaticky tím, co napsalo resolv.conf. Tyto dva předpoklady vysvětlují většinu promarněných hodin při tomto vyšetřování. Zeptejte se, která komponenta by publikovala DNS pro rozhraní, které skutečně vidíte.

Než budete pokračovat, zapište si vlastníka. Každá další kontrola na něm závisí.

Kontrola druhá: co propojení resolveru skutečně obsahuje

Na hostiteli se systemd-resolved vypisuje resolvectl status každé propojení s jeho servery DNS a doménami. Najděte propojení tunelu a přečtěte jeho položky a nepředpokládejte, že se rozhraní jmenuje tun0, protože číslování následuje pořadí vytvoření. Pokud na propojení odeslaná adresa chybí, selhalo předání, nikoli dotaz.

Pokud adresa přítomná je, další otázkou je, které domény si toto propojení nárokuje. Propojení bez seznamu domén odpovídá jen na jména, na která je dotazováno přímo, což je zřídka to, co nasazení split-DNS chce. Adresa sama je nutná, ale ne dostačující.

Než vyvodíte jakýkoli závěr, porovnejte název propojení ve výstupu resolveru s názvem rozhraní v logu VPN. Nesoulad tam obvykle znamená, že řádek logu přišel z jiného procesu.

Kontrola třetí: zda jmenný prostor volí toto propojení

Resolver může mít správný server a přesto nebýt dotazován. Doména pro propojení rozhoduje, které dotazy jdou na které propojení, a bez směrovací domény soukromý jmenný prostor padá zpět na to, co říká výchozí propojení. Proto může resolvectl query pro interní jméno uspět, zatímco aplikace stále selhává. Aplikace může používat zcela jinou cestu resolveru.

Zkontrolujte přiřazení domény, ne jen adresu serveru. Doména zapsaná jako ~corp.example je směrovací doména a vlnovka mění způsob porovnávání jména.

Pokud má aplikace vlastní resolver, testujte stejným mechanismem, který používá ona, nikoli systémovým nástrojem. Nástroj pro dotazy, který obchází systémový resolver, uspěje bez ohledu na stav propojení.

Kontrola čtvrtá: jeden vlastník, ne dva

Pokud NetworkManager už spravuje VPN i stav resolveru, přidání nesouvisejícího háčkového skriptu vytváří soupeřící zapisovatele. Háček, který balíček poskytuje pro systemd-resolved, je podporovaná integrace a očekává určitý životní cyklus: script-security 2, cestu up, up-restart, cestu down a down-pre. Tyto volby způsobují, že registrace a odstranění proběhnou ve správných okamžicích, ne jen při prvním připojení.

Použijte nainstalovanou cestu z balíčku, ne ilustrativní zkopírovanou z návodu. Na oprávněních také záleží, protože háček běží po odebrání privilegií.

Úprava resolverového skriptu distribuce za účelem změny jeho výstupního cíle zaznamenává obejití pro jeden hostitel. Není to obecná oprava.

Kontrola pátá: stejný výsledek po opětovném připojení

Připojte se znovu a přečtěte propojení znovu. Registrace, která se objeví jednou a zmizí při dalším přechodu, je porucha, kvůli které celý tento kontrolní seznam existuje. Testujte po uspání, po vynuceném opětovném připojení a po restartu služby resolveru. Každý přechod prověřuje jiný předpoklad o pořadí.

Teprve když při opětovném připojení projde všech pět kontrol, můžete říct, že se odeslaná nastavení používají. Cokoli dřívějšího je snímek šťastného okamžiku.