Pi-hole tidak menyekat iklan selepas VPN disambung: lima pemeriksaan

Iklan masih muncul pada klien, Pi-hole melaporkan dirinya sihat, dan terowong aktif, jadi nalurinya ialah menyalurkan trafik klien itu melalui Pi. Itu arah yang salah. Penapisan memerlukan soalan, bukan paket, dan klien yang pertanyaannya pergi ke penyelesai pembekal kekal tidak ditapis ke mana pun trafiknya mengalir. Lalui senarai ini mengikut urutan dan berhenti pada langkah pertama yang gagal, kerana langkah kemudian tidak boleh memberitahu apa-apa selagi langkah sebelumnya rosak.

1. Baca penyelesai yang sebenarnya digunakan oleh klien

Tanya klien, bukan penghala. Dalam Linux resolvectl status mencetak pelayan DNS bagi setiap pautan dan pautan mana yang menang; /etc/resolv.conf sendirian biasanya stub yang menunjuk ke 127.0.0.53. Dalam Windows ipconfig /all menyenaraikan pelayan yang disediakan oleh DHCP bagi setiap penyesuai, dan dalam macOS scutil --dns menunjukkan perkara yang sama mengikut skop. Jika jawapannya bukan alamat Pi-hole, anda mempunyai masalah penetapan dan langkah 2 ialah tempat ia berada.

Dua perkara mengalahkan penyelesai sistem walaupun ia ditetapkan dengan betul. Pelayar dengan DNS selamat sendiri (pilihan “Use secure DNS” Chrome, network.trr.mode Firefox) menghantar pertanyaan melalui HTTPS ke penyelesai awam dan tidak pernah membuka port 53. Dan klien VPN pada klien itu sendiri mungkin memasang pelayan DNS pada antara muka terowongnya dengan domain penghalaan ~., yang menjadikan pautan itu berwibawa untuk setiap nama.

Uji laluan yang dilalui aplikasi, bukan laluan yang dilalui alat nyahpepijat. resolvectl query example.com menunjukkan pautan mana yang menjawab, dan getent hosts example.com melalui laluan NSS yang sama seperti aplikasi; dalam macOS dscacheutil -q host -a name example.com membaca penyelesai berskop yang disenaraikan oleh scutil --dns. dig kosong tidak melakukan ini: ia membaca /etc/resolv.conf dan melangkau pemilihan mengikut pautan, jadi ia boleh menjawab dari Pi-hole sementara setiap aplikasi menggunakan penyelesai yang ditolak, dan itulah tepatnya kegagalan yang senarai ini wujud untuk menangkapnya. Simpan dig @192.168.1.53 untuk menguji satu pelayan tertentu.

2. Sahkan siapa yang mengagihkan jawapan

Penetapan datang daripada apa sahaja yang menjawab DHCP. Pada dnsmasq ia satu baris, dhcp-option=6,192.168.1.53; dalam UI web penghala ia medan DNS dalam bahagian DHCP LAN. Klien perlu memperbaharui sebelum melihatnya. Peranti yang menyala berhari-hari masih memegang pajakan lama, dan peranti dengan penyelesai yang ditaip tangan memegangnya selamanya. Perbaharui pada klien ujian dan bukannya menganggap penyebaran berlaku.

IPv6 ialah separuh yang terlepas pandang. Iklan penghala boleh membawa pelayan DNS sendiri (RDNSS), dan dalam OpenWrt itu pilihan ra_dns odhcpd; klien yang memilih IPv6 menggunakan pelayan itu sementara pilihan DHCPv4 yang baru anda tetapkan tidak digunakan. Jika anda belum bersedia menyediakan DNS melalui IPv6, padamkan iklan DNS sahaja: ra_dns dalam odhcpd, atau pilihan RDNSS dalam apa sahaja yang menjawab iklan penghala. Mematikan seluruh iklan juga membuang pengalamatan IPv6 daripada LAN, yang jauh lebih besar daripada perubahan yang anda maksudkan, manakala memadamkan pilihan DNS sahaja mengekalkan pengalamatan utuh dan menjadikan RDNSS yang hilang kelihatan dalam tangkapan paket.

3. Buktikan pertanyaan sampai ke Pi-hole

Pertanyaan dari Pi tidak membuktikan apa-apa tentang laluan rangkaian. Jalankannya dari klien dan baca kod respons:

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

Tamat masa menunjuk kepada penapisan atau laluan; REFUSED menunjuk kepada peraturan akses; SERVFAIL menunjuk kepada penyelesai huluan di belakang Pi-hole; jawapan betul yang tidak pernah muncul dalam log pertanyaan bermakna klien bertanya perkara lain. Periksa UDP dan TCP 53, kerana jawapan besar dan sesetengah penyelesai jatuh semula ke TCP, dan terbitkan kedua-duanya apabila Pi-hole berjalan dalam kontena. Pemetaan yang hanya meliputi UDP menghasilkan kegagalan berselang-seli yang kelihatan seperti kehilangan paket.

Kemudian mod mendengar Pi-hole menentukan sama ada ia menjawab langsung. Dalam mod tempatan sahaja dnsmasq mengabaikan pertanyaan daripada sumber yang bukan pada subrangkaian yang bersambung terus, dan itulah rupa klien di belakang penghala lain atau yang datang melalui terowong: klien kehabisan masa dan pertanyaan tidak pernah sampai ke log. Pertanyaan yang tetap muncul sebagai REFUSED telah ditolak oleh senarai akses atau peraturan tembok api. Membenarkan semua asal ialah pembetulan biasa, digandingkan dengan peraturan tembok api yang mengehadkan port 53 kepada subrangkaian anda sendiri.

4. Periksa sama ada terowong menggantikan atau menelan jawapan

Ini kes tempat kedua-dua gejala bersembunyi. Apabila penghala itu sendiri ialah klien VPN, pilihan DNS yang ditolak boleh mengatasi tetapan LAN pada saat terowong naik: pelayan OpenVPN menolak dhcp-option DNS, dan profil WireGuard membawa entri DNS sendiri. Baca penyelesai berkesan penghala dengan terowong aktif, bukan sebelum itu, dan abaikan apa yang didakwa oleh halaman LAN.

Kecacatan lain ialah kebolehhubungan, bukan penggantian. Jika awalan yang dibenarkan terowong merangkumi subrangkaian LAN anda, penghala mempunyai laluan yang menghantar pertanyaan untuk 192.168.1.53 ke dalam terowong, dan sebelah sana tiada laluan balik: pertanyaan kehabisan masa walaupun terowong sihat. Sebaliknya berlaku apabila Pi-hole berada pada subrangkaian yang tidak dibawa oleh terowong. Bandingkan alamat dengan awalan yang dibenarkan terowong dan jadual laluan penghala sebelum menyentuh DNS lagi.

Pilih satu pembetulan, bukan kedua-duanya. Sama ada jauhkan terowong daripada DNS — dengan pull-filter ignore “dhcp-option DNS” pada OpenVPN dan tanpa awalan LAN dalam AllowedIPs pada WireGuard —, atau terima penyelesai yang ditolak dan lepaskan penapisan tempatan untuk klien di belakang penghala itu. Apa pun yang anda pilih, tuliskannya di sebelah profil, kerana orang seterusnya yang menyuntingnya akan membalikkan keputusan itu secara tidak sengaja.

5. Ulangi ujian selepas sambung semula

Buat pertanyaan dari klien, sahkan klien itu muncul dalam log Pi-hole, kemudian selesaikan domain yang sepatutnya disekat dan periksa sama ada anda mendapat jawapan penyekatan dan bukan jawapan sebenar. Sambung semula terowong dan jalankan dua pertanyaan yang sama, kerana tetapan penyelesai yang hanya bertahan sehingga sambungan seterusnya ialah hasil biasa pembetulan yang digunakan pada lapisan yang salah.

Tinggalkan laluan penyelesai sekunder yang tidak bergantung pada terowong, supaya gangguan Pi-hole menurun kepada pelayaran tanpa penapisan dan bukan tanpa pelayaran langsung. Kekalkan nilai DHCP dan penyelesai sebelumnya sehingga ujian lulus dua kali; perubahan yang memutuskan internet isi rumah semasa makan malam jauh lebih sukar untuk dinyahpepijat daripada yang boleh anda balikkan dalam satu minit.