Pi-hole VPN қосылғаннан кейін жарнамаларды блоктамайды: бес тексеру

Клиентте жарнамалар әлі көрсетіліп тұр, Pi-hole өзін сау деп хабарлайды, туннель де қосылып тұр, сондықтан сол клиенттің трафигін Pi арқылы өткізу инстинкті пайда болады. Бұл дұрыс емес бұрылыс. Сүзгілеуге пакеттер емес, сұрақтар қажет, және сұраулары провайдер резолверіне кететін клиент трафигі қайда ақса да сүзгіден өтпей қалады. Бұл тізімді ретімен орындаңыз және сәтсіз аяқталған бірінші қадамда тоқтаңыз, өйткені алдыңғы қадам бұзылған кезде келесі қадам сізге ештеңе айта алмайды.

1. Клиент шын мәнінде қолданып отырған резолверді оқыңыз

Роутерден емес, клиенттен сұраңыз. Linux-те resolvectl status әр қосылым бойынша DNS серверлерін және қай қосылым жеңетінін басып шығарады; /etc/resolv.conf өздігінен әдетте 127.0.0.53-ке сілтейтін stub болып табылады. 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; роутердің веб интерфейсінде бұл LAN DHCP бөліміндегі DNS өрісі. Клиенттер мұны көру үшін жаңартуы керек. Күндер бойы қосылып тұрған құрылғы әлі ескі жалдауды ұстайды, ал резолвері қолмен терілген құрылғы оны мәңгі ұстайды. Таралуды болжаудың орнына сынақ клиентінде жаңартыңыз.

IPv6 — ұмытылып қалатын жартысы. Роутер хабарландырулары өз DNS серверін алып жүруі мүмкін (RDNSS), ал OpenWrt-те бұл odhcpd-ның ra_dns опциясы; IPv6-ны қалайтын клиент сол серверді пайдаланады, ал жаңа ғана орнатқан DHCPv4 опциясы пайдаланылмай қалады. Егер IPv6 бойынша DNS ұсынуға дайын болмасаңыз, тек DNS хабарландыруын тазалаңыз: odhcpd-тегі ra_dns немесе роутер хабарландыруларына жауап беретін кез келген нәрседегі RDNSS опциясы. Бүкіл хабарландыруды өшіру LAN-нан IPv6 мекенжайлауды да алып тастайды, бұл сіз ойлаған өзгерістен әлдеқайда үлкен, ал тек 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 ретінде көрінген сұрауды қатынау тізімі немесе firewall ережесі қабылдамаған. Барлық көздерге рұқсат беру әдеттегі түзету, онымен бірге 53 портын өз ішкі желілеріңізбен шектейтін firewall ережесі жүреді.

4. Туннель жауапты алмастырды ма әлде жұтып қойды ма, тексеріңіз

Бұл екі симптом да жасырылатын жағдай. Роутердің өзі VPN клиенті болған кезде, итерілген DNS опциясы туннель көтерілген сәтте LAN параметрін басып кетуі мүмкін: OpenVPN серверлері dhcp-option DNS-ті итереді, ал WireGuard профильдері өз DNS жазбасын алып жүреді. Роутердің тиімді резолверін туннель қосылып тұрғанда оқыңыз, оған дейін емес, және LAN беті айтқанды елемеңіз.

Басқа ақау — алмастыру емес, қолжетімділік. Егер туннельдің рұқсат етілген префикстері сіздің LAN ішкі желіңізді қамтыса, роутерде 192.168.1.53 үшін сұрауларды туннельге жіберетін маршрут бар, ал қарсы жақта кері маршрут жоқ: туннель сау болса да сұраулардың уақыты бітеді. Керісінше жағдай Pi-hole туннель тасымалдамайтын ішкі желіде орналасқанда болады. DNS-ке қайта тимес бұрын мекенжайды туннельдің рұқсат етілген префикстерімен және роутердің маршрут кестесімен салыстырыңыз.

Екеуін емес, бір түзетуді таңдаңыз. Не туннельді DNS-тен алыс ұстаңыз — OpenVPN-де pull-filter ignore “dhcp-option DNS” және WireGuard-та AllowedIPs ішінде LAN префиксінсіз —, не итерілген резолверді қабылдап, сол роутердің артындағы клиенттер үшін жергілікті сүзгілеуден бас тартыңыз. Қайсысын таңдасаңыз да, оны профильдің қасына жазыңыз, өйткені оны келесі өңдейтін адам әйтпесе шешімді байқаусызда кері айналдырады.

5. Қайта қосылғаннан кейін сынақты қайталаңыз

Клиенттен сұрау жасаңыз, сол клиенттің Pi-hole журналында көрінетінін растаңыз, содан кейін блокталуы тиіс доменді шешіп, нақты жауаптың орнына блоктау жауабын алатыныңызды тексеріңіз. Туннельді қайта қосып, сол екі сұрауды орындаңыз, өйткені келесі қосылуға дейін ғана сақталатын резолвер параметрі — қате қабатта қолданылған түзетудің әдеттегі нәтижесі.

Туннельге тәуелді емес қосымша резолвер жолын қалдырыңыз, сонда Pi-hole істен шыққанда шолу мүлде тоқтамай, сүзгісіз шолуға түседі. Сынақ екі рет өткенше бұрынғы DHCP және резолвер мәндерін сақтаңыз; кешкі ас кезінде үй интернетін үзетін өзгерісті жөндеу бір минутта қайтаруға болатын өзгерістен әлдеқайда қиын.