hosts-fil kontra ruterfilter: blokker ein nettstad over ein VPN

Ei oppføring i hosts-fila og eit ruterfilter blokkerer same nettstad av heilt ulike grunnar, difor held den eine fram med å verke under ein VPN medan den andre stille stoppar. hosts-fila svarar på eit namn før nokon pakke forlèt maskina. Ruterfilteret granskar trafikk som kryssar det. Set ein tunnel mellom dei to punkta, og den andre mistar oversynet medan den første ikkje merkar noko.

Kvar namnet vert løyst opp avgjer alt

Kvar blokkering byrjar med eit spørsmål: kven gjer namnet om til ei adresse? På ein vanleg stasjonær svarar resolvaren til systemet, som følgjer den konfigurerte rekkjefølgja si og vanlegvis les hosts-fila før han spør DNS. På eit filtrert nettverk kan rutaren vere svaret, og han ser berre førespurnaden om klienten sender han gjennom rutaren utan vern. Endre ruta, og du endrar kven som har lov til å svare.

Ein VPN gjer to ting samstundes her: han flyttar standardruta, og han kan skyve sin eigen DNS-tenar. Kvar av dei to endringane er nok til å flytte namneoppslag bort frå eininga som handheva blokkeringa.

Det er mekanismen bak den kjende klaga om at filteret verkar til VPN-en vert kopla til.

Ei hosts-oppføring svarar før tunnelen finst

Ei line som 127.0.0.1 www.example.com vert lesen av den lokale resolvaren, så svaret vert produsert på maskina utan nettverk. Kopla til ein tunnel, byt DNS-tenar, byt nettverk: oppføringa returnerer framleis loopback. Difor er ei hosts-blokkering den einaste av dei to som ikkje vert påverka av kvar VPN-en sluttar.

Dei blinde flekkane er like lokale. Eit program som har sin eigen resolvar, talar DNS over HTTPS eller koplar til ei bokstaveleg adresse spør aldri systemet, så oppføringa vert ikkje brukt. Ei mellomlagra adresse i ein køyrande prosess har same verknad til prosessen startar på nytt.

Stadfest svaret med getent ahosts på Linux eller Resolve-DnsName på Windows i staden for å stole på ei nettlesarfane.

Eit ruterfilter ser berre det som kryssar det

Eit innhalds- eller URL-filter på ein heimeruter matchar namn og førespurnader som passerer det i lesbar form. Når klienten byggjer ein kryptert tunnel til ein tenar ein annan stad, ser rutaren éin straum til den tenaren og ingenting inni. Filteret har ikkje noko namn å matche, så det slepp trafikken gjennom, og det ser ut som filteret svikta, ikkje som at det vart omgått.

Topologien som verkar er den andre: rutaren held tunnelen sjølv, dekrypterer ved endepunktet og brukar filteret der. I det designet sit filteret der klarteksten viser seg.

Viss tunnelen endar på den berbare, er rutaren per definisjon utanfor den verna vegen, uansett korleis regelen er skriven.

Fire handhevingpunkt og kva kvart av dei går glipp av

Fire stader kan handheve ei blokkering, og kvart av dei sviktar ulikt. Les lista som eit dekkingskart, ikkje som ei rangering.

• hosts-fil eller lokal resolvar: verkar offline og under kvar einaste tunnel, men vert omgått av ein innebygd resolvar eller ei hardkoda adresse.
• DNS-filtrering ved VPN-gatewayen: dekkjer klientar som brukar den påskunda resolvaren, og går glipp av klientar som overstyrer DNS.
• Gateway-utgangsreglar etter adresse eller SNI: uavhengige av DNS-en til klienten, men blinde for namn dei ikkje kan lese og adresser dei ikkje har lært.
• Styrt nettlesar- eller einingapolitikk: sterk på styrt maskinvare, fråverande på personlege einingar.

Ingen av desse er ei tryggingsgrense mot ein bestemd brukar på ei ustyrt eining. Dei er politikkkontrollar, og ei ærleg skildring seier kva trafikk kvar av dei faktisk dekkjer.

Vel laget som passar til føremålet: heimeleg komfort høyrer til på eininga, og ein organisasjonsregel høyrer til ved gatewayen.

Test båe tilstandane før du kallar det ferdig

Køyr dei same tre kommandoane med VPN-en tilkopla og fråkopla: getent ahosts for å sjå svaret til resolvaren, nslookup for å sjå kva førespurnaden returnerer, og curl -I mot nettstaden for å sjå om ei tilkopling framleis vert fullført. Viss den første returnerer loopback medan den tredje koplar til den verkelege adressa, har noko omgått resolvaren, og hosts-oppføringa er ikkje den kontrollen du trur.

På rutaren, les filterteljarane før og etter ein førespurnad. Ein teljar som aldri flyttar seg tyder at trafikken aldri nådde filteret, og det er eit rutesvar, ikkje eit regelsvar.

Skriv ned resultatet saman med topologien, for den neste VPN-endringa flyttar ruta igjen.