Arahkan klien OpenVPN ke resolver Pi-hole di host lain

Menaruh alamat Pi-hole di profil OpenVPN tidak membuat jalur ke sana, tidak memberi izin untuk menanyakannya, dan tidak menjamin klien akan memakainya. Ketika Pi-hole berada di mesin LAN terpisah, empat hal harus selaras: rute dari klien, penerusan dari gateway, jalur balik ke pool, dan kebijakan penerimaan di Pi-hole itu sendiri. Setiap kegagalan tampak berbeda di log. Menanganinya dalam urutan itu lebih cepat daripada memperbaiki yang terakhir lebih dulu. Jalan pintas yang biasa, membuka rekursi untuk semua asal, menukar masalah kecil dengan masalah permanen.

Apa yang dilakukan dan tidak dilakukan opsi DNS yang didorong

Server mengumumkan resolver dengan direktif di bawah, dengan asumsi 192.168.50.53 adalah host Pi-hole. Klien menerima opsi itu dan, bergantung pada platform dan integrasi resolver , menerapkannya ke antarmuka tunnel atau mengabaikannya demi stub lokal. Baris rute sama pentingnya dengan baris DNS, karena resolver yang tidak dapat dijangkau klien bukanlah resolver sama sekali. Tidak ada dari ini yang terlihat dari sisi server.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Menerima opsi tidak sama dengan memakainya. Klien Linux dengan manajer resolver mungkin menerima server yang didorong dan hanya mengirim domain tertentu ke sana; klien yang mengelola DNS sendiri dapat menimpa pengaturan sepenuhnya. Rute yang didorong juga dibatasi di beberapa platform, sehingga resolver tetap tak terjangkau meskipun opsi diterima. Periksa di klien server mana yang menjawab, bukan di server apa yang dikirim.

Opsi itu juga tidak mengatakan apa pun tentang sisi server. Lalu lintas DNS tetap harus berjalan dari klien ke gateway dan dari gateway ke Pi-hole sebelum opsi apa pun berarti. Rute yang hilang dan kueri yang ditolak terlihat sama dari klien, jadi pastikan dulu penerusan di gateway.

Jalur balik dari Pi-hole ke pool

Jika alamat sumber klien dipertahankan, Pi-hole membalas ke alamat di dalam pool VPN. Tabel rutnya sendiri mungkin tidak tahu apa-apa tentang pool itu, jadi balasan pergi ke gateway defaultnya dan hilang. Log kueri menunjukkan permintaan tanpa balasan yang cocok, yang mudah disalahartikan sebagai masalah firewall.

Beri router LAN rute statis untuk pool dengan gateway OpenVPN sebagai hop berikutnya, atau terjemahkan sumber di gateway sebelum meneruskan ke Pi-hole. Yang pertama menjaga alamat tiap klien tetap terlihat di log kueri Pi-hole. Yang kedua menghapus syarat rute balik tetapi membuat setiap kueri tampak datang dari gateway. Keduanya tidak salah; keduanya menjawab pertanyaan berbeda.

Jika pelaporan atau kebijakan per klien penting, rute statis adalah pertukaran yang lebih baik. Jika LAN dikelola orang lain dan rute tidak tersedia, penerjemahan adalah pilihan pragmatis, dengan hilangnya identitas klien dicatat. Catat mana yang Anda pilih, karena setiap pertanyaan log berikutnya bergantung padanya.

Mode mendengarkan Pi-hole untuk klien yang dirutekan

Dropdown perilaku mendengarkan antarmuka di halaman pengaturan pada bagian DNS menentukan sumber mana yang dijawab Pi-hole. Opsi terketat hanya menerima klien di jaringan yang terhubung langsung; opsi yang mengizinkan perangkat paling jauh satu hop memperluasnya ke subnet di belakang router tetangga, dan klien VPN yang dirutekan tampak persis seperti itu. Paket memang tiba di antarmuka LAN, tetapi alamat sumbernya milik subnet lain. Ini penolakan kebijakan, bukan kegagalan rut, dan perbedaannya penting saat membaca log.

Panduan mendengarkan Pi-hole memisahkan sumber yang terhubung lokal dari asal yang dirutekan, dan antarmuka kedatangan bukan patokannya. Pilih mode yang mengizinkan pool VPN tanpa mengizinkan seluruh internet, lalu padukan dengan aturan firewall yang menerima DNS hanya dari pool.

Membuka rekursi untuk semua asal agar kueri pertama berhasil adalah perbaikan yang salah. Itu mengubah resolver privat menjadi terbuka, dan perbaikannya adalah izin terbatas, bukan global.

Cocokkan balasan dengan log kueri

Tanyakan ke klien, lalu periksa server, dan bandingkan keduanya. Pada klien systemd-resolved, perintah di bawah melaporkan resolver mana yang menghasilkan balasan dan server mana yang dikonfigurasi per tautan. Gunakan nama yang hanya diketahui Pi-hole, karena kueri langsung ke alamat Pi-hole membuktikan keterjangkauan, bukan konfigurasi.

resolvectl query intranet.example.lan
resolvectl dns

Balasan yang diharapkan menyebut 192.168.50.53 sebagai server dan mengembalikan alamat yang hanya diketahui resolver itu. Lalu lihat tampilan Pi-hole sendiri: pihole -t mengikuti log kueri secara langsung, dan setiap baris membawa alamat sumber. Jika sumbernya alamat tunnel klien, rute pool utuh. Jika alamat LAN gateway, penerjemahan sumber sedang berjalan dan alamat klien sendiri tidak akan pernah muncul.

Jika tidak ada apa pun di log, kueri tidak pernah sampai ke Pi-hole dan hal berikut yang harus diperiksa adalah penerusan di gateway. Jika kueri muncul tetapi tidak ada balasan kembali, masalahnya jalur balik, yaitu bagian sebelumnya. Membagi kegagalan seperti ini mencegah kesalahan rut disangka aturan firewall.

Periksa aturan penerusan gateway

Gateway harus meneruskan paket DNS klien ke arah Pi-hole, dan aturan yang melakukannya layak dibaca, bukan diasumsikan. Perintah di bawah mendaftar aturan yang menyentuh port 53 beserta penghitungnya, pada host nftables dan pada host iptables. Aturan yang ada tetapi menunjukkan nol kecocokan adalah tanda bahwa lalu lintas dibuang sebelum diterjemahkan.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Baca penghitungnya, bukan hanya aturannya. Aturan yang tidak pernah cocok berarti paket keluar lewat antarmuka lain, atau klien tidak pernah mengirimnya. Aturan yang cocok pada setiap kueri berarti penerusan bekerja dan masalahnya lebih jauh di sepanjang jalur.

Alat apa pun yang dipakai host, jaga pemeriksaan tetap sempit: pool sebagai sumber, port 53 sebagai tujuan, dan Pi-hole sebagai satu-satunya target yang diizinkan. Aturan penerusan lebar yang juga mengizinkan port 80 adalah masalah lain yang menunggu terjadi.