Pi-hole ne blokas reklamojn post kiam la VPN konektiĝas: kvin kontroloj

Reklamoj ankoraŭ aperas ĉe kliento, Pi-hole raportas sin sana, kaj la tunelo estas aktiva, do la instinkto estas sendi la trafikon de tiu kliento tra la Pi. Tio estas la malĝusta turno. Filtrado bezonas la demandojn, ne la pakaĵojn, kaj kliento, kies demandoj iras al la provizanta resolvilo, restas nefiltrita sendepende de tio, kien ĝia trafiko fluas. Trairu ĉi tiun liston laŭ ordo kaj haltu ĉe la unua paŝo, kiu malsukcesas, ĉar posta paŝo povas diri al vi nenion dum pli frua estas rompita.

1. Legu la resolvilon, kiun la kliento fakte uzas

Demandu la klienton, ne la kurieron. En Linux resolvectl status presas la DNS-servilojn laŭligilo kaj kiun ligilon venkas; /etc/resolv.conf sole estas kutime ŝtopilo montranta al 127.0.0.53. En Windows ipconfig /all listigas la DHCP-provizitajn servilojn laŭ adaptilo, kaj en macOS scutil --dns montras la samon laŭskope. Se la respondo ne estas la adreso de Pi-hole, vi havas asignan problemon kaj paŝo 2 estas kie ĝi loĝas.

Dioj venkas la sistemresolvilon eĉ kiam ĝi estas ĝuste agordita. Retumiloj kun propra sekura DNS (la opcio “Use secure DNS” de Chrome, la network.trr.mode de Firefox) sendas demandojn per HTTPS al publika resolvilo kaj neniam malfermas pordon 53. Kaj VPN-kliento sur la kliento mem povas instali DNS-servilon sur sia tunela interfaco kun enkursiga domajno ~., kio igas tiun ligilon aŭtoritata por ĉiu nomo.

Testu la vojon, kiun prenas aplikaĵoj, ne la vojon, kiun prenas sencimiga ilo. resolvectl query example.com montras, kiu ligilo respondis, kaj getent hosts example.com iras tra la sama NSS-vojo kiel aplikaĵo; en macOS dscacheutil -q host -a name example.com legas la skopajn resolvilojn, kiujn scutil --dns listigas. Nuda dig tion ne faras: ĝi legas /etc/resolv.conf kaj preterlasas la elekton laŭligile, do ĝi povas respondi el Pi-hole dum ĉiu aplikaĵo uzas la puŝitan resolvilon, kaj tio estas ĝuste la fiasko, por kiu ekzistas ĉi tiu listo. Konservu dig @192.168.1.53 por testi unu specifan servilon.

2. Konfirmu, kiu disdonas la respondon

La asignado venas de tio, kio respondas al DHCP. Ĉe dnsmasq tio estas unu linio, dhcp-option=6,192.168.1.53; en la reta interfaco de kuriero tio estas la DNS-kampo en la LAN-DHCP-sekcio. Klientoj devas renovigi antaŭ ol vidi ĝin. Aparato, kiu funkcias de tagoj, ankoraŭ tenas la malnovan luon, kaj aparato kun permane tajpita resolvilo tenas ĝin por ĉiam. Renovigu ĉe testa kliento anstataŭ supozi disvastiĝon.

IPv6 estas la duono, kiu estas preterlasata. Kurieraj anoncoj povas porti sian propran DNS-servilon (RDNSS), kaj en OpenWrt tio estas la opcio ra_dns de odhcpd; kliento, kiu preferas IPv6, uzas tiun servilon dum la DHCPv4-opcio, kiun vi ĵus agordis, restas neuzata. Se vi ne pretas servi IPv6-DNS, forigu nur la DNS-anoncon: ra_dns en odhcpd, aŭ la RDNSS-opcion en tio, kio respondas al kurieraj anoncoj. Malŝalti la tutan anoncon forigas ankaŭ IPv6-adresadon el la LAN, kio estas multe pli granda ŝanĝo ol tiu, kiun vi intencis, dum forigi nur la DNS-opcion konservas la adresadon sendifekta kaj igas la mankan RDNSS videbla en paketa kapto.

3. Pruvu, ke la demando atingas Pi-hole

Demando el la Pi pruvas nenion pri la reta vojo. Rulu ĝin el la kliento kaj legu la respondan kodon:

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

Tempo-limigo montras al filtrado aŭ al itinero; REFUSED montras al alira regulo; SERVFAIL montras al la supra resolvilo malantaŭ Pi-hole; ĝusta respondo, kiu neniam aperas en la demanda protokolo, signifas, ke la kliento demandis ion alian. Kontrolu UDP kaj TCP 53, ĉar grandaj respondoj kaj iuj resolviloj falas reen al TCP, kaj publikigu ambaŭ kiam Pi-hole funkcias en ujo. Mapado, kiu kovras nur UDP, produktas intermitajn fiaskojn, kiuj aspektas kiel perdo de pakaĵoj.

Tiam la aŭskulta reĝimo de Pi-hole decidas, ĉu ĝi entute respondas. En reĝimo nur-loka dnsmasq ignoras demandojn el fontoj, kiuj ne estas en rekte konektita subreto, kaj ĝuste tiel aspektas kliento malantaŭ alia kuriero aŭ venanta tra tunelo: la kliento tempolimiĝas kaj la demando neniam atingas la protokolon. Demando, kiu tamen aperas kiel REFUSED, estis rifuzita de alira listo aŭ fajroŝirma regulo. Permesi ĉiujn originojn estas la kutima riparo, kune kun fajroŝirma regulo, kiu limigas pordon 53 al viaj propraj subretoj.

4. Kontrolu, ĉu la tunelo anstataŭigis aŭ englutis la respondon

Tio estas la kazo, en kiu kaŝas sin ambaŭ simptomoj. Kiam la kuriero mem estas VPN-kliento, puŝita DNS-opcio povas superregi la LAN-agordon en la momento, kiam la tunelo leviĝas: OpenVPN-serviloj puŝas dhcp-option DNS, kaj WireGuard-profiloj portas sian propran DNS-enskrivon. Legu la efektivan resolvilon de la kuriero kun la tunelo aktiva, ne antaŭe, kaj ignoru tion, kion asertas la LAN-paĝo.

La alia difekto estas atingeblo, ne anstataŭigo. Se la permesitaj prefiksoj de la tunelo inkluzivas vian LAN-subreton, la kuriero havas itineron, kiu sendas demandojn por 192.168.1.53 en la tunelon, kaj la alia flanko havas neniun itineron reen: demandoj tempolimiĝas kvankam la tunelo estas sana. La malo okazas, kiam Pi-hole sidas en subreto, kiun la tunelo ne portas. Komparu la adreson kun la permesitaj prefiksoj de la tunelo kaj la itinera tabelo de la kuriero antaŭ ol tuŝi DNS denove.

Elektu unu riparon anstataŭ ambaŭ. Aŭ tenu la tunelon for de DNS — kun pull-filter ignore “dhcp-option DNS” en OpenVPN kaj sen LAN-prefikso en AllowedIPs en WireGuard —, aŭ akceptu la puŝitan resolvilon kaj rezignu pri loka filtrado por klientoj malantaŭ tiu kuriero. Kion ajn vi elektos, skribu ĝin apud la profilo, ĉar la sekva persono, kiu redaktos ĝin, alie hazarde renversos la decidon.

5. Ripetu la teston post rekonekto

Demandu el kliento, konfirmu, ke tiu kliento aperas en la protokolo de Pi-hole, poste solvu domajnon, kiu devus esti blokata, kaj kontrolu, ke vi ricevas la blokan respondon anstataŭ la realan. Rekonektu la tunelon kaj rulu la samajn du demandojn, ĉar resolvila agordo, kiu daŭras nur ĝis la sekva rekonekto, estas la kutima rezulto de riparo aplikita en la malĝusta tavolo.

Lasu duarangan resolvilan vojon, kiu ne dependas de la tunelo, por ke paneo de Pi-hole degeneru al nefiltrita retumado anstataŭ al neniu retumado. Konservu la antaŭajn DHCP kaj resolvilajn valorojn ĝis la testoj trapasos dufoje; ŝanĝon, kiu rompas la hejman interreton dum la vespermanĝo, estas multe pli malfacile sencimigi ol unu, kiun vi povas malfari en minuto.