Pi-hole nuk bllokon reklamat pas lidhjes së VPN-së: pesë kontrolle

Reklamat ende shfaqen në një klient, Pi-hole raporton se është i shëndetshëm dhe tuneli është aktiv, prandaj instinkti është të kalosh trafikun e atij klienti përmes Pi. Ky është kthesa e gabuar. Filtrimi kërkon pyetjet, jo paketat, dhe një klient pyetjet e të cilit shkojnë te zgjidhësi i ofruesit mbetet i pafiltruar kudo që rrjedh trafiku i tij. Kaloni nëpër këtë listë me radhë dhe ndaloni në hapin e parë që dështon, sepse një hap i mëvonshëm nuk mund të thotë asgjë ndërsa një i mëparshëm është i prishur.

1. Lexoni zgjidhësin që klienti përdor në të vërtetë

Pyetni klientin, jo ruterin. Në Linux resolvectl status shtyp serverët DNS për çdo lidhje dhe cila lidhje fiton; /etc/resolv.conf vetëm është zakonisht një stub që tregon te 127.0.0.53. Në Windows ipconfig /all liston serverët e dhënë nga DHCP për çdo përshtatës, dhe në macOS scutil --dns tregon të njëjtën gjë sipas fushës. Nëse përgjigja nuk është adresa e Pi-hole, keni një problem caktimi dhe hapi 2 është vendi ku ndodhet.

Dy gjëra mposhtin zgjidhësin e sistemit edhe kur është vendosur saktë. Shfletuesit me DNS të tyre të sigurt (opsioni “Use secure DNS” i Chrome, network.trr.mode i Firefox) dërgojnë pyetje përmes HTTPS te një zgjidhës publik dhe nuk hapin kurrë portën 53. Dhe një klient VPN në vetë klientin mund të instalojë një server DNS në ndërfaqen e tunelit të tij me një domen rrugëtimi ~., gjë që e bën atë lidhje autoritative për çdo emër.

Testoni rrugën që marrin aplikacionet, jo rrugën që merr një mjet korrigjimi. resolvectl query example.com tregon cila lidhje u përgjigj, dhe getent hosts example.com kalon në të njëjtën rrugë NSS si një aplikacion; në macOS dscacheutil -q host -a name example.com lexon zgjidhësit sipas fushës që liston scutil --dns. Një dig i zhveshur nuk e bën këtë: lexon /etc/resolv.conf dhe anashkalon zgjedhjen sipas lidhjes, prandaj mund të përgjigjet nga Pi-hole ndërsa çdo aplikacion përdor zgjidhësin e shtyrë, dhe ky është pikërisht dështimi për të cilin ekziston kjo listë. Mbani dig @192.168.1.53 për të testuar një server të caktuar.

2. Konfirmoni kush e shpërndan përgjigjen

Caktimi vjen nga çdo gjë që i përgjigjet DHCP. Në dnsmasq është një rresht i vetëm, dhcp-option=6,192.168.1.53; në ndërfaqen web të një ruteri është fusha DNS në seksionin DHCP të LAN-it. Klientët duhet të rinovojnë para se ta shohin. Një pajisje që punon prej ditësh ende mban qiranë e vjetër, dhe një pajisje me zgjidhës të shkruar me dorë e mban përgjithmonë. Rinovoni në një klient testimi në vend që të supozoni përhapjen.

IPv6 është gjysma që harrohet. Njoftimet e ruterit mund të mbajnë serverin e tyre DNS (RDNSS), dhe në OpenWrt ky është opsioni ra_dns i odhcpd; një klient që preferon IPv6 përdor atë server ndërsa opsioni DHCPv4 që sapo vendosët mbetet i papërdorur. Nëse nuk jeni gati të shërbeni DNS përmes IPv6, fshini vetëm njoftimin DNS: ra_dns në odhcpd, ose opsionin RDNSS në çdo gjë që i përgjigjet njoftimeve të ruterit. Fikja e të gjithë njoftimit heq edhe adresimin IPv6 nga LAN-i, çka është një ndryshim shumë më i madh se ai që kishit ndërmend, ndërsa fshirja vetëm e opsionit DNS e mban adresimin të paprekur dhe e bën RDNSS-in që mungon të dukshëm në një kapje paketash.

3. Provoni që pyetja arrin në Pi-hole

Një pyetje nga Pi nuk provon asgjë për rrugën e rrjetit. Ekzekutoni atë nga klienti dhe lexoni kodin e përgjigjes:

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

Skadimi i kohës tregon filtrim ose një rrugë; REFUSED tregon një rregull aksesi; SERVFAIL tregon zgjidhësin e sipërm pas Pi-hole; një përgjigje e saktë që nuk shfaqet kurrë në regjistrin e pyetjeve do të thotë që klienti pyeti diçka tjetër. Kontrolloni UDP dhe TCP 53, sepse përgjigjet e mëdha dhe disa zgjidhës bien përsëri në TCP, dhe publikoni të dyja kur Pi-hole punon në një kontejner. Një hartë që mbulon vetëm UDP prodhon dështime të ndërprera që duken si humbje paketash.

Pastaj mënyra e dëgjimit e Pi-hole vendos nëse përgjigjet fare. Në mënyrën vetëm lokale dnsmasq i injoron pyetjet nga burimet që nuk janë në një nënrrjet të lidhur drejtpërdrejt, dhe pikërisht kështu duket një klient pas një ruteri tjetër ose që vjen përmes një tuneli: klientit i skadon koha dhe pyetja nuk arrin kurrë në regjistër. Një pyetje që gjithsesi shfaqet si REFUSED është refuzuar nga një listë aksesi ose një rregull muri zjarri. Lejimi i të gjitha burimeve është rregullimi i zakonshëm, së bashku me një rregull muri zjarri që kufizon portën 53 në nënrrjetet tuaja.

4. Kontrolloni nëse tuneli e zëvendësoi apo e gëlltiti përgjigjen

Ky është rasti ku fshihen të dy simptomat. Kur ruteri është vetë një klient VPN, një opsion DNS i shtyrë mund të anashkalojë cilësimin e LAN-it në momentin kur tuneli ngrihet: serverët OpenVPN shtyjnë dhcp-option DNS, dhe profilet WireGuard mbajnë hyrjen e tyre DNS. Lexoni zgjidhësin efektiv të ruterit me tunelin aktiv, jo përpara tij, dhe injoroni atë që pretendon faqja e LAN-it.

Dëmtimi tjetër është arritshmëria, jo zëvendësimi. Nëse prefikset e lejuara të tunelit përfshijnë nënrrjetin tuaj LAN, ruteri ka një rrugë që i dërgon pyetjet për 192.168.1.53 brenda tunelit, dhe ana tjetër nuk ka rrugë kthimi: pyetjeve u skadon koha edhe pse tuneli është i shëndetshëm. E kundërta ndodh kur Pi-hole ndodhet në një nënrrjet që tuneli nuk e mbart. Krahasoni adresën me prefikset e lejuara të tunelit dhe tabelën e rrugëve të ruterit përpara se të prekni përsëri DNS.

Zgjidhni një rregullim, jo të dyja. Ose mbani tunelin larg DNS-së — me pull-filter ignore “dhcp-option DNS” në OpenVPN dhe pa prefiks LAN në AllowedIPs në WireGuard —, ose pranoni zgjidhësin e shtyrë dhe hiqni dorë nga filtrimi lokal për klientët pas atij ruteri. Çfarëdo që të zgjidhni, shkruajeni pranë profilit, sepse personi tjetër që do ta modifikojë do ta kthejë ndryshe vendimin pa dashje.

5. Përsëritni testin pas një rilidhjeje

Bëni një pyetje nga një klient, konfirmoni që ai klient shfaqet në regjistrin e Pi-hole, pastaj zgjidhni një domen që duhet të bllokohet dhe kontrolloni që merrni përgjigjen e bllokimit në vend të asaj reale. Rilidhni tunelin dhe ekzekutoni të njëjtat dy pyetje, sepse një cilësim zgjidhësi që zgjat vetëm deri në lidhjen tjetër është rezultati i zakonshëm i një rregullimi të aplikuar në shtresën e gabuar.

Lëreni një rrugë dytësore zgjidhësi që nuk varet nga tuneli, që një ndërprerje e Pi-hole të degradohet në shfletim pa filtrim në vend të asnjë shfletimi. Mbani vlerat e mëparshme të DHCP dhe të zgjidhësit derisa testi të kalojë dy herë; një ndryshim që prish internetin e shtëpisë në darkë është shumë më i vështirë për t'u korrigjuar sesa një që mund ta kthesh brenda një minute.