Halakan klien OpenVPN ke penyelesai Pi-hole pada hos lain

Meletakkan alamat Pi-hole dalam profil OpenVPN tidak mencipta laluan ke sana, tidak memberi kebenaran untuk menanyanya dan tidak menjamin klien akan menggunakannya. Apabila Pi-hole berada pada mesin LAN berasingan, empat perkara mesti selaras: laluan dari klien, penghantaran dari get laluan, laluan balik ke kolam dan dasar penerimaan pada Pi-hole itu sendiri. Setiap kegagalan kelihatan berbeza dalam log. Menanganinya mengikut urutan itu lebih pantas daripada membaiki yang terakhir dahulu. Jalan pintas biasa, membuka rekursi untuk setiap asal, menukar masalah kecil dengan masalah kekal.

Apa yang dilakukan dan tidak dilakukan pilihan DNS yang dihantar

Pelayan mengumumkan penyelesai dengan arahan di bawah, dengan andaian 192.168.50.53 ialah hos Pi-hole. Klien menerima pilihan itu dan, bergantung pada platform dan integrasi penyelesai , menerapkannya pada antara muka terowong atau mengabaikannya demi stub tempatan. Baris laluan sama pentingnya dengan baris DNS, kerana penyelesai yang tidak dapat dicapai klien bukanlah penyelesai sama sekali. Tiada satu pun daripada ini kelihatan dari sisi pelayan.

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 pilihan bukan sama dengan menggunakannya. Klien Linux dengan pengurus penyelesai mungkin menerima pelayan yang dihantar dan hanya menghantar domain tertentu kepadanya; klien yang mengurus DNS sendiri mungkin menulis ganti tetapan sepenuhnya. Laluan yang dihantar juga terhad pada sesetengah platform, yang menjadikan penyelesai tidak dapat dicapai walaupun pilihan diterima. Periksa pada klien pelayan mana yang menjawab, bukan pada pelayan apa yang dihantar.

Pilihan itu juga tidak mengatakan apa-apa tentang sisi pelayan. Trafik DNS masih mesti bergerak dari klien ke get laluan dan dari get laluan ke Pi-hole sebelum apa-apa pilihan bermakna. Laluan yang hilang dan pertanyaan yang ditolak kelihatan sama dari klien, jadi sahkan dahulu penghantaran pada get laluan.

Laluan balik dari Pi-hole ke kolam

Jika alamat sumber klien dikekalkan, Pi-hole membalas ke alamat dalam kolam VPN. Jadual laluannya sendiri mungkin tidak tahu apa-apa tentang kolam itu, jadi balasan pergi ke get laluan lalainya dan hilang. Log pertanyaan menunjukkan permintaan tanpa balasan yang sepadan, yang mudah disalah tafsir sebagai masalah tembok api.

Beri penghala LAN laluan statik untuk kolam dengan get laluan OpenVPN sebagai hop seterusnya, atau terjemahkan sumber pada get laluan sebelum menghantar ke Pi-hole. Yang pertama mengekalkan alamat setiap klien kelihatan dalam log pertanyaan Pi-hole. Yang kedua menghapuskan syarat laluan balik tetapi menjadikan setiap pertanyaan kelihatan datang dari get laluan. Kedua-duanya tidak salah; ia menjawab soalan berbeza.

Jika pelaporan atau dasar setiap klien penting, laluan statik ialah pertukaran yang lebih baik. Jika LAN diurus oleh orang lain dan tiada laluan tersedia, penterjemahan ialah pilihan pragmatik, dengan kehilangan identiti klien dicatat. Catat mana yang anda pilih, kerana setiap soalan log kemudiannya bergantung padanya.

Mod mendengar Pi-hole untuk klien yang dihalakan

Menu lungsur tingkah laku mendengar antara muka pada halaman tetapan di bawah DNS menentukan sumber mana yang dijawab Pi-hole. Pilihan paling ketat hanya menerima klien pada rangkaian yang bersambung terus; pilihan yang membenarkan peranti paling jauh satu hop memperluaskannya kepada subrangkaian di belakang penghala bersebelahan, dan klien VPN yang dihalakan kelihatan tepat seperti itu. Paket memang tiba pada antara muka LAN, tetapi alamat sumbernya milik subrangkaian lain. Ini penolakan dasar, bukan kegagalan laluan, dan perbezaannya penting apabila membaca log.

Panduan mendengar Pi-hole memisahkan sumber yang bersambung setempat daripada asal yang dihalakan, dan antara muka ketibaan bukan kayu ukur. Pilih mod yang membenarkan kolam VPN tanpa membenarkan seluruh internet, kemudian padankan dengan peraturan tembok api yang menerima DNS hanya daripada kolam.

Membuka rekursi untuk semua asal supaya pertanyaan pertama berjaya ialah pembaikan yang salah. Ia menjadikan penyelesai peribadi menjadi terbuka, dan pembetulannya ialah kebenaran terhad, bukan global.

Padankan balasan dengan log pertanyaan

Tanya klien, kemudian periksa pelayan dan bandingkan kedua-duanya. Pada klien systemd-resolved, arahan di bawah melaporkan penyelesai mana yang menghasilkan balasan dan pelayan mana yang dikonfigurasi setiap pautan. Gunakan nama yang hanya diketahui Pi-hole, kerana pertanyaan terus ke alamat Pi-hole membuktikan ketercapaian, bukan konfigurasi.

resolvectl query intranet.example.lan
resolvectl dns

Balasan yang dijangka menamakan 192.168.50.53 sebagai pelayan dan mengembalikan alamat yang hanya diketahui penyelesai itu. Kemudian lihat paparan Pi-hole sendiri: pihole -t mengikuti log pertanyaan secara langsung, dan setiap baris membawa alamat sumber. Jika sumbernya alamat terowong klien, laluan kolam utuh. Jika alamat LAN get laluan, penterjemahan sumber sedang berjalan dan alamat klien sendiri tidak akan pernah muncul.

Jika tiada apa-apa muncul dalam log, pertanyaan tidak pernah sampai ke Pi-hole dan perkara seterusnya yang perlu diperiksa ialah penghantaran pada get laluan. Jika pertanyaan muncul tetapi tiada balasan kembali, masalahnya ialah laluan balik, iaitu bahagian sebelumnya. Membahagikan kegagalan seperti ini menghalang kesilapan laluan disangka peraturan tembok api.

Periksa peraturan penghantaran get laluan

Get laluan mesti menghantar paket DNS klien ke arah Pi-hole, dan peraturan yang melakukannya wajar dibaca, bukan diandaikan. Arahan di bawah menyenaraikan peraturan yang menyentuh port 53 bersama pengira, pada hos nftables dan pada hos iptables. Peraturan yang wujud tetapi menunjukkan sifar padanan ialah tanda bahawa trafik dibuang sebelum diterjemahkan.

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

Baca pengira, bukan hanya peraturan. Peraturan yang tidak pernah sepadan bermakna paket keluar melalui antara muka lain, atau klien tidak pernah menghantarnya. Peraturan yang sepadan pada setiap pertanyaan bermakna penghantaran berfungsi dan masalahnya lebih jauh di sepanjang laluan.

Apa jua alat yang digunakan hos, kekalkan pemeriksaan sempit: kolam sebagai sumber, port 53 sebagai destinasi dan Pi-hole sebagai satu-satunya sasaran yang dibenarkan. Peraturan penghantaran luas yang juga membenarkan port 80 ialah masalah lain yang menunggu berlaku.