DNS filter v VPN: blokiranje imen ne blokira oglasov

Ena vrstica dnsmasq lahko odgovori na ime s kodo NXDOMAIN in to je celoten mehanizem. Nikoli ne bere HTML, nikoli ne pregleda poti zahteve in nikoli ne vidi, kaj aplikacija počne s povezavo, ki jo je že odprla. Primerjava z razširitvijo brskalnika je zato primerjava dveh različnih opravil. Eno odloča, ali se ime razreši; drugo odloča, kaj se zgodi potem.

Kaj filter imen dejansko nadzoruje

Možnost address=/metrics.example/, brez česar koli za zadnjo poševnico, povzroči, da razreševalnik vrne NXDOMAIN za to ime in njegove poddomene. Praznjenje naslova je pomembni del: prepreči pošiljanje odjemalcev na nepovezan nadomestni strežnik ali pretvarjanje, da je naslov loopback pravi cilj. Priročnik dnsmasq to obliko opisuje kot negativen odgovor in ne kot preusmeritev.

Vse, kar pravilo zmore, izhaja iz te ene odločitve. Odjemalec, ki vpraša ta razreševalnik, dobi negativen odgovor; odjemalec, ki vpraša drug razreševalnik, dobi tisto, kar ta reče. Filter ne ve, katero pot, katero poizvedbeno niz ali kateri račun bi aplikacija uporabila.

Ta podrobnost je pomembna, ker eno ime gostitelja pogosto služi več namenom. Prijavne točke, slike in sledenje si lahko delijo domeno, pravilo, ki odstrani celotno ime, pa lahko z njim odstrani tudi delovni tok. Politika na ravni imena mora ta kompromis sprejeti ali izbrati ožja imena.

V čem se blokator na strani odjemalca razlikuje

Razširitev brskalnika vidi zahtevo, preden odide, zato lahko ujame pot URL, prekliče določeno zahtevo in skrije element, ki bi prikazal rezultat. Lahko dovoli example.com/article in zavrne example.com/ads/, česar noben odgovor DNS ne more izraziti. Ta pogled na ravni poti je zmožnost, ki je razreševalnik preprosto nima. To je tudi razlog, da se seznam filtrov, zgrajen za eno orodje, v drugem le redko obnaša enako.

Cena je obseg. Ta zaščita živi v enem brskalniku, v enem profilu, na eni napravi in izgine, ko uporabnik preklopi na drugo aplikacijo. DNS filter, nastavljen na prehodu, pokrije vsako napravo, ki uporablja razreševalnik prehoda, tudi naprave, na katere ni mogoče namestiti nobene razširitve.

Nobena ureditev sama po sebi ni popolna. DNS filter ne more odstraniti identifikatorja, ki ga je stran že poslala, razširitev brskalnika pa ne more zaščititi aplikacije, ki je nikoli ne naloži.

Pot razreševalnika odloča, ali se kar koli od tega uporabi

VPN lahko oglašuje strežnik DNS in vseeno ne prejme vsake poizvedbe. Brskalnik z nastavljenim šifriranim DNS, aplikacija z lastnim razreševalnikom ali naprava na omrežni poti, ki izključuje prehod, bodo vsi iskali drugje. Mobilne platforme vse pogosteje ponujajo nastavitev zasebnega DNS, ki tiho preglasi to, kar predlaga tunel.

Zato preizkusite pot in ne politike. Povprašajte predvideni razreševalnik neposredno s prehoda, nato ga povprašajte z odjemalca in primerjajte, zatem pa opazujte, ali ime, ki bi moralo biti blokirano, v aplikaciji, ki jo uporabnik izvaja, res odpove.

Predpomnjeni odgovori in odprti vtičnice naredijo to hrupno. Stran, ki je svoje vire že naložila, bo delovala naprej po spremembi pravila, zato je nova povezava boljši preizkus kot ponovno nalaganje starega zavihka.

Preizkusite obe smeri, preden razglasite rezultat

Uporabite namerno blokirano dokumentacijsko ime, dovoljeno javno ime in zasebno ime, ki ga storitev potrebuje:

$ 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

Prazen odgovor za blokirano ime, običajen naslov za javno in zasebni naslov za notranje skupaj pokažejo, da filtriranje, nadrejeno razreševanje in lokalni zapisi delujejo. Če vse tri odpovedo, gledate težavo z nadrejenim strežnikom ali s poslušalcem in ne s filtrom.

Trditev naj bo ozka v vsem, kar objavite interno. To je filtriranje domen na razreševalniku, ne pregledovanje vsebine, ne filtriranje poti in ne obljuba, da nikogar ne spremljajo. Ob pravilih navedite lastnika politike, pot izjeme in obdobje hrambe poizvedb, ker ima filter, ki beleži vsako iskanje, svoje stroške zasebnosti.