Pi-hole VPN qoşulduqdan sonra reklamları bloklamır: beş yoxlama

Reklamlar hələ də bir klientdə görünür, Pi-hole özünü sağlam elan edir və tunel işləyir, ona görə də instinkt həmin klientin trafikini Pi vasitəsilə yönləndirməkdir. Bu, yanlış dönüşdür. Filtrləmə paketlərə deyil, suallara ehtiyac duyur və sorğuları ISP həlledicisinə gedən klient trafiki haradan axsa da filtrlənməmiş qalır. Bu siyahını sıra ilə işləyin və ilk uğursuz addımda dayanın, çünki əvvəlki addım xarab olduqda sonrakı addım sizə heç nə deyə bilməz.

1. Klientin həqiqətən istifadə etdiyi həlledicini oxuyun

Routerdən deyil, klientdən soruşun. Linuxda resolvectl status hər keçid üzrə DNS serverlərini və hansı keçidin qalib gəldiyini çap edir; /etc/resolv.conf tək başına adətən 127.0.0.53-ə işarə edən stub-dur. Windowsda ipconfig /all hər adapter üzrə DHCP ilə verilən serverləri sadalayır, macOSda isə scutil --dns eyni şeyi sahə üzrə göstərir. Əgər cavab Pi-hole ünvanı deyilsə, təyinat probleminiz var və 2-ci addım onun yeridir.

İki şey sistem həlledicisini düzgün qurulduqda belə məğlub edir. Öz təhlükəsiz DNS-i olan brauzerlər (Chrome-un “Use secure DNS” seçimi, Firefox-un network.trr.mode) sorğuları HTTPS ilə ictimai həllediciyə göndərir və 53 portunu heç vaxt açmır. Və klientin özündəki VPN klienti öz tunel interfeysinə ~. yönləndirmə domeni ilə DNS serveri quraşdıra bilər, bu da həmin keçidi hər ad üçün səlahiyyətli edir.

Tətbiqlərin getdiyi yolu sınayın, sazlama alətinin getdiyi yolu deyil. resolvectl query example.com hansı keçidin cavab verdiyini göstərir və getent hosts example.com tətbiqin keçdiyi eyni NSS yolundan keçir; macOSda dscacheutil -q host -a name example.com scutil --dns-in sadaladığı sahəli həllediciləri oxuyur. Çılpaq dig bunu etmir: o, /etc/resolv.conf-u oxuyur və keçid üzrə seçimi atlayır, ona görə də hər tətbiq ötürülən həlledicidən istifadə edərkən Pi-hole-dan cavab verə bilər və bu, məhz bu siyahının tutmaq üçün mövcud olduğu nasazlıqdır. Bir konkret serveri yoxlamaq üçün dig @192.168.1.53-ü saxlayın.

2. Cavabı kimin payladığını təsdiqləyin

Təyinat DHCP-yə cavab verən hər şeydən gəlir. dnsmasq-da bu bir sətirdir, dhcp-option=6,192.168.1.53; routerin veb interfeysində isə bu, LAN DHCP bölməsindəki DNS sahəsidir. Klientlər bunu görməmişdən əvvəl yeniləməlidirlər. Günlərlə işləyən cihaz hələ də köhnə lizinqi saxlayır və həlledicisi əl ilə yazılmış cihaz onu əbədi saxlayır. Yayılmanı fərz etmək əvəzinə sınaq klientində yeniləyin.

IPv6 yaddan çıxan yarıdır. Router reklamları öz DNS serverini daşıya bilər (RDNSS) və OpenWrt-də bu, odhcpd-nin ra_dns seçimidir; IPv6-ya üstünlük verən klient həmin serverdən istifadə edərkən yenicə qurduğunuz DHCPv4 seçimi istifadəsiz qalır. Əgər IPv6 DNS xidmət etməyə hazır deyilsinizsə, yalnız DNS reklamını təmizləyin: odhcpd-də ra_dns və ya router reklamlarına cavab verən hər şeydə RDNSS seçimini. Bütün reklamı söndürmək həm də LAN-dan IPv6 ünvanlamasını çıxarır ki, bu da etmək istədiyiniz dəyişiklikdən qat-qat böyükdür, halbuki yalnız DNS seçimini təmizləmək ünvanlamanı toxunulmaz saxlayır və itkin RDNSS-i paket tutmasında görünən edir.

3. Sorğunun Pi-hole-a çatdığını sübut edin

Pi-dən edilən sorğu şəbəkə yolu haqqında heç nə sübut etmir. Onu klientdən işlədin və cavab kodunu oxuyun:

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

Taymaut filtrləməyə və ya marşruta işarə edir; REFUSED giriş qaydasına işarə edir; SERVFAIL Pi-hole-un arxasındakı yuxarı həllediciyə işarə edir; sorğu jurnalında heç vaxt görünməyən düzgün cavab klientin başqa bir şey soruşduğunu bildirir. UDP və TCP 53-ü yoxlayın, çünki böyük cavablar və bəzi həlledicilər TCP-yə keçir və Pi-hole konteynerdə işləyəndə hər ikisini dərc edin. Yalnız UDP-ni əhatə edən xəritələmə paket itkisinə bənzəyən fasiləli nasazlıqlar yaradır.

Sonra Pi-hole-un dinləmə rejimi ümumiyyətlə cavab verib-vermədiyini həll edir. Yalnız yerli rejimdə dnsmasq birbaşa qoşulmuş alt şəbəkədə olmayan mənbələrdən gələn sorğuları nəzərə almır ki, bu da başqa routerin arxasındakı və ya tuneldən gələn klientin tam görünüşüdür: klientin vaxtı bitir və sorğu heç vaxt jurnala çatmır. REFUSED kimi görünən sorğu isə giriş siyahısı və ya firewall qaydası ilə rədd edilib. Bütün mənbələrə icazə vermək adi həlldir və 53 portunu öz alt şəbəkələrinizlə məhdudlaşdıran firewall qaydası ilə birləşdirilir.

4. Tunelin cavabı əvəz edib-etmədiyini və ya udub-udmadığını yoxlayın

Bu, hər iki simptomun gizləndiyi haldır. Router özü VPN klienti olduqda, ötürülən DNS seçimi tunel qalxdığı anda LAN ayarını üstələyə bilər: OpenVPN serverləri dhcp-option DNS ötürür və WireGuard profilləri öz DNS qeydini daşıyır. Routerin effektiv həlledicisini tunel işləyərkən oxuyun, ondan əvvəl deyil, və LAN səhifəsinin iddia etdiyini nəzərə almayın.

Digər qüsur dəyişdirmə deyil, əlçatanlıqdır. Əgər tunelin icazə verilən prefiksləri LAN alt şəbəkənizi əhatə edirsə, routerin 192.168.1.53 üçün sorğuları tunelə göndərən marşrutu var və qarşı tərəfin geriyə marşrutu yoxdur: tunel sağlam olsa da sorğuların vaxtı bitir. Əksi hal Pi-hole tunelin daşımadığı alt şəbəkədə yerləşəndə baş verir. DNS-ə yenidən toxunmazdan əvvəl ünvanı tunelin icazə verilən prefiksləri və routerin marşrut cədvəli ilə müqayisə edin.

Hər ikisini deyil, bir həll seçin. Ya tuneli DNS-dən uzaq saxlayın — OpenVPN-də pull-filter ignore “dhcp-option DNS” və WireGuard-da AllowedIPs-də LAN prefiksi olmadan — ya da ötürülən həlledicini qəbul edin və həmin routerin arxasındakı klientlər üçün yerli filtrləmədən imtina edin. Hansını seçsəniz də, onu profilin yanında yazın, çünki onu növbəti redaktə edən şəxs qərarı təsadüfən tərsinə çevirəcək.

5. Yenidən qoşulduqdan sonra testi təkrarlayın

Bir klientdən sorğu verin, həmin klientin Pi-hole jurnalında göründüyünü təsdiqləyin, sonra bloklanmalı olan domeni həll edin və real cavab əvəzinə bloklama cavabı aldığınızı yoxlayın. Tuneli yenidən qoşun və eyni iki sorğunu işlədin, çünki yalnız növbəti yenidən qoşulmaya qədər davam edən həlledici ayarı yanlış qatda tətbiq edilmiş düzəlişin adi nəticəsidir.

Tuneldən asılı olmayan ikinci dərəcəli həlledici yolu buraxın ki, Pi-hole nasazlığı heç gəzinti olmaması əvəzinə filtrsiz gəzintiyə çevrilsin. Test iki dəfə keçənə qədər əvvəlki DHCP və həlledici dəyərlərini saxlayın; ailənin internetini şam yeməyində kəsən dəyişikliyi sazlamaq bir dəqiqədə geri qaytara biləcəyiniz dəyişiklikdən qat-qat çətindir.