hosts-fail ruuteri filtri vastu: saidi blokeerimine VPN-i kaudu

Kirje hosts-failis ja ruuteri filter blokeerivad sama saiti täiesti erinevatel põhjustel, mistõttu üks töötab VPN-i all edasi ja teine lakkab vaikselt. hosts-fail vastab nimele enne, kui ükski pakett masinast lahkub. Ruuteri filter uurib liiklust, mis seda läbib. Pane nende kahe punkti vahele tunnel ja teine kaotab oma vaate, samal ajal kui esimene ei märka midagi.

Kus nimi lahendatakse, otsustab kõik

Iga blokeering algab küsimusega: kes muudab nime aadressiks? Tavalisel töölauaarvutil vastab süsteemi resolver, mis läbib oma seadistatud järjekorra ja loeb tavaliselt hosts-faili enne DNS-i küsitlemist. Filtreeritud võrgus võib vastata ruuter, mis näeb päringut ainult siis, kui klient saadab selle sealt kaitsetult läbi. Muuda teekonda ja muudad, kes tohib vastata.

VPN teeb siin kaks asja korraga: see liigutab vaiketeekonda ja võib peale suruda oma DNS-serveri. Kumbki muudatus on piisav, et nime lahendamine eemaldada seadmest, mis blokeeringut rakendas.

See on mehhanism tuttava kaebuse taga, et filter töötab, kuni VPN ühendub.

hosts-kirje vastab enne, kui tunnel olemas on

Sellist rida nagu 127.0.0.1 www.example.com loeb kohalik resolver, seega tekib vastus masinas ilma võrgu osaluseta. Ühenda tunnel, muuda DNS-serverit, vaheta võrke: kirje tagastab ikka loopbacki. Seetõttu on hosts-blokeering kahest ainus, mida ei mõjuta see, kus VPN lõpeb.

Selle pimealad on sama kohalikud. Rakendus, mis toob kaasa oma resolveri, räägib DNS over HTTPS-i või ühendub otsese aadressiga, ei küsi kunagi süsteemilt, seega kirjet ei kasutata. Käimasolevas protsessis vahemällu salvestatud aadressil on sama mõju, kuni see protsess taaskäivitub.

Kinnita vastus Linuxis käsuga getent ahosts või Windowsis käsuga Resolve-DnsName, mitte ei usalda brauseri vahekaarti.

Ruuteri filter näeb ainult seda, mis seda läbib

Sisu- või URL-filter kodu-ruuteril sobitab nimesid ja päringuid, mis läbivad seda loetaval kujul. Kui klient ehitab krüpteeritud tunneli serverini mujal, näeb ruuter üht voogu selle serverini ja mitte midagi selle sees. Filtril pole nime, millega sobitada, seega laseb see liikluse läbi, ja see näib nii, nagu filter oleks ebaõnnestunud, mitte nagu see oleks mööda mindud.

Toimiv topoloogia on teine: ruuter hoiab tunnelit ise, dekrüpteerib lõpp-punktis ja rakendab seal filtri. Selles lahenduses istub filter seal, kus paistab selge tekst.

Kui tunnel lõpeb sülearvutis, on ruuter definitsiooni järgi kaitstud teekonnast väljas, ükskõik kuidas reegel on kirjutatud.

Neli jõustamispunkti ja mida igaüks mööda laseb

Blokeeringut saavad jõustada neli kohta ja igaüks ebaõnnestub erinevalt. Lugege loendit kaetuskaardina, mitte pingereana.

• hosts-fail või kohalik resolver: töötab võrguühenduseta ja iga tunneli all, kuid seda mööda minnakse kaasatud resolveri või kõvakodeeritud aadressiga.
• DNS-filtreerimine VPN-lüüsil: katab kliendid, kes kasutavad pealesurutud resolverit, ja jätab vahele kliendid, kes DNS-ist mööda lähevad.
• Lüüsi väljumisreeglid aadressi või SNI järgi: sõltumatud kliendi DNS-ist, kuid pimedad nimede suhtes, mida see lugeda ei saa, ja aadresside suhtes, mida see õppinud pole.
• Hallatav brauseri- või seadmepoliitika: tugev hallataval riistvaral, puudub isiklikel seadmetel.

Ükski neist ei ole turbepiir kindlameelse kasutaja vastu haldamata seadmel. Need on poliitikakontrollid ja aus kirjeldus ütleb, millist liiklust igaüks tegelikult katab.

Valige kiht, mis vastab kavatsusele: kodune mugavus kuulub seadmele ja organisatsiooni reegel kuulub lüüsile.

Testige mõlemat olekut enne, kui ütlete, et see on valmis

Käivitage samad kolm käsku VPN-iga ühendatud ja ühendamata olekus: getent ahosts resolveri vastuse nägemiseks, nslookup päringu vastuse nägemiseks ja curl -I saidi vastu, et näha, kas ühendus ikka lõpuni jõuab. Kui esimene tagastab loopbacki, aga kolmas ühendub päris aadressiga, on miski resolverist mööda läinud ja hosts-kirje pole see kontroll, mida te arvate.

Ruuteril lugege filtriloendureid enne päringut ja pärast seda. Loendur, mis kunagi ei liigu, tähendab, et liiklus ei jõudnudki filtrini, ja see on marsruutimise vastus, mitte reegli vastus.

Kirjutage tulemus topoloogia juurde, sest järgmine VPN-muudatus liigutab teekonda jälle.