Pi-hole VPN ulangandan keyin reklamalarni bloklamayapti: beshta tekshiruv

Reklamalar hali ham bitta mijozda ko’rinadi, Pi-hole o’zini sog’lom deb e’lon qiladi va tunnel ishlayapti, shuning uchun o’sha mijoz trafigini Pi orqali o’tkazish instinkti paydo bo’ladi. Bu noto’g’ri burilish. Filtrlash paketlarni emas, savollarni talab qiladi va so’rovlari provayder rezolveriga ketadigan mijoz trafigi qayerda oqmasin, filtrlanmagan holda qoladi. Bu ro’yxatni tartib bilan bajaring va muvaffaqiyatsiz bo’lgan birinchi qadamda to’xtang, chunki oldingi qadam buzilgan bo’lsa, keyingi qadam sizga hech narsa aytolmaydi.

1. Mijoz haqiqatda ishlatayotgan rezolverni o’qing

Mijozdan so’rang, routerdan emas. Linuxda resolvectl status har bir ulanish bo’yicha DNS serverlarini va qaysi ulanish yutishini chop etadi; /etc/resolv.conf o’zi odatda 127.0.0.53 ga ishora qiluvchi stub bo’ladi. Windowsda ipconfig /all har bir adapter uchun DHCP bergan serverlarni sanaydi, macOSda esa scutil --dns xuddi shu narsani qamrov bo’yicha ko’rsatadi. Agar javob Pi-hole manzili bo’lmasa, sizda tayinlash muammosi bor va 2-qadam — uning joyi.

Tizim rezolverini to’g’ri sozlangan bo’lsa ham ikki narsa yengadi. O’z xavfsiz DNSiga ega brauzerlar (Chrome’ning “Use secure DNS”, Firefox’ning network.trr.mode) so’rovlarni HTTPS orqali ommaviy rezolverga yuboradi va 53-portni hech qachon ochmaydi. Va mijozning o’zidagi VPN mijozi o’z tunnel interfeysiga ~. marshrutlash domeni bilan DNS server o’rnatishi mumkin, bu esa o’sha ulanishni har bir nom uchun vakolatli qiladi.

Ilovalar bosib o’tadigan yo’lni sinang, debug vositasi bosib o’tadigan yo’lni emas. resolvectl query example.com qaysi ulanish javob berganini ko’rsatadi va getent hosts example.com ilova bilan bir xil NSS yo’lidan o’tadi; macOSda dscacheutil -q host -a name example.com scutil --dns sanab o’tgan qamrov rezolverlarini o’qiydi. Yalang’och dig buni qilmaydi: u /etc/resolv.conf ni o’qiydi va ulanish bo’yicha tanlovni tashlab ketadi, shuning uchun har bir ilova surilgan rezolverni ishlatayotganda u Pi-hole’dan javob berishi mumkin, va bu ro’yxat aynan shu nosozlikni tutish uchun mavjud. Bitta aniq serverni sinash uchun dig @192.168.1.53 ni saqlang.

2. Javobni kim tarqatayotganini tasdiqlang

Tayinlash DHCPga javob beradigan narsadan keladi. dnsmasqda bu bitta satr, dhcp-option=6,192.168.1.53; router veb-interfeysida bu LAN DHCP bo’limidagi DNS maydoni. Mijozlar buni ko’rishdan oldin yangilashlari kerak. Kunlab ishlab turgan qurilma hali ham eski ijarani saqlaydi, rezolveri qo’lda yozilgan qurilma esa uni abadiy saqlaydi. Tarqalishni taxmin qilish o’rniga sinov mijozida yangilang.

IPv6 — e’tibordan chetda qoladigan yarmi. Router e’lonlari o’z DNS serverini olib yurishi mumkin (RDNSS), OpenWrtda bu odhcpdning ra_dns opsiyasi; IPv6 ni afzal ko’rgan mijoz o’sha serverdan foydalanadi, siz hozir o’rnatgan DHCPv4 opsiyasi esa ishlatilmay qoladi. Agar IPv6 orqali DNS xizmat qilishga tayyor bo’lmasangiz, faqat DNS e’lonini tozalang: odhcpdda ra_dns yoki router e’lonlariga javob beradigan har qanday narsada RDNSS opsiyasi. Butun e’lonni o’chirish LANdan IPv6 manzillashni ham olib tashlaydi, bu siz o’ylagan o’zgarishdan ancha katta, holbuki faqat DNS opsiyasini tozalash manzillashni buzilmagan holda saqlaydi va yetishmayotgan RDNSS ni paket ushlashda ko’rinadigan qiladi.

3. So’rov Pi-holeda yetib borishini isbotlang

Pidan qilingan so’rov tarmoq yo’li haqida hech narsani isbotlamaydi. Uni mijozdan ishga tushiring va javob kodini o’qing:

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

Vaqt tugashi filtrlashga yoki marshrutga ishora qiladi; REFUSED kirish qoidasiga ishora qiladi; SERVFAIL Pi-hole orqasidagi yuqori rezolverga ishora qiladi; so’rovlar jurnalida hech qachon ko’rinmaydigan to’g’ri javob mijoz boshqa narsani so’raganini bildiradi. UDP va TCP 53 ni tekshiring, chunki katta javoblar va ba’zi rezolverlar TCPga qaytadi, va Pi-hole konteynerda ishlaganda ikkalasini ham e’lon qiling. Faqat UDPni qamrab olgan xaritalash paket yo’qotilishiga o’xshash davriy nosozliklar keltirib chiqaradi.

So’ngra Pi-holening tinglash rejimi u umuman javob beradimi-yo’qmi hal qiladi. Faqat mahalliy rejimda dnsmasq to’g’ridan-to’g’ri ulangan subnetda bo’lmagan manbalardan kelgan so’rovlarni e’tiborsiz qoldiradi va boshqa router orqasidagi yoki tunneldan kelayotgan mijoz aynan shunday ko’rinadi: mijozning vaqti tugaydi va so’rov hech qachon jurnalga yetib bormaydi. Shunga qaramay REFUSED bo’lib ko’ringan so’rovni kirish ro’yxati yoki firewall qoidasi rad etgan. Barcha manbalarga ruxsat berish odatiy tuzatishdir, 53-portni o’zingizning subnetlaringiz bilan cheklovchi firewall qoidasi bilan birga.

4. Tunnel javobni almashtirganmi yoki yutib yuborganmi, tekshiring

Bu ikkala alomat ham yashiringan holat. Routerning o’zi VPN mijoz bo’lganda, surilgan DNS opsiyasi tunnel ko’tarilgan paytda LAN sozlamasini chetlab o’tishi mumkin: OpenVPN serverlari dhcp-option DNS ni suradi, WireGuard profillari esa o’z DNS yozuvini olib yuradi. Routerning samarali rezolverini tunnel ishlab turganda o’qing, undan oldin emas, va LAN sahifasi da’vo qilgan narsaga e’tibor bermang.

Boshqa nuqson — almashtirish emas, yetib borish. Agar tunnelning ruxsat etilgan prefikslari sizning LAN subnetingizni qamrab olsa, routerda 192.168.1.53 uchun so’rovlarni tunnel ichiga yuboradigan marshrut bor, qarshi tomonda esa qaytish marshruti yo’q: tunnel sog’lom bo’lsa ham so’rovlarning vaqti tugaydi. Buning aksi Pi-hole tunnel olib o’tmaydigan subnetda joylashganda yuz beradi. DNSga yana tegishdan oldin manzilni tunnelning ruxsat etilgan prefikslari va routerning marshrutlar jadvali bilan solishtiring.

Ikki emas, bitta tuzatishni tanlang. Yoki tunnelni DNSdan uzoq tuting — OpenVPNda pull-filter ignore “dhcp-option DNS” va WireGuardda AllowedIPs ichida LAN prefiksisiz —, yoki surilgan rezolverni qabul qiling va o’sha router orqasidagi mijozlar uchun mahalliy filtrlashdan voz keching. Nima tanlasangiz ham, uni profil yoniga yozib qo’ying, chunki keyingi tahrir qiluvchi kishi aks holda qarorni tasodifan teskari o’giradi.

5. Qayta ulangandan keyin sinovni takrorlang

Bitta mijozdan so’rov qiling, o’sha mijoz Pi-hole jurnalida ko’rinishini tasdiqlang, so’ngra bloklanishi kerak bo’lgan domenni hal qiling va haqiqiy javob o’rniga bloklash javobini olishingizni tekshiring. Tunnelni qayta ulang va o’sha ikki so’rovni bajaring, chunki faqat keyingi ulanishgacha davom etadigan rezolver sozlamasi noto’g’ri qatlamda qo’llangan tuzatishning odatiy natijasidir.

Tunnelga bog’liq bo’lmagan ikkilamchi rezolver yo’lini qoldiring, shunda Pi-hole uzilishi umuman ko’rish to’xtashiga emas, filtrsiz ko’rishga tushadi. Sinov ikki marta o’tguncha oldingi DHCP va rezolver qiymatlarini saqlang; kechki ovqat paytida uy internetini buzadigan o’zgarishni sozlash bir daqiqada qaytarish mumkin bo’lgan o’zgarishdan ancha qiyin.