VPN bağlandıktan sonra Pi-hole reklamları engellemiyor: beş kontrol

Reklamlar hâlâ bir istemcide görünüyor, Pi-hole kendini sağlıklı bildiriyor ve tünel açık, bu yüzden içgüdü o istemcinin trafiğini Pi üzerinden yönlendirmek oluyor. Bu yanlış dönüş. Filtreleme paketleri değil soruları gerektirir ve sorguları sağlayıcının çözümleyicisine giden bir istemci, trafiği nereye akarsa aksın filtrelenmemiş kalır. Bu listeyi sırayla izleyin ve başarısız olan ilk adımda durun, çünkü önceki adım bozukken sonraki adım size hiçbir şey söyleyemez.

1. İstemcinin gerçekte kullandığı çözümleyiciyi okuyun

Yönlendiriciye değil istemciye sorun. Linux'ta resolvectl status bağlantı başına DNS sunucularını ve hangi bağlantının kazandığını yazdırır; /etc/resolv.conf tek başına genellikle 127.0.0.53'e işaret eden bir stub'dur. Windows'ta ipconfig /all DHCP'nin verdiği sunucuları bağdaştırıcı başına listeler, macOS'ta scutil --dns aynı şeyi kapsam başına gösterir. Yanıt Pi-hole'ın adresi değilse bir atama sorununuz var ve adım 2 onun bulunduğu yerdir.

Sistem çözümleyicisi doğru ayarlanmış olsa bile iki şey onu yener. Kendi güvenli DNS'i olan tarayıcılar (Chrome'un “Use secure DNS” seçeneği, Firefox'un network.trr.mode ayarı) sorguları HTTPS üzerinden genel bir çözümleyiciye gönderir ve 53 numaralı portu asla açmaz. Ayrıca istemcinin kendisindeki bir VPN istemcisi, tünel arayüzüne ~. yönlendirme alan adıyla bir DNS sunucusu kurabilir; bu da o bağlantıyı her ad için yetkili kılar.

Uygulamaların izlediği yolu test edin, hata ayıklama aracının izlediği yolu değil. resolvectl query example.com hangi bağlantının yanıt verdiğini gösterir ve getent hosts example.com bir uygulamayla aynı NSS yolundan geçer; macOS'ta dscacheutil -q host -a name example.com, scutil --dns'in listelediği kapsamlı çözümleyicileri okur. Çıplak dig bunu yapmaz: /etc/resolv.conf'u okur ve bağlantı bazlı seçimi atlar, bu yüzden her uygulama itilen çözümleyiciyi kullanırken o Pi-hole'dan yanıt verebilir ve bu listeden var olma nedeni tam olarak bu arızadır. Belirli bir sunucuyu test etmek için dig @192.168.1.53'ü saklayın.

2. Yanıtı kimin dağıttığını doğrulayın

Atama DHCP'ye yanıt veren şeyden gelir. dnsmasq'da bu tek satırdır, dhcp-option=6,192.168.1.53; yönlendiricinin web arayüzünde bu, LAN DHCP bölümündeki DNS alanıdır. İstemcilerin bunu görmek için yenilemesi gerekir. Günlerdir açık olan bir cihaz hâlâ eski kiralamayı tutar ve çözümleyicisi elle yazılmış bir cihaz onu sonsuza dek tutar. Yayıldığını varsaymak yerine bir test istemcisinde yenileyin.

IPv6 atlanan yarıdır. Yönlendirici duyuruları kendi DNS sunucusunu taşıyabilir (RDNSS) ve OpenWrt'de bu, odhcpd'nin ra_dns seçeneğidir; IPv6'yı tercih eden bir istemci o sunucuyu kullanırken yeni ayarladığınız DHCPv4 seçeneği kullanılmadan kalır. IPv6 üzerinden DNS sunmaya hazır değilseniz yalnızca DNS duyurusunu temizleyin: odhcpd'de ra_dns veya yönlendirici duyurularına yanıt veren her neyse onun içindeki RDNSS seçeneği. Duyurunun tamamını kapatmak IPv6 adreslemeyi de LAN'den kaldırır ki bu amaçladığınızdan çok daha büyük bir değişikliktir; yalnızca DNS seçeneğini temizlemek ise adreslemeyi bozulmadan bırakır ve eksik RDNSS'yi bir paket yakalamada görünür kılar.

3. Sorgunun Pi-hole'a ulaştığını kanıtlayın

Pi'den yapılan bir sorgu ağ yoluna dair hiçbir şey kanıtlamaz. İstemciden çalıştırın ve yanıt kodunu okuyun:

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

Zaman aşımı filtrelemeye veya bir rotaya işaret eder; REFUSED bir erişim kuralına; SERVFAIL Pi-hole'ın arkasındaki üst çözümleyiciye; sorgu günlüğünde asla görünmeyen doğru bir yanıt ise istemcinin başka bir şey sorduğu anlamına gelir. UDP ve TCP 53'ü denetleyin, çünkü büyük yanıtlar ve bazı çözümleyiciler TCP'ye geri düşer, ve Pi-hole bir konteynerde çalışırken ikisini de yayımlayın. Yalnızca UDP'yi kapsayan bir eşleme, paket kaybı gibi görünen aralıklı arızalar üretir.

Ardından Pi-hole'ın dinleme kipi, hiç yanıt verip vermeyeceğine karar verir. Yalnızca yerel kipinde dnsmasq, doğrudan bağlı bir alt ağda olmayan kaynaklardan gelen sorguları yok sayar ve başka bir yönlendiricinin arkasındaki ya da tünelden gelen bir istemci tam olarak böyle görünür: istemcinin süresi dolar ve sorgu günlüğe asla ulaşmaz. Yine de REFUSED olarak görünen sorgu bir erişim listesi veya güvenlik duvarı kuralı tarafından reddedilmiştir. Tüm kaynaklara izin vermek olağan düzeltmedir; 53 numaralı portu kendi alt ağlarınızla sınırlayan bir güvenlik duvarı kuralıyla birlikte.

4. Tünelin yanıtı değiştirdiğini mi yuttuğunu mu denetleyin

Her iki belirtinin de saklandığı durum budur. Yönlendiricinin kendisi bir VPN istemcisiyse, itilen bir DNS seçeneği tünel kalktığı anda LAN ayarını geçersiz kılabilir: OpenVPN sunucuları dhcp-option DNS iter ve WireGuard profilleri kendi DNS girdisini taşır. Yönlendiricinin etkin çözümleyicisini tünel açıkken okuyun, öncesinde değil, ve LAN sayfasının iddia ettiğini yok sayın.

Diğer arıza değiştirme değil erişilebilirliktir. Tünelin izin verilen önekleri LAN alt ağınızı içeriyorsa, yönlendiricinin 192.168.1.53 için sorguları tünelin içine gönderen bir rotası vardır ve karşı tarafın geri dönüş rotası yoktur: tünel sağlıklı olsa da sorguların süresi dolar. Pi-hole tünelin taşımadığı bir alt ağda oturduğunda bunun tersi olur. DNS'e yeniden dokunmadan önce adresi tünelin izin verilen önekleri ve yönlendiricinin yönlendirme tablosuyla karşılaştırın.

İki değil bir düzeltme seçin. Ya tüneli DNS'ten uzak tutun — OpenVPN'de pull-filter ignore “dhcp-option DNS” ve WireGuard'da AllowedIPs içinde LAN öneki olmadan —, ya da itilen çözümleyiciyi kabul edip o yönlendiricinin arkasındaki istemciler için yerel filtrelemeden vazgeçin. Hangisini seçerseniz seçin, profilin yanına yazın, çünkü onu bir sonraki düzenleyen kişi aksi hâlde kararı yanlışlıkla tersine çevirecektir.

5. Yeniden bağlandıktan sonra testi yineleyin

Bir istemciden sorgu yapın, o istemcinin Pi-hole günlüğünde göründüğünü doğrulayın, ardından engellenmesi gereken bir alan adını çözümleyin ve gerçek yanıt yerine engelleme yanıtı aldığınızı denetleyin. Tüneli yeniden bağlayın ve aynı iki sorguyu çalıştırın, çünkü yalnızca bir sonraki bağlantıya kadar süren bir çözümleyici ayarı, yanlış katmanda uygulanan bir düzeltmenin olağan sonucudur.

Tünele bağlı olmayan ikincil bir çözümleyici yolu bırakın, böylece Pi-hole kesintisi hiç tarama olmaması yerine filtresiz taramaya düşsün. Test iki kez geçene kadar önceki DHCP ve çözümleyici değerlerini koruyun; akşam yemeğinde evin internetini bozan bir değişikliğin hata ayıklaması, bir dakikada geri alabileceğiniz bir değişiklikten çok daha zordur.