hosts-fil kontra ruterfilter: blokker et nettsted over en VPN

En oppføring i hosts-filen og et ruterfilter blokkerer samme nettsted av helt forskjellige grunner, derfor fortsetter den ene å virke under en VPN mens den andre stille stopper. hosts-filen svarer på et navn før noen pakke forlater maskinen. Ruterfilteret undersøker trafikk som krysser det. Sett en tunnel mellom de to punktene, og den andre mister oversikten mens den første ikke merker noe.

Hvor navnet løses opp avgjør alt

Hver blokkering begynner med et spørsmål: hvem gjør navnet om til en adresse? På en vanlig stasjonær svarer systemets resolver, som følger sin konfigurerte rekkefølge og vanligvis leser hosts-filen før den spør DNS. På et filtrert nettverk kan ruteren være svaret, og den ser bare forespørselen hvis klienten sender den gjennom ruteren ubeskyttet. Endre ruten, og du endrer hvem som har lov til å svare.

En VPN gjør to ting samtidig her: den flytter standardruten, og den kan skyve sin egen DNS-server. Enhver av de to endringene er nok til å flytte navneoppslag bort fra enheten som håndhevet blokkeringen.

Det er mekanismen bak den kjente klagen om at filteret virker til VPN-en kobles til.

En hosts-oppføring svarer før tunnelen finnes

En linje som 127.0.0.1 www.example.com leses av den lokale resolveren, så svaret produseres på maskinen uten nettverk. Koble til en tunnel, bytt DNS-server, bytt nettverk: oppføringen returnerer fortsatt loopback. Derfor er en hosts-blokkering den eneste av de to som ikke påvirkes av hvor VPN-en avsluttes.

De blinde flekkene er like lokale. Et program som har sin egen resolver, snakker DNS over HTTPS eller kobler til en bokstavelig adresse spør aldri systemet, så oppføringen brukes ikke. En mellomlagret adresse i en kjørende prosess har samme virkning til prosessen starter på nytt.

Bekreft svaret med getent ahosts på Linux eller Resolve-DnsName på Windows i stedet for å stole på en nettleserfane.

Et ruterfilter ser bare det som krysser det

Et innholds- eller URL-filter på en hjemmeruter matcher navn og forespørsler som passerer det i lesbar form. Når klienten bygger en kryptert tunnel til en server et annet sted, ser ruteren én strøm til den serveren og ingenting inni. Filteret har ikke noe navn å matche, så det slipper trafikken gjennom, og det ser ut som filteret sviktet, ikke som at det ble omgått.

Topologien som virker er den andre: ruteren holder tunnelen selv, dekrypterer ved endepunktet og bruker filteret der. I det designet sitter filteret der klarteksten vises.

Hvis tunnelen ender på den bærbare, er ruteren per definisjon utenfor den beskyttede veien, uansett hvordan regelen er skrevet.

Fire håndhevingspunkter og hva hvert av dem går glipp av

Fire steder kan håndheve en blokkering, og hvert av dem svikter forskjellig. Les listen som et dekningskart, ikke som en rangering.

• hosts-fil eller lokal resolver: virker offline og under enhver tunnel, men omgås av en innebygd resolver eller en hardkodet adresse.
• DNS-filtrering ved VPN-gatewayen: dekker klienter som bruker den påskyvede resolveren, og går glipp av klienter som overstyrer DNS.
• Gateway-utgangsregler etter adresse eller SNI: uavhengige av klientens DNS, men blinde for navn de ikke kan lese og adresser de ikke har lært.
• Styrt nettleser- eller enhetspolicy: sterk på styrt maskinvare, fraværende på personlige enheter.

Ingen av disse er en sikkerhetsgrense mot en bestemt bruker på en ustyrt enhet. De er policykontroller, og en ærlig beskrivelse sier hvilken trafikk hver av dem faktisk dekker.

Velg laget som passer til hensikten: hjemlig bekvemmelighet hører til på enheten, og en organisasjonsregel hører til ved gatewayen.

Test begge tilstander før du kaller det ferdig

Kjør de samme tre kommandoene med VPN-en tilkoblet og frakoblet: getent ahosts for å se resolverens svar, nslookup for å se hva forespørselen returnerer, og curl -I mot nettstedet for å se om en tilkobling fortsatt fullføres. Hvis den første returnerer loopback mens den tredje kobler til den ekte adressen, har noe omgått resolveren, og hosts-oppføringen er ikke den kontrollen du tror.

På ruteren, les filtertellerne før og etter en forespørsel. En teller som aldri flytter seg betyr at trafikken aldri nådde filteret, og det er et rutesvar, ikke et regelsvar.

Skriv ned resultatet sammen med topologien, for den neste VPN-endringen flytter ruten igjen.