hosts-fil kontra routerfilter: blokér en side over en VPN

En post i hosts-filen og et routerfilter blokerer den samme side af helt forskellige grunde, og derfor bliver den ene ved med at virke under en VPN, mens den anden stille holder op. hosts-filen svarer på et navn, før nogen pakke forlader maskinen. Routerfilteret undersøger trafik, der krydser det. Sæt en tunnel mellem de to punkter, og den anden mister udsynet, mens den første ikke bemærker noget.

Hvor navnet slås op, afgør alt

Enhver blokering begynder med et spørgsmål: hvem omsætter navnet til en adresse? På en almindelig stationær svarer systemets resolver, som følger sin konfigurerede rækkefølge og typisk læser hosts-filen, før den spørger DNS. På et filtreret netværk kan routeren være svaret, og den ser kun forespørgslen, hvis klienten sender den gennem routeren ubeskyttet. Ændr ruten, og du ændrer, hvem der må svare.

En VPN gør to ting på én gang her: den flytter standardruten, og den kan skubbe sin egen DNS-server. Enhver af de to ændringer er nok til at flytte navneopslag væk fra den enhed, der håndhævede blokeringen.

Det er mekanismen bag den velkendte klage om, at filteret virker, indtil VPN'en forbinder.

En hosts-post svarer, før tunnelen findes

En linje som 127.0.0.1 www.example.com læses af den lokale resolver, så svaret produceres på maskinen uden netværk. Tilslut en tunnel, skift DNS-server, skift netværk: posten returnerer stadig loopback. Derfor er en hosts-blokering den eneste af de to, der ikke påvirkes af, hvor VPN'en slutter.

Dens blinde vinkler er lige så lokale. Et program, der har sin egen resolver, taler DNS over HTTPS eller forbinder til en bogstavelig adresse, spørger aldrig systemet, så posten bruges ikke. En mellemlagret adresse i en kørende proces har samme virkning, indtil processen genstarter.

Bekræft svaret med getent ahosts på Linux eller Resolve-DnsName på Windows i stedet for at stole på en browserfane.

Et routerfilter ser kun det, der krydser det

Et indholds- eller URL-filter på en hjemmerouter matcher navne og anmodninger, der passerer det i læsbar form. Når klienten bygger en krypteret tunnel til en server et andet sted, ser routeren én strøm til den server og intet indeni. Filteret har intet navn at matche, så det tillader trafikken, og det ser ud, som om filteret svigtede, ikke som om det blev omgået.

Den topologi, der virker, er den anden: routeren holder tunnelen selv, dekrypterer ved endepunktet og anvender filteret der. I det design sidder filteret, hvor klarteksten vises.

Hvis tunnelen slutter på bærbaren, er routeren per definition uden for den beskyttede vej, uanset hvordan reglen er skrevet.

Fire håndhævelsespunkter og hvad hvert enkelt misser

Fire steder kan håndhæve en blokering, og hvert enkelt fejler forskelligt. Læs listen som et dækningskort, ikke som en rangliste.

• hosts-fil eller lokal resolver: virker offline og under enhver tunnel, men omgås af en indbygget resolver eller en hårdkodet adresse.
• DNS-filtrering ved VPN-gatewayen: dækker klienter, der bruger den skubbede resolver, og misser klienter, der tilsidesætter DNS.
• Gateway-udgangsregler efter adresse eller SNI: uafhængige af klientens DNS, men blinde for navne, de ikke kan læse, og adresser, de ikke har lært.
• Styret browser- eller enhedspolitik: stærk på styret hardware, fraværende på personlige enheder.

Ingen af disse er en sikkerhedsgrænse mod en beslutsom bruger på en ustyret enhed. De er politikstyringer, og en ærlig beskrivelse siger, hvilken trafik hver enkelt faktisk dækker.

Vælg det lag, der passer til hensigten: huslig bekvemmelighed hører til på enheden, og en organisatorisk regel hører til ved gatewayen.

Test begge tilstande, før du kalder det færdigt

Kør de samme tre kommandoer med VPN'en tilsluttet og afbrudt: getent ahosts for at se resolverens svar, nslookup for at se, hvad forespørgslen returnerer, og curl -I mod siden for at se, om en forbindelse stadig fuldføres. Hvis den første returnerer loopback, mens den tredje forbinder til den rigtige adresse, har noget omgået resolveren, og hosts-posten er ikke den kontrol, du tror.

På routeren skal du læse filtertællerne før og efter en anmodning. En tæller, der aldrig flytter sig, betyder, at trafikken aldrig nåede filteret, og det er et rutesvar, ikke et regelsvar.

Skriv resultatet ned sammen med topologien, for den næste VPN-ændring flytter igen ruten.