Mengapa Pi-hole v6 mengabaikan pertanyaan DNS daripada klien WireGuard

Pi-hole v6 menerima pertanyaan DNS pada port 53 dan kemudian memutuskan sama ada paket yang tiba boleh dijawab. Pada hos WireGuard keputusan kedua itu biasanya menjadi sebab klien menerima tamat masa manakala penyelesai kelihatan sihat dari LAN. Port terbuka, FTL berjalan, namun tiada apa-apa kembali dari 10.90.0.1. Tiga perkara saling mempengaruhi sebelum jawapan keluar: dns.interface, dns.listeningMode dan tembok api di hadapan kedua-duanya.

Soket pendengar tidak menentukan siapa yang mendapat jawapan

FTL membuka pendengar UDP dan TCP pada port 53. Dalam konfigurasi lalai soket selalunya wildcard, jadi ss -lunp | grep :53 memaparkan 0.0.0.0:53 dan [::]:53 sama ada klien VPN dilayan atau tidak. Soket wildcard menerima paket itu, kemudian FTL menggunakan peraturan antara muka dan sumbernya sebelum menjawab. Itulah sebabnya "port sedang mendengar" hampir tidak membuktikan apa-apa tentang klien terowong.

Baca konfigurasi yang berjalan, bukan fail yang anda anggap aktif. pihole-FTL --config dns.interface dan pihole-FTL --config dns.listeningMode mencetak nilai berkesan, dan nilai itu boleh berbeza daripada fail hos apabila kontena, pemboleh ubah persekitaran atau pengurus penggunaan memiliki tetapan tersebut. Rujukan konfigurasi Pi-hole FTL menyenaraikan mod dan yang mana bergantung pada antara muka.

LOCAL bertanya subnet mana, SINGLE bertanya antara muka mana

LOCAL, mod lalai, menjawab pertanyaan yang alamat sumbernya tergolong dalam subnet yang dikonfigurasi pada salah satu antara muka hos. wg0 ringkas dengan 10.90.0.1/24 lulus ujian itu, kerana klien pada 10.90.0.2 berada di dalam subnet terowong. Klien yang dihalakan di sebelah sana rakan sebaya, atau klien yang tersembunyi di sebalik NAT dalam awalan lain, tidak lulus, walaupun paket tiba di wg0, dan tiada pertanyaan muncul dalam log.

SINGLE mengubah soalan. Ia menerima pertanyaan yang tiba pada antara muka yang dinamakan dalam dns.interface, termasuk loopback, dan mengabaikan subnet sumber. Itulah mod yang bertahan dalam topologi VPN berantai atau dihalakan. Tetapkan kedua-dua kunci bersama-sama, kerana mod tanpa antara muka bernama bukan arahan lengkap:

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

BIND mengubah soket, dan itu ada harganya

BIND tidak menapis soket wildcard; ia mengikat port 53 hanya kepada alamat yang wujud pada antara muka bernama, jadi kernel menolak paket yang tiba di tempat lain. Ia lebih ketat daripada SINGLE dan bukan sinonimnya. Harganya muncul semasa but: jika wg0 tidak aktif apabila FTL bermula, mungkin tiada alamat untuk diikat, dan penyelesai boleh berjalan tanpa pendengar sehingga antara muka muncul dan FTL dimulakan semula.

Pilih BIND apabila anda mengawal urutan permulaan, contohnya unit systemd yang disusun selepas antara muka WireGuard, dan apabila anda mahu kernel membuang paket sesat sebelum FTL melihatnya. Pilih SINGLE apabila terowong datang dan pergi, atau apabila antara muka dicipta oleh alat yang bermula selepas FTL.

Tembok api ialah pintu kedua

Mod FTL yang betul masih gagal jika tembok api hos membuang port 53 pada wg0. Benarkan julat sumber VPN untuk kedua-dua protokol dan biarkan bahagian internet tertutup. Dalam nftables, dengan rantai input sedia ada dalam jadual inet filter, peraturannya kelihatan 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

Tambah peraturan IPv6 yang sepadan jika terowong membawa IPv6, dan letakkan sebelum dasar drop rantai. Jika hos menggunakan ufw atau firewalld, nyatakan padanan yang sama dalam pengurus itu dan bukannya mencampurkan alat. Jangan majukan port 53 dari penghala internet; klien harus mencapai alamat VPN penyelesai melalui terowong.

Dua laluan kekal berasingan. Pertanyaan klien berakhir di FTL. Carian huluan FTL sendiri keluar mengikut jadual penghalaan hos, yang mungkin menggunakan terowong atau tidak, jadi penyelesai yang menjawab tetapi tidak memulangkan apa-apa yang berguna ialah masalah huluan. Pentadbir web dan API mendengar pada port mereka sendiri dan memerlukan sekatan sendiri.

Sahkan jawapan dan penolakan

Dari klien VPN, tanya alamat penyelesai melalui kedua-dua protokol: dig @10.90.0.1 example.com dan dig +tcp @10.90.0.1 example.com. Kemudian semak log pertanyaan dalam antara muka pentadbir untuk mengesahkan FTL merekodkan pertanyaan itu. Tamat masa klien tanpa entri log menunjuk kepada tembok api atau penapis antara muka; entri log tanpa jawapan menunjuk kepada penyelesaian huluan.

Uji laluan negatif dari hos di luar VPN. dig @10.90.0.1 example.com sepatutnya tamat masa, dan ss -lunp pada penyelesai sepatutnya tidak menunjukkan port 53 terikat pada alamat awam. Mulakan semula perkhidmatan sekali, kemudian but semula hos dan sahkan penyelesai masih menjawab selepas wg0 muncul semula. Pertanyaan yang hanya berfungsi sehingga but semula seterusnya bukan perubahan yang selesai.