hosts-fil kontra routerfilter: blockera en webbplats över ett VPN

En post i hosts-filen och ett routerfilter blockerar samma webbplats av helt olika skäl, därför fortsätter den ena att fungera under ett VPN medan den andra tystnar. hosts-filen svarar på ett namn innan något paket lämnar maskinen. Routerfiltret granskar trafik som passerar det. Sätt en tunnel mellan de två punkterna och den andra tappar sin vy medan den första inte märker något.

Var namnet slås upp avgör allt

Varje blockering börjar med en fråga: vem gör om namnet till en adress? På en vanlig stationär dator svarar systemets resolver, som följer sin konfigurerade ordning och vanligtvis läser hosts-filen innan den frågar DNS. På ett filtrerat nätverk kan routern vara svaret, och den ser bara frågan om klienten skickar den genom routern oskyddad. Ändra vägen och du ändrar vem som får svara.

Ett VPN gör två saker samtidigt här: det flyttar standardrutten och det kan trycka ut sin egen DNS-server. Endera ändringen räcker för att flytta namnuppslagningen bort från enheten som upprätthöll blockeringen.

Det är mekanismen bakom det vanliga klagomålet att filtret fungerar tills VPN:et ansluter.

En hosts-post svarar innan tunneln finns

En rad som 127.0.0.1 www.example.com läses av den lokala resolvern, så svaret skapas på maskinen utan nätverk. Anslut en tunnel, byt DNS-server, byt nätverk: posten returnerar fortfarande loopback. Därför är en hosts-blockering den enda av de två som inte påverkas av var VPN:et slutar.

Dess blinda fläckar är lika lokala. Ett program som har sin egen resolver, talar DNS over HTTPS eller ansluter till en bokstavlig adress frågar aldrig systemet, så posten används inte. En cachelagrad adress i en pågående process har samma effekt tills processen startas om.

Bekräfta svaret med getent ahosts på Linux eller Resolve-DnsName på Windows i stället för att lita på en webbläsarflik.

Ett routerfilter ser bara det som passerar det

Ett innehålls- eller URL-filter på en hemrouter matchar namn och förfrågningar som passerar det i läsbar form. När klienten bygger en krypterad tunnel till en server någon annanstans ser routern ett enda flöde till den servern och ingenting inuti. Filtret har inget namn att matcha, så det släpper igenom trafiken, och det ser ut som att filtret misslyckades, inte som att det kringgicks.

Topologin som fungerar är den andra: routern håller tunneln själv, dekrypterar vid slutpunkten och tillämpar filtret där. I den designen sitter filtret där klartexten syns.

Om tunneln slutar på bärbara datorn står routern per definition utanför den skyddade vägen, oavsett hur regeln är skriven.

Fyra tillämpningspunkter och vad var och en missar

Fyra ställen kan upprätthålla en blockering och var och en misslyckas olika. Läs listan som en täckningskarta, inte som en rangordning.

• hosts-fil eller lokal resolver: fungerar offline och under alla tunnlar, men kringgås av en inbyggd resolver eller en hårdkodad adress.
• DNS-filtrering vid VPN-gatewayen: täcker klienter som använder den påtvingade resolvern och missar klienter som åsidosätter DNS.
• Gateway-utgångsregler efter adress eller SNI: oberoende av klientens DNS, men blinda för namn de inte kan läsa och adresser de inte har lärt sig.
• Hanterad webbläsar- eller enhetspolicy: stark på hanterad hårdvara, frånvarande på personliga enheter.

Ingen av dessa är en säkerhetsgräns mot en beslutsam användare på en ohanterad enhet. De är policykontroller, och en ärlig beskrivning säger vilken trafik var och en faktiskt täcker.

Välj det lager som passar syftet: hembekvämlighet hör till enheten och en organisationsregel hör till gatewayen.

Testa båda tillstånden innan du kallar det klart

Kör samma tre kommandon med VPN:et anslutet och frånkopplat: getent ahosts för att se resolverns svar, nslookup för att se vad frågan returnerar och curl -I mot webbplatsen för att se om en anslutning fortfarande fullbordas. Om den första returnerar loopback medan den tredje ansluter till den riktiga adressen har något kringgått resolvern och hosts-posten är inte den kontroll du tror.

På routern, läs filterräknarna före och efter en begäran. En räknare som aldrig rör sig betyder att trafiken aldrig nådde filtret, och det är ett routningssvar, inte ett regelsvar.

Skriv ner resultatet tillsammans med topologin, för nästa VPN-ändring flyttar vägen igen.