Pi-hole не блакуе рэкламу пасля падключэння VPN: пяць праверак

Рэклама ўсё яшчэ паказваецца на кліенце, Pi-hole паведамляе, што ён здаровы, а тунэль узняты, таму інстынкт падказвае накіраваць трафік гэтага кліента праз Pi. Гэта няправільны паварот. Фільтраванне патрабуе пытанняў, а не пакетаў, і кліент, запыты якога ідуць да рэзалвера правайдэра, застаецца нефільтраваным незалежна ад таго, куды ідзе яго трафік. Прайдзіце гэты спіс па парадку і спыніцеся на першым кроку, які не ўдаўся, бо наступны крок нічога вам не скажа, пакуль папярэдні зламаны.

1. Прачытайце рэзалвер, які кліент фактычна выкарыстоўвае

Спытайце кліент, а не роўтар. У Linux resolvectl status друкуе DNS-серверы па кожным інтэрфейсе і тое, які інтэрфейс перамагае; /etc/resolv.conf сам па сабе звычайна з'яўляецца заглушкай, якая паказвае на 127.0.0.53. У Windows ipconfig /all пералічвае серверы, атрыманыя праз DHCP, па кожным адаптары, а ў macOS scutil --dns паказвае тое ж па кожнай вобласці. Калі адказ не адрас Pi-hole, у вас праблема з прызначэннем, і крок 2 — гэта месца, дзе яна знаходзіцца.

Дзве рэчы перамагаюць сістэмны рэзалвер, нават калі ён наладжаны правільна. Браўзеры з уласным бяспечным DNS (у Chrome — “Use secure DNS”, у Firefox — network.trr.mode) адпраўляюць запыты праз HTTPS да публічнага рэзалвера і ніколі не адкрываюць порт 53. А VPN-кліент на самім кліенце можа ўсталяваць DNS-сервер на сваім тунэльным інтэрфейсе з даменам маршрутызацыі ~., што робіць гэты інтэрфейс аўтарытэтным для кожнага імя.

Праверце шлях, якім ідуць праграмы, а не шлях, якім ідзе інструмент адладкі. resolvectl query example.com паказвае, які інтэрфейс адказаў, а getent hosts example.com ідзе праз той жа шлях NSS, што і праграма; у macOS dscacheutil -q host -a name example.com чытае рэзалверы з вобласцю, якія пералічвае scutil --dns. Голы dig гэтага не робіць: ён чытае /etc/resolv.conf і прапускае выбар па інтэрфейсе, таму можа адказаць з Pi-hole, пакуль кожная праграма выкарыстоўвае прасунуты рэзалвер, — і гэта менавіта тая памылка, для якой існуе гэты спіс. Пакіньце dig @192.168.1.53 для праверкі аднаго канкрэтнага сервера.

2. Пацвердзіце, хто выдае адказ

Прызначэнне прыходзіць ад таго, хто адказвае на DHCP. У dnsmasq гэта адзін радок, dhcp-option=6,192.168.1.53; у вэб-інтэрфейсе роўтара гэта поле DNS у раздзеле LAN DHCP. Кліенты павінны аднавіць арэнду, перш чым убачыць гэта. Прылада, якая працуе ўжо некалькі дзён, усё яшчэ трымае старую арэнду, а прылада з рэзалверам, уведзеным уручную, трымае яго вечна. Аднавіце арэнду на тэставым кліенце, а не мяркуйце, што значэнне распаўсюдзілася.

IPv6 — гэта тая палова, якую забываюць. Аб'явы роўтара могуць несці ўласны DNS-сервер (RDNSS), і ў OpenWrt гэта опцыя ra_dns у odhcpd; кліент, які аддае перавагу IPv6, выкарыстоўвае гэты сервер, пакуль опцыя DHCPv4, якую вы толькі што задалі, застаецца незапатрабаванай. Калі вы не гатовыя абслугоўваць DNS па IPv6, ачысціце толькі аб'яву DNS: ra_dns у odhcpd або опцыю RDNSS у тым, што адказвае на аб'явы роўтара. Выключэнне ўсёй аб'явы таксама выдаляе адрасацыю IPv6 з LAN, што з'яўляецца значна большай зменай, чым тая, якую вы мелі на ўвазе, тады як ачыстка толькі опцыі DNS захоўвае адрасацыю нязменнай і робіць адсутны RDNSS бачным у перахопе пакетаў.

3. Дакажыце, што запыт дасягае Pi-hole

Запыт з Pi нічога не даказвае пра сеткавы шлях. Выканайце яго з кліента і прачытайце код адказу:

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

Таймаўт паказвае на фільтраванне або на маршрут; REFUSED — на правіла доступу; SERVFAIL — на вышэйшы рэзалвер за Pi-hole; правільны адказ, які ніколі не з'яўляецца ў журнале запытаў, азначае, што кліент запытаў нешта іншае. Праверце UDP і TCP 53, бо вялікія адказы і некаторыя рэзалверы пераходзяць на TCP, і публікуйце абодва, калі Pi-hole працуе ў кантэйнеры. Адлюстраванне, якое ахоплівае толькі UDP, стварае перарывістыя збоі, якія выглядаюць як страта пакетаў.

Затым рэжым праслухоўвання Pi-hole вырашае, ці адказвае ён наогул. У рэжыме толькі лакальны dnsmasq ігнаруе запыты з крыніц, якія не знаходзяцца ў непасрэдна падключанай падсетцы, — а менавіта так выглядае кліент за іншым роўтарам або той, што прыходзіць праз тунэль: кліент атрымлівае таймаўт, і запыт ніколі не дасягае журнала. Запыт, які ўсё ж з'яўляецца як REFUSED, быў адхілены спісам доступу або правілам міжсеткавага экрана. Дазвол усіх крыніц — звычайнае рашэнне разам з правілам міжсеткавага экрана, якое абмяжоўвае порт 53 вашымі ўласнымі падсеткамі.

4. Праверце, ці тунэль замяніў або праглынуў адказ

Гэта выпадак, у якім хаваюцца абодва сімптомы. Калі роўтар сам з'яўляецца VPN-кліентам, прасунутая опцыя DNS можа перакрыць наладу LAN у момант, калі тунэль узнімаецца: серверы OpenVPN прасоўваюць dhcp-option DNS, а профілі WireGuard нясуць уласны запіс DNS. Чытайце эфектыўны рэзалвер роўтара з узнятым тунэлем, а не да яго, і ігнаруйце тое, што сцвярджае старонка LAN.

Іншая няспраўнасць — гэта дасягальнасць, а не замена. Калі дазволеныя прэфіксы тунэля ўключаюць вашу падсетку LAN, роўтар мае маршрут, які адпраўляе запыты для 192.168.1.53 у тунэль, а ў процілеглага боку няма зваротнага маршруту: запыты атрымліваюць таймаўт, хоць тунэль здаровы. Адваротнае адбываецца, калі Pi-hole знаходзіцца ў падсетцы, якую тунэль не нясе. Параўнайце адрас з дазволенымі прэфіксамі тунэля і табліцай маршрутаў роўтара, перш чым зноў чапаць DNS.

Выберыце адно рашэнне, а не абодва. Або трымайце тунэль далей ад DNS — з pull-filter ignore “dhcp-option DNS” у OpenVPN і без прэфікса LAN у AllowedIPs у WireGuard, — або прыміце прасунуты рэзалвер і адмовіцеся ад лакальнага фільтравання для кліентаў за гэтым роўтарам. Што б вы ні выбралі, запішыце гэта побач з профілем, бо наступны чалавек, які будзе яго рэдагаваць, інакш выпадкова адмяніць рашэнне.

5. Паўтарыце тэст пасля перападключэння

Зрабіце запыт з кліента, пераканайцеся, што гэты кліент з'яўляецца ў журнале Pi-hole, затым развяжыце дамен, які павінен быць заблакаваны, і праверце, што вы атрымліваеце адказ блакавання, а не сапраўдны. Перападключыце тунэль і выканайце тыя ж два запыты, бо налада рэзалвера, якая трымаецца толькі да наступнага перападключэння, — звычайны вынік выпраўлення, ужытага на няправільным узроўні.

Пакіньце другасны шлях рэзалвера, які не залежыць ад тунэля, каб збой Pi-hole прыводзіў да нефільтраванага аглядання, а не да поўнай адсутнасці аглядання. Трымайце папярэднія значэнні DHCP і рэзалвера, пакуль тэст не пройдзе двойчы; змена, якая ламае інтэрнэт сям'і за вячэрай, значна цяжэй паддаецца адладцы, чым тая, якую можна адкаціць за хвіліну.