hosts-bestand versus routerfilter: een site blokkeren via een VPN

Een regel in het hosts-bestand en een routerfilter blokkeren dezelfde site om volledig verschillende redenen, daarom blijft de ene onder een VPN werken en stopt de andere stil. Het hosts-bestand beantwoordt een naam voordat er ook maar een pakket de machine verlaat. Het routerfilter inspecteert verkeer dat erdoorheen gaat. Zet een tunnel tussen die twee punten en de tweede verliest zijn zicht, terwijl de eerste niets merkt.

Waar de naam wordt opgelost, bepaalt alles

Elke blokkade begint met een vraag: wie zet de naam om in een adres? Op een gewone desktop antwoordt de systeemresolver, die zijn ingestelde volgorde volgt en meestal het hosts-bestand leest voordat hij DNS vraagt. Op een gefilterd netwerk kan de router het antwoord zijn, die de query alleen ziet als de client hem onbeschermd door de router stuurt. Verander het pad en je verandert wie mag antwoorden.

Een VPN doet hier twee dingen tegelijk: hij verplaatst de standaardroute, en hij kan zijn eigen DNS-server opdringen. Elk van beide veranderingen is genoeg om naamresolutie weg te halen bij het apparaat dat de blokkade afdwong.

Dat is het mechanisme achter de bekende klacht dat het filter werkt tot de VPN verbindt.

Een hosts-regel antwoordt voordat de tunnel bestaat

Een regel als 127.0.0.1 www.example.com wordt door de lokale resolver gelezen, dus het antwoord wordt op de machine geproduceerd zonder netwerk. Sluit een tunnel aan, wijzig de DNS-server, wissel van netwerk: de regel geeft nog steeds loopback terug. Daarom is een hosts-blokkade de enige van de twee die niet afhangt van waar de VPN eindigt.

De blinde vlekken zijn even lokaal. Een applicatie die zijn eigen resolver meebrengt, DNS over HTTPS spreekt of verbindt met een letterlijk adres, vraagt het systeem nooit, dus de regel wordt niet geraadpleegd. Een adres in de cache van een draaiend proces heeft hetzelfde effect totdat dat proces opnieuw start.

Bevestig het antwoord met getent ahosts op Linux of Resolve-DnsName op Windows in plaats van een browsertab te vertrouwen.

Een routerfilter ziet alleen wat erdoorheen gaat

Een inhouds- of URL-filter op een thuisrouter matcht namen en verzoeken die er in leesbare vorm doorheen gaan. Wanneer de client een versleutelde tunnel naar een server elders opbouwt, ziet de router één stroom naar die server en niets erin. Het filter heeft geen naam om te matchen, dus het laat het verkeer door, en dat lijkt op een falend filter, niet op een omzeild filter.

De topologie die werkt is de andere: de router houdt de tunnel zelf, ontsleutelt aan het eindpunt en past het filter daar toe. In dat ontwerp zit het filter waar de platte tekst verschijnt.

Als de tunnel op de laptop eindigt, staat de router per definitie buiten het beschermde pad, hoe de regel ook is geschreven.

Vier handhavingspunten en wat elk mist

Vier plekken kunnen een blokkade afdwingen, en elk faalt anders. Lees de lijst als een dekkingskaart, niet als een rangorde.

• hosts-bestand of lokale resolver: werkt offline en onder elke tunnel, maar wordt omzeild door een ingebouwde resolver of een hardgecodeerd adres.
• DNS-filtering bij de VPN-gateway: dekt clients die de opgedrongen resolver gebruiken, en mist clients die DNS overschrijven.
• Gateway-uitgangsregels op adres of SNI: onafhankelijk van de DNS van de client, maar blind voor namen die het niet kan lezen en adressen die het niet heeft geleerd.
• Beheerd browser- of apparaatbeleid: sterk op beheerde hardware, afwezig op persoonlijke apparaten.

Geen van deze is een beveiligingsgrens tegen een vastberaden gebruiker op een onbeheerd apparaat. Het zijn beleidscontroles, en een eerlijke beschrijving zegt welk verkeer elk ervan werkelijk dekt.

Kies de laag die bij de bedoeling past: huiselijk gemak hoort op het apparaat, en een organisatieregel hoort bij de gateway.

Test beide toestanden voordat je het af noemt

Voer dezelfde drie opdrachten uit met de VPN verbonden en verbroken: getent ahosts om het antwoord van de resolver te zien, nslookup om te zien wat de query teruggeeft, en curl -I tegen de site om te zien of een verbinding nog tot stand komt. Als de eerste loopback teruggeeft terwijl de derde verbindt met het echte adres, heeft iets de resolver omzeild en is de hosts-regel niet de controle die je denkt.

Lees op de router de filtertellers voor en na een verzoek. Een teller die nooit beweegt betekent dat het verkeer het filter nooit bereikte, en dat is een routeringsantwoord, geen regelantwoord.

Schrijf het resultaat op samen met de topologie, want de volgende VPN-wijziging verplaatst het pad opnieuw.