Soubor hosts proti filtru na routeru: blokování webu přes VPN

Záznam v souboru hosts a filtr na routeru blokují stejný web z úplně jiných důvodů, proto jeden funguje dál pod VPN a druhý tiše přestane. Soubor hosts odpovídá na jméno dřív, než stroj opustí jakýkoli paket. Filtr na routeru zkoumá provoz, který jím prochází. Umístěte tunel mezi tyto dva body a druhý ztratí výhled, zatímco první si ničeho nevšimne.

Kde se jméno vyřeší, rozhoduje o všem

Každé blokování začíná otázkou: kdo převádí jméno na adresu? Na běžném stolním počítači odpovídá systémový resolver, který jde podle nastaveného pořadí a obvykle čte soubor hosts dřív než dotaz na DNS. Ve filtrované síti může odpovědět router, který dotaz vidí jen tehdy, když ho klient pošle přes router nechráněný. Změňte cestu a změníte, kdo smí odpovídat.

VPN tu dělá dvě věci najednou: přesouvá výchozí trasu a může protlačit svůj vlastní DNS server. Stačí kterákoli z těchto změn, aby se překlad jmen přesunul mimo zařízení, které blok prosazovalo.

To je mechanismus známé stížnosti, že filtr funguje, dokud se VPN nepřipojí.

Záznam v hosts odpovídá dřív, než tunel existuje

Řádek jako 127.0.0.1 www.example.com čte místní resolver, takže odpověď vzniká na stroji bez jakékoli sítě. Připojte tunel, změňte DNS server, přepněte sítě: záznam pořád vrací loopback. Proto je blok přes hosts jediný ze dvou, který nezávisí na tom, kde VPN končí.

Jeho slepá místa jsou stejně místní. Aplikace, která nese vlastní resolver, mluví DNS over HTTPS nebo se připojuje k doslovné adrese, se systému nikdy neptá, takže záznam se nepoužije. Adresa v cache běžícího procesu má stejný účinek, dokud se ten proces restartuje.

Potvrďte odpověď pomocí getent ahosts na Linuxu nebo Resolve-DnsName na Windows, místo abyste věřili záložce prohlížeče.

Filtr na routeru vidí jen to, co jím projde

Filtr obsahu nebo URL na domácím routeru páruje jména a požadavky, které jím procházejí v čitelné podobě. Když klient vytvoří šifrovaný tunel k serveru někde jinde, router vidí jediný tok k tomu serveru a nic uvnitř. Filtr nemá jméno k párování, takže provoz pustí, a to vypadá, jako by filtr selhal, ne jako by ho obešli.

Funguje jiná topologie: router drží tunel sám, dešifruje na konci a filtr aplikuje tam. V tom návrhu filtr sedí tam, kde se objevuje čistý text.

Pokud tunel končí na notebooku, je router podle definice mimo chráněnou cestu, ať je pravidlo napsané jakkoli.

Čtyři místa prosazení a co každé mine

Blok mohou prosadit čtyři místa a každé selhává jinak. Čtěte seznam jako mapu pokrytí, ne jako žebříček.

• Soubor hosts nebo místní resolver: funguje offline a pod jakýmkoli tunelem, ale obejde ho zabudovaný resolver nebo pevně zadaná adresa.
• DNS filtrování na VPN bráně: pokrývá klienty, kteří používají protlačený resolver, a míjí klienty, kteří DNS obcházejí.
• Pravidla odchodu na bráně podle adresy nebo SNI: nezávislá na DNS klienta, ale slepá ke jménům, která nedokážou přečíst, a k adresám, které se nenaučily.
• Spravovaná politika prohlížeče nebo zařízení: silná na spravovaném hardware, chybí na osobních zařízeních.

Nic z toho není bezpečnostní hranice proti rozhodnému uživateli na nespravovaném zařízení. Jsou to politické kontroly a poctivý popis říká, který provoz každá skutečně pokrývá.

Vyberte vrstvu, která odpovídá záměru: domácí pohodlí patří na zařízení a organizační pravidlo na bránu.

Otestujte oba stavy, než to prohlásíte za hotové

Spusťte stejné tři příkazy s připojenou i odpojenou VPN: getent ahosts pro odpověď resolveru, nslookup pro to, co dotaz vrací, a curl -I proti webu pro to, zda se spojení ještě dokončí. Pokud první vrací loopback a třetí se připojuje ke skutečné adrese, něco obešlo resolver a záznam hosts není kontrola, kterou si myslíte.

Na routeru přečtěte počítadla filtru před požadavkem a po něm. Počítadlo, které se nikdy nehne, znamená, že provoz se k filtru nikdy nedostal, a to je odpověď směrování, ne pravidla.

Zapište výsledek spolu s topologií, protože příští změna VPN cestu zase posune.