Povolte DNS jen přes svůj VPN resolver: procházka krok za krokem

Sledujte jeden dotaz na jméno od chvíle, kdy ho napíšete. Prohlížeč se ptá operačního systému, operační systém se ptá resolveru, který vybere jeho politika, a dotaz opouští zařízení nějakým rozhraním a nějakým transportem. Váš návrh VPN říká, že odpověď má přijít od určitého resolveru určitou cestou. Rozdíl mezi těmito dvěma tvrzeními je to, co nastavíte a potom vynutíte.

Krok 1: pojmenujte resolver a cestu

Než se dotknete firewallu, zapište tři věci: adresu resolveru, protokol a port, které očekáváte, a rozhraní, kterým má dotaz odejít. Bez tohoto seznamu je pravidlo dohadem o provozu, nikoli vynucením rozhodnutí. VPN může přenášet data aplikací, zatímco DNS jde vlastním uspořádáním, a samo o sobě to není chyba. Je to to, co se stane, když klientovi nikdo neřekl nic jiného.

Pojmenovat cestu výslovně je rozdíl mezi návrhem a náhodou. Dává vám také něco k pozdějšímu testování, protože každé pozorování lze srovnat s písemným očekáváním. Držte ten seznam v tiketu změny, ne v něčí hlavě.

Krok 2: nastavte politiku tam, kde skutečně žije

Volba resolveru patří klientovi: síťová konfigurace operačního systému, vlastní nastavení VPN klienta nebo spravovaná politika prohlížeče. Nastavte ji nejprve tam, mechanismem, který platforma podporuje, protože firewall nemůže přimět klienta zvolit resolver, o kterém se nikdy nedozvěděl. U klienta s rozděleným tunelem výslovně řekněte, které domény jdou na interní resolver. Ve spravované flotile bývá politika prohlížeče jedinou pákou pro DoH, protože prohlížeč si může zvolit vlastní šifrovaný resolver nezávisle na systémovém nastavení.

Přeskočte to a jděte rovnou na firewall a dostanete pravidlo, které povoluje správný resolver, plus klienta, který ho nikdy nepoužije. Pravidlo vypadá správně a protokoly resolveru zůstávají prázdné, což je při ladění matoucí dvojice. Nejprve nastavte volbu, potom ji vynuťte.

Krok 3: vynuťte cestu úzce

Nyní přidejte síťové povolení pro povolenou cestu: adresu resolveru, protokol a port a rozhraní, kterým má odejít. Držte pravidlo omezené na tento resolver místo povolení veškerého odchozího DNS. Tři cesty níže jsou ty, kterými se moderní klient může vydat, a jen první pokrývá pravidlo pro port 53.

Blokovat DoH a DoT je legitimní; předpokládat, že je pravidlo pro port 53 už zablokovalo, nikoli. Prohlížeč s DoH řeší jména cestou, kterou vaše pravidlo nikdy nepopisovalo, a aplikace s vlastním resolverem dělá totéž. Zapište každou cestu, kterou hodláte povolit, i každou, kterou hodláte odmítnout. Pravidlo, které cestu nepojmenuje, o ní nerozhodlo.

Krok 4: sledujte soukromá a veřejná jména

Rozdělený DNS záměrně posílá jen soukromé jmenné prostory na interní resolver, zatímco veřejná jména jdou jinam, takže víc resolverů v návrhu není únik. Únik je dotaz, který měl jít na váš resolver a objeví se jinde, nebo nedostupná zamýšlená cesta, kvůli které klient tiše padne zpět. Tyto dva případy je třeba hledat. Sledujte interní a veřejné jméno podle zamýšlené politiky a poznamenejte, který resolver na každé odpověděl.

Testovací stránka, která hlásí váš resolver, je náznak, ne důkaz, protože vidí jen dotazy, které k ní dorazily. Zachyťte dotaz na straně klienta, když potřebujete vědět, kterou cestou skutečně šel, a obě pozorování srovnejte. Když se rozcházejí, našli jste návrat, který nikdo nezdokumentoval.

Je-li adresa resolveru správná, ale nedostupná, problém je v směrování nebo filtrování, nikoli v politice. Vystopujte dotaz na tuto adresu a potvrďte, že se odpověď vrací očekávaným rozhraním, než změníte jakékoli nastavení resolveru.

Krok 5: nechte si cestu zpět

Než utáhnete přístup k DNS na bráně, potvrďte způsob obnovy, který nezávisí na překladu jmen. Rozbitý resolver ztěžuje dosažení všech opravných nástrojů, včetně těch, kterými byste změnu vrátili. Držte lokální konzoli nebo mimopásmovou cestu otevřenou, dokud nová politika neprojde ověřením. Odstraňte ji až poté, co politika přežila opětovné připojení.

Po opětovném připojení nebo aktualizaci politiky prohlížeče znovu prohlédněte efektivní stav, protože obojí může změnit resolver, aniž by změnilo vaše pravidlo. Požadavkem je známý příjemce a chráněná cesta pro dotazy, ne uklidňující štítek resolveru na jednom snímku obrazovky. Specifikace RFC 8484 pro DNS over HTTPS je referencí pro šifrovanou cestu, kterou vaše pravidlo portu nevidí.