Pi-hole neblokuoja reklamų prisijungus prie VPN: penki patikrinimai

Reklamų blokavimui reikia užklausų, o ne maršrutų. Eikite per priskyrimą, 53 prievadą, IPv6, stumiamą DNS ir tunelio priešdėlius iš eilės ir sustokite ties pirmąja klaida.

Kliente vis dar rodomos reklamos, Pi-hole praneša esąs sveikas, o tunelis veikia, todėl instinktas yra nukreipti to kliento srautą per Pi. Tai klaidingas posūkis. Filtravimui reikia klausimų, o ne paketų, ir klientas, kurio užklausos keliauja pas teikėjo resolverį, lieka nefiltruojamas, kad ir kur tekėtų jo srautas. Eikite per šį sąrašą iš eilės ir sustokite ties pirmuoju žingsniu, kuris nepavyksta, nes vėlesnis žingsnis nieko negali pasakyti, kol ankstesnis sugedęs.

1. Perskaitykite resolverį, kurį klientas iš tikrųjų naudoja

Klauskite kliento, o ne maršrutizatoriaus. Linuxe resolvectl status spausdina DNS serverius pagal ryšį ir kuris ryšys laimi; /etc/resolv.conf vienas paprastai yra stub, nurodantis į 127.0.0.53. Windowsuose ipconfig /all išvardija DHCP suteiktus serverius pagal adapterį, o macOS scutil --dns rodo tą patį pagal sritį. Jei atsakymas ne Pi-hole adresas, turite priskyrimo problemą, o 2 žingsnis yra vieta, kur ji gyvena.

Sisteminį resolverį įveikia du dalykai, net kai jis nustatytas teisingai. Naršyklės su savo saugiu DNS (Chrome parinktis “Use secure DNS”, Firefox network.trr.mode) siunčia užklausas per HTTPS viešajam resolveriui ir niekada neatveria 53 prievado. O VPN klientas pačiame kliente gali įdiegti DNS serverį savo tunelio sąsajoje su ~. maršrutizavimo domenu, todėl ta jungtis tampa įgaliota kiekvienam vardui.

Tikrinkite kelią, kuriuo eina programos, o ne kelią, kuriuo eina derinimo įrankis. resolvectl query example.com parodo, kuri jungtis atsakė, o getent hosts example.com eina tuo pačiu NSS keliu kaip programa; macOS dscacheutil -q host -a name example.com skaito sričių resolverius, kuriuos išvardija scutil --dns. Grynas dig to nedaro: jis skaito /etc/resolv.conf ir praleidžia pasirinkimą pagal jungtį, todėl gali atsakyti iš Pi-hole, nors kiekviena programa naudoja stumiamą resolverį, ir tai yra būtent ta gedimas, kuriam egzistuoja šis sąrašas. Palikite dig @192.168.1.53 vieno konkretaus serverio testavimui.

2. Patvirtinkite, kas dalija atsakymą

Priskyrimas ateina iš to, kas atsako į DHCP. dnsmasq tai viena eilutė, dhcp-option=6,192.168.1.53; maršrutizatoriaus žiniatinklio sąsajoje tai DNS laukas LAN DHCP skyriuje. Klientai turi atnaujinti, kol tai pamatys. Įrenginys, kuris veikia jau dienas, vis dar laiko seną nuomą, o įrenginys su ranka įvestu resolveriu laiko ją amžinai. Atnaujinkite bandomajame kliente, o ne darykite prielaidą apie plitimą.

IPv6 yra ta pusė, kuri praleidžiama. Maršrutizatoriaus skelbimai gali nešti savo DNS serverį (RDNSS), o OpenWrt tai yra odhcpd parinktis ra_dns; klientas, kuris teikia pirmenybę IPv6, naudoja tą serverį, o ką tik nustatyta DHCPv4 parinktis lieka nenaudojama. Jei nesate pasiruošę teikti DNS per IPv6, išvalykite tik DNS skelbimą: ra_dns odhcpd, arba RDNSS parinktį tame, kas atsako į maršrutizatoriaus skelbimus. Išjungus visą skelbimą, iš LAN taip pat pašalinamas IPv6 adresavimas, o tai yra daug didesnis pakeitimas nei numatėte, tuo tarpu išvalius tik DNS parinktį adresavimas lieka nepažeistas ir trūkstamas RDNSS tampa matomas paketų fiksavime.

3. Įrodykite, kad užklausa pasiekia Pi-hole

Užklausa iš Pi nieko neįrodo apie tinklo kelią. Paleiskite ją iš kliento ir perskaitykite atsakymo kodą:

dig @192.168.1.53 example.com
dig @192.168.1.53 doubleclick.net

Skirtasis laikas rodo filtravimą arba maršrutą; REFUSED rodo prieigos taisyklę; SERVFAIL rodo aukštesnį resolverį už Pi-hole; teisingas atsakymas, kuris niekada nepasireiškia užklausų žurnale, reiškia, kad klientas klausė kažko kito. Patikrinkite UDP ir TCP 53, nes dideli atsakymai ir kai kurie resolveriai grįžta prie TCP, ir paskelbkite abu, kai Pi-hole veikia konteineryje. Susiejimas, apimantis tik UDP, sukelia protarpinius gedimus, kurie atrodo kaip paketų praradimas.

Tada Pi-hole klausymosi režimas nusprendžia, ar jis apskritai atsako. Tik vietiniame režime dnsmasq ignoruoja užklausas iš šaltinių, kurie nėra tiesiogiai prijungtame potinkle, ir būtent taip atrodo klientas už kito maršrutizatoriaus arba atvykstantis per tunelį: klientui baigiasi laikas ir užklausa niekada nepasiekia žurnalo. Užklausa, kuri vis dėlto pasirodo kaip REFUSED, buvo atmesta prieigos sąrašo arba ugniasienės taisyklės. Leisti visas kilmes yra įprastas sprendimas kartu su ugniasienės taisykle, ribojančia 53 prievadą jūsų pačių potinkliais.

4. Patikrinkite, ar tunelis pakeitė, ar prarijo atsakymą

Tai atvejis, kuriame slepiasi abu simptomai. Kai maršrutizatorius pats yra VPN klientas, stumiama DNS parinktis gali panaikinti LAN nustatymą tuo metu, kai tunelis pakyla: OpenVPN serveriai stumia dhcp-option DNS, o WireGuard profiliai turi savo DNS įrašą. Skaitykite veiksmingą maršrutizatoriaus resolverį, kai tunelis veikia, o ne prieš tai, ir nekreipkite dėmesio į tai, ką teigia LAN puslapis.

Kitas trūkumas yra pasiekiamumas, o ne pakeitimas. Jei tunelio leidžiami priešdėliai apima jūsų LAN potinklį, maršrutizatorius turi maršrutą, kuris užklausas dėl 192.168.1.53 siunčia į tunelį, o kita pusė neturi maršruto atgal: užklausoms baigiasi laikas, nors tunelis sveikas. Priešingai nutinka, kai Pi-hole yra potinkyje, kurio tunelis neneša. Palyginkite adresą su tunelio leidžiamais priešdėliais ir maršrutizatoriaus maršrutų lentele prieš vėl liesdami DNS.

Pasirinkite vieną sprendimą, o ne abu. Arba laikykite tunelį atokiau nuo DNS — su pull-filter ignore “dhcp-option DNS” OpenVPN ir be LAN priešdėlio AllowedIPs WireGuard —, arba priimkite stumiamą resolverį ir atsisakykite vietinio filtravimo klientams už to maršrutizatoriaus. Kad ir ką pasirinktumėte, užrašykite tai šalia profilio, nes kitas žmogus, kuris jį redaguos, priešingu atveju netyčia apvers sprendimą.

5. Pakartokite testą po pakartotinio prisijungimo

Užklauskite iš kliento, patvirtinkite, kad tas klientas pasirodo Pi-hole žurnale, tada išspręskite domeną, kuris turėtų būti blokuojamas, ir patikrinkite, ar gaunate blokavimo atsakymą, o ne tikrąjį. Vėl prijunkite tunelį ir paleiskite tas pačias dvi užklausas, nes resolverio nustatymas, kuris išlieka tik iki kito prisijungimo, yra įprastas netinkamame sluoksnyje pritaikyto sprendimo rezultatas.

Palikite antrinį resolverio kelią, nepriklausantį nuo tunelio, kad Pi-hole sutrikimas degraduotų į nefiltruotą naršymą, o ne į visišką naršymo nebuvimą. Išsaugokite ankstesnes DHCP ir resolverio reikšmes, kol testas praeis du kartus; pakeitimą, kuris sugriauna namų internetą per vakarienę, daug sunkiau derinti nei tokį, kurį galite atšaukti per minutę.

Susiję straipsniai