Mengapa Pi-hole v6 mengabaikan kueri DNS dari klien WireGuard

Pi-hole v6 menerima kueri DNS pada port 53 lalu memutuskan apakah paket yang tiba boleh dijawab. Di host WireGuard, keputusan kedua itu biasanya menjadi alasan klien mengalami timeout sementara resolver tampak sehat dari LAN. Port terbuka, FTL berjalan, tetapi tidak ada yang kembali dari 10.90.0.1. Tiga hal saling memengaruhi sebelum jawaban keluar: dns.interface, dns.listeningMode dan firewall di depan keduanya.

Socket pendengar tidak menentukan siapa yang mendapat jawaban

FTL membuka pendengar UDP dan TCP pada port 53. Dalam konfigurasi bawaan socket sering berupa wildcard, jadi ss -lunp | grep :53 menampilkan 0.0.0.0:53 dan [::]:53 terlepas dari apakah klien VPN dilayani. Socket wildcard menerima paket, lalu FTL menerapkan aturan antarmuka dan sumbernya sebelum menjawab. Itulah sebabnya "port sedang mendengarkan" hampir tidak membuktikan apa pun tentang klien tunnel.

Baca konfigurasi yang berjalan, bukan berkas yang Anda anggap aktif. pihole-FTL --config dns.interface dan pihole-FTL --config dns.listeningMode mencetak nilai efektif, dan nilai itu bisa berbeda dari berkas host ketika kontainer, variabel lingkungan, atau manajer penerapan memiliki pengaturan tersebut. Referensi konfigurasi Pi-hole FTL mencantumkan mode dan mana yang bergantung pada antarmuka.

LOCAL menanyakan subnet mana, SINGLE menanyakan antarmuka mana

LOCAL, mode bawaan, menjawab kueri yang alamat sumbernya termasuk subnet yang dikonfigurasi pada salah satu antarmuka host. wg0 sederhana dengan 10.90.0.1/24 lolos uji itu, karena klien di 10.90.0.2 berada di dalam subnet tunnel. Klien yang dirutekan di sisi lain peer, atau klien yang tersembunyi di balik NAT pada prefiks berbeda, tidak lolos, meskipun paket tiba di wg0, dan tidak ada kueri yang muncul di log.

SINGLE mengubah pertanyaannya. Ia menerima kueri yang tiba pada antarmuka yang dinamai di dns.interface, termasuk loopback, dan mengabaikan subnet sumber. Itulah mode yang bertahan pada topologi VPN berantai atau dirutekan. Setel kedua kunci bersama-sama, karena mode tanpa antarmuka bernama bukan instruksi lengkap:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND mengubah socket, dan itu ada biayanya

BIND tidak menyaring socket wildcard; ia mengikat port 53 hanya ke alamat yang ada pada antarmuka bernama, sehingga kernel menolak paket yang tiba di tempat lain. Ia lebih ketat daripada SINGLE dan bukan sinonimnya. Biayanya muncul saat boot: jika wg0 belum aktif saat FTL mulai, mungkin tidak ada alamat untuk diikat, dan resolver dapat berjalan tanpa pendengar sampai antarmuka muncul dan FTL dimulai ulang.

Pilih BIND ketika Anda mengendalikan urutan mulai, misalnya unit systemd yang diurutkan setelah antarmuka WireGuard, dan ketika Anda ingin kernel membuang paket nyasar sebelum FTL melihatnya. Pilih SINGLE ketika tunnel datang dan pergi, atau ketika antarmuka dibuat oleh alat yang mulai setelah FTL.

Firewall adalah gerbang kedua

Mode FTL yang benar tetap gagal jika firewall host membuang port 53 pada wg0. Izinkan rentang sumber VPN untuk kedua protokol dan biarkan sisi internet tertutup. Di nftables, dengan rantai input yang ada di tabel inet filter, aturannya tampak seperti ini:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Tambahkan aturan IPv6 yang sesuai jika tunnel membawa IPv6, dan letakkan sebelum kebijakan drop rantai. Jika host memakai ufw atau firewalld, nyatakan pencocokan yang sama di manajer itu alih-alih mencampur alat. Jangan meneruskan port 53 dari router internet; klien harus menjangkau alamat VPN resolver melalui tunnel.

Dua jalur tetap terpisah. Kueri klien berakhir di FTL. Pencarian upstream FTL sendiri keluar menurut tabel perutean host, yang mungkin memakai tunnel atau tidak, jadi resolver yang menjawab tetapi tidak mengembalikan apa pun yang berguna adalah masalah upstream. Admin web dan API mendengarkan pada port mereka sendiri dan memerlukan pembatasan sendiri.

Verifikasi jawaban dan penolakannya

Dari klien VPN, tanyakan alamat resolver melalui kedua protokol: dig @10.90.0.1 example.com dan dig +tcp @10.90.0.1 example.com. Lalu periksa log kueri di antarmuka admin untuk memastikan FTL mencatat kueri tersebut. Timeout klien tanpa entri log mengarah ke firewall atau filter antarmuka; entri log tanpa jawaban mengarah ke resolusi upstream.

Uji jalur negatif dari host di luar VPN. dig @10.90.0.1 example.com seharusnya timeout, dan ss -lunp pada resolver seharusnya tidak menampilkan port 53 terikat ke alamat publik. Mulai ulang layanan sekali, lalu reboot host dan pastikan resolver masih menjawab setelah wg0 muncul kembali. Kueri yang hanya berfungsi sampai reboot berikutnya bukan perubahan yang selesai.