hosts-lêer teen router-filter: ’n werf oor ’n VPN blokkeer

’n Inskrywing in die hosts-lêer en ’n router-filter blokkeer dieselfde werf om heeltemal verskillende redes, en daarom werk die een onder ’n VPN en stop die ander stil. Die hosts-lêer beantwoord ’n naam voordat enige pakkie die masjien verlaat. Die router-filter ondersoek verkeer wat dit kruis. Plaas ’n tonnel tussen daardie twee punte en die tweede een verloor sy sig, terwyl die eerste een niks merk nie.

Waar die naam opgelos word, bepaal alles

Elke blok begin met ’n vraag: wie maak die naam in ’n adres om? Op ’n gewone rekenaar is die antwoord die stelsel-oplosser, wat sy opgestelde volgorde volg en gewoonlik die hosts-lêer lees voordat dit DNS navraag. Op ’n gefiltreerde netwerk is die antwoord dalk die router, wat die navraag net sien as die kliënt dit onbeskermd deur die router stuur. Verander die pad en jy verander wie mag antwoord.

’n VPN doen hier twee dinge op een slag: dit verskuif die verstekroete, en dit kan sy eie DNS-bediener stoot. Enige van die twee veranderinge is genoeg om naamoplossing weg te beweeg van die toestel wat die blok afgedwing het.

Dit is die meganisme agter die bekende klag dat die filter werk tot die VPN koppel.

’n hosts-inskrywing antwoord voordat die tonnel bestaan

’n Reël soos 127.0.0.1 www.example.com word deur die plaaslike oplosser gelees, so die antwoord word op die masjien geproduseer sonder dat ’n netwerk betrokke is. Koppel ’n tonnel, verander die DNS-bediener, wissel netwerke: die inskrywing gee steeds loopback terug. Daarom is ’n hosts-blok die enigste van die twee wat nie deur die plek waar die VPN eindig, beïnvloed word nie.

Sy blinde kolle is ewe plaaslik. ’n Program wat sy eie oplosser insluit, DNS oor HTTPS praat of aan ’n letterlike adres koppel, vra die stelsel nooit, so die inskrywing word nie geraadpleeg nie. ’n Gekasde adres binne ’n lopende proses het dieselfde effek totdat daardie proses herbegin.

Bevestig die antwoord met getent ahosts op Linux of Resolve-DnsName op Windows eerder as om ’n blaaier-oortjie te vertrou.

’n Router-filter sien net wat dit kruis

’n Inhoud- of URL-filter op ’n huisrouter pas name en versoeke aan wat dit in leesbare vorm kruis. Wanneer die kliënt ’n geënkripteerde tonnel na ’n bediener elders bou, sien die router ’n enkele vloei na daardie bediener en niks binne dit nie. Die filter het geen naam om aan te pas nie, so dit laat die verkeer deur, wat lyk asof die filter gefaal het eerder as of dit omseil is.

Die topologie wat wel werk, is die ander een: die router hou die tonnel self, dekripteer by die eindpunt en pas die filter daar toe. In daardie ontwerp sit die filter waar die gewone teks verskyn.

As die tonnel op die skootrekenaar eindig, is die router per definisie buite die beskermde pad, ongeag hoe die reël geskryf is.

Vier handhawingspunte en wat elkeen mis

Vier plekke kan ’n blok handhaaf, en elkeen faal anders. Lees die lys as ’n dekkaart eerder as ’n rangorde.

• hosts-lêer of plaaslike oplosser: werk vanlyn en onder enige tonnel, maar word omseil deur ’n ingesluitde oplosser of ’n hardgekodeerde adres.
• DNS-filtering by die VPN-deurgang: dek kliënte wat die gestote oplosser gebruik, en mis kliënte wat DNS oorheers.
• Deurgangs-uitgangsreëls per adres of SNI: onafhanklik van die kliënt se DNS, maar blind vir name wat dit nie kan lees nie en vir adresse wat dit nie geleer het nie.
• Bestuurde blaaier- of toestelbeleid: sterk op bestuurde hardeware, afwesig op persoonlike toestelle.

Nie een van hierdie is ’n sekuriteitsgrens teen ’n vasberade gebruiker op ’n onbestuurde toestel nie. Hulle is beleidskontroles, en ’n eerlike beskrywing sê watter verkeer elkeen werklik dek.

Kies die laag wat by die bedoeling pas: huishoudelike gerief hoort op die toestel, en ’n organisasie-reël hoort by die deurgang.

Toets albei toestande voordat jy dit klaar noem

Voer dieselfde drie opdragte uit met die VPN gekoppel en ontkoppeld: getent ahosts om die oplosser se antwoord te sien, nslookup om te sien wat die navraag teruggee, en curl -I teen die werf om te sien of ’n verbinding steeds voltooi. As die eerste loopback teruggee terwyl die derde aan die regte adres koppel, het iets die oplosser omseil en die hosts-inskrywing is nie die beheer wat jy dink dit is nie.

Lees op die router die filter-tellers voor en ná ’n versoek. ’n Teller wat nooit beweeg nie, beteken die verkeer het nooit die filter bereik nie, wat ’n roetantwoord is eerder as ’n reëlantwoord.

Skryf die resultaat saam met die topologie neer, want die volgende VPN-verandering sal die pad weer verskuif.