VPN-i DNS-filter: nimede blokeerimine ei blokeeri reklaame

Üks dnsmasq-i rida võib nimele vastata NXDOMAIN-iga ja see ongi kogu mehhanism. See ei loe kunagi HTML-i, ei uuri päringu teed ega näe, mida rakendus teeb juba avatud ühendusega. Seetõttu on selle võrdlemine brauserilaiendiga kahe erineva töö võrdlemine. Üks otsustab, kas nimi lahendatakse; teine otsustab, mis juhtub pärast seda.

Mida nimefilter tegelikult kontrollib

Valik address=/metrics.example/, mille järel viimase kaldkriipsu järel pole midagi, paneb lahendaja selle nime ja selle alamdomeenide jaoks tagastama NXDOMAIN-i. Aadressi tühjaks jätmine on oluline osa: nii ei saadeta kliente seostamata asendusserverisse ega esitata loopback-aadressi tegeliku sihtkohana. dnsmasq-i käsiraamat kirjeldab seda vormi eitava vastusena, mitte ümbersuunamisena.

Kõik, mida reegel teha saab, tuleneb sellest ühest otsusest. Klient, kes küsib seda lahendajat, saab eitava vastuse; klient, kes küsib teist lahendajat, saab selle, mida too lahendaja ütleb. Filter ei tea midagi teest, päringustringist ega kontost, mida rakendus oleks kasutanud.

See detailsus loeb, sest üks hostinimi teenindab sageli mitut eesmärki. Sisselogimispunktid, pildid ja jälgimine võivad jagada domeeni ning reegel, mis eemaldab kogu nime, võib eemaldada ka töövoo. Nime tasandil poliitika peab selle kompromissi vastu võtma või valima kitsamad nimed.

Mille poolest kliendipoolne blokeerija erineb

Brauserilaiend näeb päringut enne, kui see väljub, seega saab see sobitada URL-i teed, tühistada konkreetse päringu ja peita elemendi, mis oleks tulemuse kuvanud. See saab lubada example.com/article, samal ajal keeldudes example.com/ads/, mida ükski DNS-vastus väljendada ei suuda. See tee tasandi vaade on võime, mida lahendajal lihtsalt ei ole. Seetõttu käitub ühe tööriista jaoks ehitatud filtriloend teises harva samamoodi.

Hind on ulatus. See kaitse elab ühes brauseris, ühes profiilis, ühes seadmes ja kaob, kui kasutaja läheb üle teisele rakendusele. Lüüsile seatud DNS-filter katab iga seadme, mis kasutab lüüsi lahendajat, ka seadmed, kuhu ei saa ühtegi laiendit paigaldada.

Kumbki lahendus ei ole iseenesest täielik. DNS-filter ei saa eemaldada identifikaatorit, mille leht on juba saatnud, ja brauserilaiend ei saa kaitsta rakendust, mis seda kunagi ei laadi.

Lahendaja tee otsustab, kas midagi sellest üldse kehtib

VPN võib DNS-serverit reklaamida ja ikkagi mitte saada iga päringut. Krüpteeritud DNS-iga seadistatud brauser, oma lahendajaga rakendus või võrguteel olev seade, mis lüüsi välistab, vaatavad kõik mujale. Mobiilplatvormid pakuvad üha sagedamini privaatse DNS-i seadet, mis vaikselt tühistab selle, mida tunnel soovitab.

Seega testige teed, mitte poliitikat. Küsige kavandatud lahendajalt otse lüüsist, seejärel küsige seda kliendist ja võrrelge, ning seejärel jälgige, kas nimi, mis peaks blokeeritud olema, tegelikult rakenduses, mida kasutaja käitab, ebaõnnestub.

Vahemällu salvestatud vastused ja avatud soklid teevad selle müra rohkeks. Leht, mis on oma ressursid juba laadinud, töötab ka pärast reegli muutmist edasi, seega on värske ühendus parem test kui vana vahelehe uuesti laadimine.

Testige mõlemat suunda, enne kui tulemust väidate

Kasutage meelega blokeeritud dokumentatsiooninime, lubatud avalikku nime ja privaatset nime, mida teenus vajab:

$ dig +short metrics.example @10.40.0.53
$ dig +short example.com @10.40.0.53
$ dig +short intranet.corp.internal @10.40.0.53

Tühi vastus blokeeritud nimele, tavaline aadress avalikule ja privaatne aadress sisemisele näitavad koos, et filtreerimine, ülesvoolu lahendamine ja kohalikud kirjed kõik töötavad. Kui kõik kolm ebaõnnestuvad, on teil tegemist ülesvoolu või kuulaja probleemiga, mitte filtriga.

Hoidke väidet kitsana kõiges, mida sisemiselt avaldate. See on domeenide filtreerimine lahendajal, mitte sisu kontroll, mitte teede filtreerimine ja mitte lubadus, et kedagi ei jälgita. Märkige reeglite kõrvale poliitika omanik, eranditee ja päringute säilitamise aeg, sest filtril, mis logib iga otsingu, on oma privaatsuskulu.