Pi-hole tidak memblokir iklan setelah VPN tersambung: lima pemeriksaan

Iklan masih muncul di sebuah klien, Pi-hole melaporkan dirinya sehat, dan terowongan aktif, jadi nalurinya adalah mengarahkan lalu lintas klien itu melalui Pi. Itu belokan yang salah. Penyaringan butuh pertanyaannya, bukan paketnya, dan klien yang kuerinya pergi ke resolver penyedia tetap tanpa penyaringan ke mana pun lalu lintasnya mengalir. Jalani daftar ini secara berurutan dan berhenti pada langkah pertama yang gagal, karena langkah berikutnya tidak bisa memberi tahu apa pun selama langkah sebelumnya rusak.

1. Baca resolver yang benar-benar dipakai klien

Tanyakan ke klien, bukan ke router. Di Linux, resolvectl status mencetak server DNS per tautan dan tautan mana yang menang; /etc/resolv.conf sendirian biasanya stub yang mengarah ke 127.0.0.53. Di Windows, ipconfig /all mencantumkan server dari DHCP per adaptor, dan di macOS scutil --dns menunjukkan hal yang sama per cakupan. Jika jawabannya bukan alamat Pi-hole, Anda punya masalah penetapan dan langkah 2 adalah tempatnya berada.

Dua hal mengalahkan resolver sistem bahkan saat sudah diatur dengan benar. Peramban dengan DNS aman sendiri (opsi “Use secure DNS” di Chrome, network.trr.mode di Firefox) mengirim kueri lewat HTTPS ke resolver publik dan tidak pernah membuka port 53. Dan klien VPN di klien itu sendiri bisa memasang server DNS pada antarmuka terowongannya dengan domain perutean ~., yang membuat tautan itu otoritatif untuk setiap nama.

Uji jalur yang dilalui aplikasi, bukan jalur yang dilalui alat pengawakutuan. resolvectl query example.com menunjukkan tautan mana yang menjawab, dan getent hosts example.com melewati jalur NSS yang sama seperti aplikasi; di macOS dscacheutil -q host -a name example.com membaca resolver bercakupan yang dicantumkan scutil --dns. dig polos tidak melakukan ini: ia membaca /etc/resolv.conf dan melewati pemilihan per tautan, jadi ia bisa menjawab dari Pi-hole sementara setiap aplikasi memakai resolver yang didorong, dan itulah tepatnya kegagalan yang daftar ini ada untuk menangkapnya. Simpan dig @192.168.1.53 untuk menguji satu server tertentu.

2. Pastikan siapa yang membagikan jawaban

Penetapan datang dari apa pun yang menjawab DHCP. Di dnsmasq itu satu baris, dhcp-option=6,192.168.1.53; di antarmuka web router itu kolom DNS di bagian DHCP LAN. Klien harus memperbarui sebelum melihatnya. Perangkat yang menyala berhari-hari masih memegang sewa lama, dan perangkat dengan resolver yang diketik manual memegangnya selamanya. Perbarui di klien uji alih-alih menganggapnya menyebar.

IPv6 adalah separuh yang terlewat. Pengumuman router bisa membawa server DNS sendiri (RDNSS), dan di OpenWrt itu opsi ra_dns milik odhcpd; klien yang memilih IPv6 memakai server itu sementara opsi DHCPv4 yang baru Anda setel tidak terpakai. Jika Anda belum siap melayani DNS lewat IPv6, hapus hanya pengumuman DNS: ra_dns di odhcpd, atau opsi RDNSS pada apa pun yang menjawab pengumuman router. Mematikan seluruh pengumuman juga menghapus pengalamatan IPv6 dari LAN, yang jauh lebih besar daripada perubahan yang Anda maksud, sedangkan menghapus hanya opsi DNS menjaga pengalamatan tetap utuh dan membuat RDNSS yang hilang terlihat dalam tangkapan paket.

3. Buktikan kueri mencapai Pi-hole

Kueri dari Pi tidak membuktikan apa pun tentang jalur jaringan. Jalankan dari klien dan baca kode responsnya:

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

Batas waktu menunjuk ke penyaringan atau ke rute; REFUSED menunjuk ke aturan akses; SERVFAIL menunjuk ke resolver hulu di belakang Pi-hole; jawaban benar yang tidak pernah muncul di log kueri berarti klien menanyakan hal lain. Periksa UDP dan TCP 53, karena jawaban besar dan sebagian resolver jatuh kembali ke TCP, dan terbitkan keduanya saat Pi-hole berjalan di kontainer. Pemetaan yang hanya mencakup UDP menghasilkan kegagalan berselang yang tampak seperti kehilangan paket.

Lalu mode mendengarkan Pi-hole menentukan apakah ia menjawab sama sekali. Dalam mode hanya lokal, dnsmasq mengabaikan kueri dari sumber yang tidak berada di subnet yang terhubung langsung, dan itulah persisnya bentuk klien di balik router lain atau yang datang lewat terowongan: klien kehabisan waktu dan kueri tidak pernah mencapai log. Kueri yang tetap muncul sebagai REFUSED ditolak oleh daftar akses atau aturan firewall. Mengizinkan semua asal adalah perbaikan biasa, dipasangkan dengan aturan firewall yang membatasi port 53 ke subnet Anda sendiri.

4. Periksa apakah terowongan menggantikan atau menelan jawabannya

Ini kasus tempat kedua gejala bersembunyi. Ketika router itu sendiri adalah klien VPN, opsi DNS yang didorong bisa menimpa pengaturan LAN pada saat terowongan naik: server OpenVPN mendorong dhcp-option DNS, dan profil WireGuard membawa entri DNS sendiri. Baca resolver efektif router saat terowongan aktif, bukan sebelumnya, dan abaikan apa yang diklaim halaman LAN.

Kerusakan lainnya adalah keterjangkauan, bukan penggantian. Jika prefiks yang diizinkan terowongan mencakup subnet LAN Anda, router punya rute yang mengirim kueri untuk 192.168.1.53 ke dalam terowongan, dan sisi seberang tidak punya rute balik: kueri kehabisan waktu meski terowongan sehat. Kebalikannya terjadi saat Pi-hole berada di subnet yang tidak dibawa terowongan. Bandingkan alamatnya dengan prefiks yang diizinkan terowongan dan tabel rute router sebelum menyentuh DNS lagi.

Pilih satu perbaikan, bukan keduanya. Entah jauhkan terowongan dari DNS — dengan pull-filter ignore “dhcp-option DNS” di OpenVPN dan tanpa prefiks LAN di AllowedIPs pada WireGuard —, atau terima resolver yang didorong dan lepaskan penyaringan lokal untuk klien di balik router itu. Apa pun yang Anda pilih, tuliskan di samping profil, karena orang berikutnya yang menyuntingnya akan membalik keputusan itu tanpa sengaja.

5. Ulangi uji setelah menyambung ulang

Lakukan kueri dari klien, pastikan klien itu muncul di log Pi-hole, lalu resolusi domain yang seharusnya diblokir dan periksa bahwa Anda mendapat jawaban pemblokiran alih-alih jawaban asli. Sambungkan ulang terowongan dan jalankan dua kueri yang sama, karena pengaturan resolver yang hanya bertahan sampai penyambungan berikutnya adalah hasil biasa dari perbaikan yang diterapkan di lapisan yang salah.

Tinggalkan jalur resolver sekunder yang tidak bergantung pada terowongan, agar pemadaman Pi-hole menurun ke penjelajahan tanpa penyaringan alih-alih tanpa penjelajahan sama sekali. Pertahankan nilai DHCP dan resolver sebelumnya sampai uji lulus dua kali; perubahan yang memutus internet rumah saat makan malam jauh lebih sulit di-debug daripada yang bisa Anda kembalikan dalam satu menit.