DNS filtr ve VPN: blokování jmen nezablokuje reklamy

Jediný řádek v dnsmasq může odpovědět na jméno NXDOMAIN a to je celý mechanismus. Nikdy nečte HTML, nezkoumá cestu požadavku a nevidí, co aplikace dělá se spojením, které už otevřela. Srovnávat ho s rozšířením prohlížeče je proto srovnávání dvou různých úkolů. Jeden rozhoduje, zda se jméno přeloží; druhý rozhoduje, co se stane potom.

Co filtr jmen ve skutečnosti řídí

Volba address=/metrics.example/, za posledním lomítkem nic, způsobí, že překladač vrátí NXDOMAIN pro toto jméno a jeho subdomény. Nechat adresu prázdnou je ta důležitá část: zabrání to posílání klientů na nesouvisející náhradní server nebo vydávání adresy loopback za skutečný cíl. Manuál k dnsmasq popisuje tuto podobu jako zápornou odpověď, nikoli jako přesměrování.

Všechno, co pravidlo umí, plyne z tohoto jediného rozhodnutí. Klient, který se ptá tohoto překladače, dostane zápornou odpověď; klient, který se ptá jiného překladače, dostane to, co řekne onen překladač. Filtr nic neví o cestě, dotazovacím řetězci ani účtu, které by aplikace použila.

Tato podrobnost je důležitá, protože jedno jméno hostitele často slouží několika účelům. Přihlašovací koncové body, obrázky a sledování mohou sdílet doménu a pravidlo, které odebere celé jméno, může s ním odebrat i pracovní postup. Zásada na úrovni jména musí tento kompromis přijmout, nebo zvolit užší jména.

Čím se blokátor na straně klienta liší

Rozšíření prohlížeče vidí požadavek dřív, než odejde, takže umí porovnat cestu URL, zrušit konkrétní požadavek a skrýt prvek, který by výsledek zobrazil. Umí povolit example.com/article a přitom odmítnout example.com/ads/, což žádná odpověď DNS vyjádřit nedokáže. Tento pohled na úrovni cesty je schopnost, kterou překladač prostě nemá. Proto se seznam filtrů vytvořený pro jeden nástroj v druhém chová jen zřídka stejně.

Cenou je rozsah. Taková ochrana žije v jednom prohlížeči, v jednom profilu, na jednom zařízení a zmizí, když uživatel přejde k jiné aplikaci. DNS filtr nastavený na bráně pokrývá každé zařízení, které používá překladač brány, včetně zařízení, na která žádné rozšíření nainstalovat nelze.

Ani jedno z těch dvou uspořádání není samo o sobě úplné. DNS filtr neumí odstranit identifikátor, který stránka už odeslala, a rozšíření prohlížeče neumí ochránit aplikaci, která ho nikdy nenačte.

Cesta překladače rozhoduje o tom, zda se něco z toho uplatní

VPN může inzerovat server DNS a přesto nedostávat každý dotaz. Prohlížeč s nastaveným šifrovaným DNS, aplikace s vlastním překladačem nebo zařízení na síťové cestě, která bránu vylučuje, se všechny budou ptát jinde. Mobilní platformy stále častěji nabízejí nastavení soukromého DNS, které tiše přebíjí to, co tunel navrhuje.

Testujte tedy cestu, ne zásadu. Zeptejte se zamýšleného překladače přímo z brány, pak se ho zeptejte z klienta a porovnejte, a potom sledujte, zda jméno, které má být blokováno, v aplikaci, kterou uživatel spouští, skutečně selže.

Uložené odpovědi a otevřené sockety to dělají hlučným. Stránka, která už načetla své zdroje, bude po změně pravidla dál fungovat, takže nové spojení je lepší test než znovunačtení staré karty.

Otestujte oba směry, než výsledek oznámíte

Použijte záměrně blokované jméno z dokumentace, povolené veřejné jméno a soukromé jméno, které služba potřebuje:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Prázdná odpověď pro blokované jméno, běžná adresa pro veřejné a soukromá adresa pro interní dohromady ukazují, že filtrování, překlad proti nadřazenému serveru i místní záznamy fungují. Pokud selžou všechny tři, díváte se na problém nadřazeného serveru nebo naslouchajícího procesu, ne filtru.

Držte tvrzení úzké ve všem, co interně publikujete. Tohle je filtrování domén na překladači, ne kontrola obsahu, ne filtrování cest a ne slib, že nikdo není sledován. Uveďte vedle pravidel vlastníka zásady, cestu výjimky a dobu uchovávání dotazů, protože filtr, který zaznamenává každé vyhledání, má svou vlastní cenu za soukromí.