Rozdělené DNS a VPN: pravidla domén nejsou IP trasy

Váš notebook překládá intranet.corp přes tunel, zatímco gitlab.com dál chodí k překladači poskytovatele, a to je uspořádání, které funguje podle návrhu. Vzniklo ze dvou oddělených rozhodnutí: pravidlo shody jména vybralo překladač a trasa přinesla odpověď zpět. Porušte kterékoli z nich a prohlížeč ukáže selhání, které zvenčí vypadá stejně. Většina zpráv o rozděleném DNS popisuje druhé selhání, a přitom cituje důkazy o prvním.

Obě poloviny žijí na různých místech a obvykle je upravují různí lidé. Jedna je zásada DNS připojená k profilu VPN, druhá je trasa, kterou tunel instaluje nebo zadržuje. Ladění se zasekne, když nikdo neustanoví, která polovina se vlastně pohnula.

Dvě rozhodnutí skrytá v jednom požadavku

Polovina jména je objekt zásad, ne trasa. Ve Windows je to zásada překladu jmen v profilu VPN; na platformách Apple sada domén shody v objektu nastavení DNS; v Linuxu doména směrování, řádek rozděleného překladače nebo pořadí přepínače jmenné služby. Polovina cesty je obyčejné směrování, instalované tunelem nebo ručně, a nemá ponětí, co je jméno hostitele. Profil, který připouští příponu, rozhoduje jen o tom, kdo odpovídá; nikdy nedělá odpověď dosažitelnou.

Rychlý test příznaků je oddělí: nahraďte jméno adresou. Pokud adresa funguje, cesta je v pořádku a pravidlo je špatné. Pokud selže i adresa, pravidlo může být správné a cesta chybí.

Jak každá platforma vyjadřuje stejné pravidlo jmen

Záměr je totožný a názvy polí nejsou. Příklad zkopírovaný z jednoho klienta do druhého se parsuje čistě a nikdy se neshoduje. Tři podoby vypadají takto:

Doména shody nebo směrování je test přípony, takže intranet.corp pokrývá git.intranet.corp a nepokrývá corp.intranet, a obrácení tohoto vztahu je nejčastější chyba v celém nastavení. Windows nese mapování jako zásadu překladu jmen připojenou k profilu, s vlastním pořadím priorit vůči jakémukoli seznamu přípon, který rozhraní už mělo. Platformy Apple připojují domény shody k objektu nastavení DNS síťového rozšíření a systém je uplatňuje pro každý omezený překladač. Žádná z těchto podob není trasa a žádná nedokáže učinit nedosažitelnou adresu dosažitelnou. Referenční stránka zásada překladu jmen ve Windows uvádí názvy polí a pravidla priorit pro tuto platformu a nejsou to ta, která používají dokumenty Apple nebo systemd.

Správná odpověď stále potřebuje cestu

Odpověď překladače je jen adresa a aplikace se k ní stále musí dostat. Návrh rozděleného tunelu často protlačuje 10.20.0.0/16 a zadržuje výchozí trasu, takže interní jméno se přeloží a spojení pak visí. Opačný případ je stejně častý: trasa existuje, veřejný překladač odpoví na soukromé jméno NXDOMAIN a selhání se zapíše jako problém směrování. Testování cesty jako prvního vás nechá zírat na trasy kvůli jménu, které se nikdy nemělo přeložit.

Existuje i třetí brána, kterou žádná polovina nepokrývá. ACL na bráně, pravidlo firewallu nebo zásada na straně klienta mohou spojení zahodit poté, co obě rozhodnutí byla správná. Když se jméno přeloží, trasa existuje a spojení přesto vyprší, přestaňte testovat DNS.

Testování jmen a cest v pevném pořadí

Zvolte pořadí a držte se ho, jinak budete honit krok, který selhal naposledy. Přeložte dokumentované plné interní jméno, potvrďte, že odpověď je adresa, kterou směrovací tabulka unese, a pak to zopakujte s veřejným jménem, abyste dokázali, že tunel nezachytil všechno. Na hostiteli se systemd dělí dotaz a doména směrování překladače jedním příkazem:

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Klient Windows klade stejné dvě otázky jinými rutinami. Druhá hlásí rozhraní, které by systém skutečně použil:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

Pokud vyhledání vrátí adresu a kontrola cesty označí fyzické rozhraní, pravidlo jmen fungovalo a trasa ne. Pokud krátké jméno selže, zatímco plné jméno se přeloží, chybný je seznam přípon, ne překladač.

Kde se srovnání obvykle pokazí

První chyba je ptát se nesouvisejícího veřejného překladače na soukromé jméno a číst odmítnutí jako důkaz o VPN. Druhá je předpokládat, že funkční veřejné vyhledání dokazuje cestu překladače tunelu. Třetí je považovat rozdělené tunelování a rozdělené DNS za jedno návrhové rozhodnutí, když nasazení může být správné v jednom a rozbité v druhém. Každá chyba dává sebejisté závěry z testu, který nikdy necvičil obviňovanou část.

Prohlížeč s vlastním zabezpečeným DNS může také obejít systémové pravidlo, a proto jeden prohlížeč selhávající, zatímco jiný uspěje, není protiklad. Porovnávejte překladač, který odpověděl, ne prohlížeč, který si stěžoval.

Jakmile jsou obě poloviny viditelné, zbývající otázka je otázkou zásad, ne techniky: které jmenné prostory patří organizaci, kdo vlastní každou odpověď a které z nich by měly vůbec opustit stroj. Zapište to vedle profilu, protože příští člověk, který se pravidla dotkne, to bude potřebovat.