Pi-hole nebloķē reklāmas pēc VPN pievienošanas: piecas pārbaudes

Klientā joprojām parādās reklāmas, Pi-hole ziņo, ka ir vesels, un tunelis ir aktīvs, tāpēc instinkts ir virzīt šī klienta datplūsmu caur Pi. Tas ir nepareizais pagrieziens. Filtrēšanai vajadzīgi jautājumi, nevis paketes, un klients, kura vaicājumi dodas pie pakalpojumu sniedzēja risinātāja, paliek nefiltrēts neatkarīgi no tā, kur plūst viņa datplūsma. Iziet šo sarakstu secībā un apstājies pie pirmā soļa, kas neizdodas, jo vēlāks solis neko nevar pateikt, kamēr iepriekšējais ir salauzts.

1. Izlasi risinātāju, ko klients patiešām izmanto

Jautā klientam, nevis maršrutētājam. Linux resolvectl status izdrukā DNS serverus pa saitēm un to, kura saite uzvar; /etc/resolv.conf pats par sevi parasti ir stub, kas norāda uz 127.0.0.53. Windows ipconfig /all uzskaita DHCP nodrošinātos serverus pa adapteriem, bet macOS scutil --dns rāda to pašu pa tvērumiem. Ja atbilde nav Pi-hole adrese, tev ir piešķiršanas problēma, un solis 2 ir vieta, kur tā atrodas.

Divas lietas pārspēj sistēmas risinātāju arī tad, kad tas ir pareizi iestatīts. Pārlūki ar savu drošo DNS (Chrome opcija “Use secure DNS”, Firefox network.trr.mode) sūta vaicājumus pa HTTPS uz publisku risinātāju un nekad neatver portu 53. Un VPN klients pašā klientā var instalēt DNS serveri savā tuneļa saskarnē ar ~. maršrutēšanas domēnu, kas padara šo saiti autoritatīvu katram vārdam.

Pārbaudi ceļu, pa kuru iet lietotnes, nevis ceļu, pa kuru iet atkļūdošanas rīks. resolvectl query example.com parāda, kura saite atbildēja, un getent hosts example.com iet pa to pašu NSS ceļu kā lietotne; macOS dscacheutil -q host -a name example.com lasa tvēruma risinātājus, ko uzskaita scutil --dns. Kails dig to nedara: tas lasa /etc/resolv.conf un izlaiž izvēli pa saiti, tāpēc tas var atbildēt no Pi-hole, kamēr katra lietotne izmanto uzspiesto risinātāju, un tas ir tieši tas bojājums, kuram šis saraksts pastāv. Paturi dig @192.168.1.53 viena konkrēta servera pārbaudei.

2. Apstiprini, kas izdala atbildi

Piešķiršana nāk no tā, kas atbild uz DHCP. dnsmasq tas ir viena rinda, dhcp-option=6,192.168.1.53; maršrutētāja tīmekļa saskarnē tas ir DNS lauks LAN DHCP sadaļā. Klientiem jāatjauno, pirms tie to redz. Ierīce, kas darbojas jau dienas, joprojām tur veco nomu, un ierīce ar ar roku ierakstītu risinātāju tur to mūžīgi. Atjauno testa klientā, nevis pieņem izplatīšanos.

IPv6 ir tā puse, kas paliek nepamanīta. Maršrutētāja paziņojumi var nest savu DNS serveri (RDNSS), un OpenWrt tas ir odhcpd opcija ra_dns; klients, kas dod priekšroku IPv6, izmanto šo serveri, kamēr tikko iestatītā DHCPv4 opcija paliek neizmantota. Ja neesi gatavs apkalpot DNS ar IPv6, notīri tikai DNS paziņojumu: ra_dns odhcpd vai RDNSS opciju tajā, kas atbild uz maršrutētāja paziņojumiem. Izslēdzot visu paziņojumu, no LAN tiek noņemta arī IPv6 adresācija, kas ir daudz lielākas izmaiņas nekā biji iecerējis, turpretī tikai DNS opcijas notīrīšana saglabā adresāciju neskartu un padara trūkstošo RDNSS redzamu pakešu uztveršanā.

3. Pierādi, ka vaicājums sasniedz Pi-hole

Vaicājums no Pi neko nepierāda par tīkla ceļu. Palaid to no klienta un nolasi atbildes kodu:

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

Taimauts norāda uz filtrēšanu vai maršrutu; REFUSED norāda uz piekļuves noteikumu; SERVFAIL norāda uz augšupējo risinātāju aiz Pi-hole; pareiza atbilde, kas nekad neparādās vaicājumu žurnālā, nozīmē, ka klients jautāja ko citu. Pārbaudi UDP un TCP 53, jo lielas atbildes un daži risinātāji atkrīt atpakaļ uz TCP, un publicē abus, kad Pi-hole darbojas konteinerā. Kartējums, kas aptver tikai UDP, rada periodiskas kļūmes, kas izskatās kā pakešu zudums.

Pēc tam Pi-hole klausīšanās režīms izlemj, vai tas vispār atbild. Tikai vietējā režīmā dnsmasq ignorē vaicājumus no avotiem, kas nav tieši pievienotā apakštīklā, un tieši tā izskatās klients aiz cita maršrutētāja vai tāds, kas nāk pa tuneli: klientam beidzas laiks, un vaicājums nekad nesasniedz žurnālu. Vaicājums, kas tomēr parādās kā REFUSED, tika noraidīts piekļuves sarakstā vai ugunsmūra noteikumā. Atļaut visus avotus ir ierastais labojums kopā ar ugunsmūra noteikumu, kas ierobežo portu 53 ar taviem pašu apakštīkliem.

4. Pārbaudi, vai tunelis atbildi aizstāja vai aprīja

Šis ir gadījums, kurā slēpjas abi simptomi. Kad maršrutētājs pats ir VPN klients, uzspiestā DNS opcija var atcelt LAN iestatījumu tajā brīdī, kad tunelis paceļas: OpenVPN serveri uzspiež dhcp-option DNS, un WireGuard profili nes savu DNS ierakstu. Lasi maršrutētāja faktisko risinātāju ar paceltu tuneli, nevis pirms tam, un ignorē to, ko apgalvo LAN lapa.

Otrs defekts ir sasniedzamība, nevis aizstāšana. Ja tuneļa atļautie prefiksi ietver tavu LAN apakštīklu, maršrutētājam ir maršruts, kas vaicājumus par 192.168.1.53 sūta tunelī, un pretējai pusei nav atgriešanās maršruta: vaicājumiem beidzas laiks, lai gan tunelis ir vesels. Pretējais notiek, kad Pi-hole atrodas apakštīklā, ko tunelis nepārvadā. Salīdzini adresi ar tuneļa atļautajiem prefiksiem un maršrutētāja maršrutu tabulu, pirms vēlreiz pieskaras DNS.

Izvēlies vienu labojumu, nevis abus. Vai nu turi tuneli tālu no DNS — ar pull-filter ignore “dhcp-option DNS” OpenVPN un bez LAN prefiksa AllowedIPs WireGuard —, vai pieņem uzspiesto risinātāju un atsakies no vietējās filtrēšanas klientiem aiz šī maršrutētāja. Ko vien izvēlies, pieraksti to blakus profilam, jo nākamais cilvēks, kas to rediģēs, citādi nejauši apvērsīs lēmumu.

5. Atkārto testu pēc atkārtotas pievienošanas

Vaicā no klienta, apstiprini, ka šis klients parādās Pi-hole žurnālā, pēc tam atrisini domēnu, kas būtu jābloķē, un pārbaudi, vai saņem bloķēšanas atbildi, nevis īsto. Atkārtoti pievieno tuneli un izpildi tos pašus divus vaicājumus, jo risinātāja iestatījums, kas saglabājas tikai līdz nākamajai pievienošanai, ir ierasts labojuma rezultāts, kas piemērots nepareizajā slānī.

Atstāj sekundāru risinātāja ceļu, kas nav atkarīgs no tuneļa, lai Pi-hole pārtraukums degradētos uz nefiltrētu pārlūkošanu, nevis uz pārlūkošanas trūkumu. Saglabā iepriekšējās DHCP un risinātāja vērtības, līdz tests iztur divas reizes; izmaiņas, kas vakariņu laikā salauž mājsaimniecības internetu, ir daudz grūtāk atkļūdojamas nekā tādas, ko vari atsaukt minūtē.