Hotspot Pi dengan Pi-hole dan VPN: beri setiap perkhidmatan satu tugas

Telefon menyertai hotspot Pi, mendapat alamat, dan halaman itu masih gagal. Pi menjalankan pembantu hotspot, Pi-hole dan klien VPN, dan setiap satu menyangka ia memiliki sebahagian laluan. Kebanyakan binaan ini gagal bukan kerana komponen rosak, tetapi kerana dua komponen melakukan kerja yang sama. Tetapkan satu pemilik bagi setiap fungsi sebelum menala mana-mana daripadanya.

Tetapkan satu pemilik bagi setiap fungsi

Terdapat empat fungsi yang penting di sini, dan setiap satu memerlukan tepat satu pemilik. Jadual di bawah menyenaraikan fungsi, pemilik yang boleh dilaksanakan dan apa yang berlaku apabila dua perkhidmatan menuntutnya.

Pertindihan biasanya datang satu paket pada satu masa. Pembantu hotspot memasang contoh dnsmasq sendiri, Pi-hole mahukan port 53, dan klien VPN menambah laluan. Setiap langkah kelihatan munasabah secara berasingan, dan bersama-sama menghasilkan mesin di mana perkhidmatan kedua yang bermula secara senyap mengubah tingkah laku yang pertama.

Tuliskan pemilik sebelum mengaktifkan apa-apa lagi. Jadual pendek dalam nota binaan menghalang pemasangan kemudian daripada mengambil alih fungsi yang sudah mempunyai pemilik.

Pilih satu julat dan jauhkannya daripada terowong

Pilih julat hotspot, alamat Pi di dalamnya, kolam DHCP dan resolver yang diterima klien. Jauhkan julat itu daripada LAN huluan dan daripada julat terowong VPN, kerana subnet yang bertindih menjadikan masalah penghalaan sebagai projek terjemahan alamat. Julat yang bertindih dengan terowong menjadikan Pi penghala tidak sengaja antara dua awalan yang sama. Tulis julat dan kolam itu ke dalam konfigurasi hotspot dan bukannya membiarkannya pada nilai lalai.

Jika mod berkongsi NetworkManager memiliki hotspot, periksa sambungan berkesan sebelum menambah pelayan DHCP. Mod berkongsi memulakan pembantunya sendiri dan mengaktifkan penghantaran, jadi ia sudah menjadi pemilik pelan alamat bagi antara muka itu. Menambah pelayan kedua kerana ia tersedia mencipta tawaran bersaing dan bukan redundansi.

Tentukan IPv6 secara sengaja. Pengiklanan penghala dan DHCPv6 dalam banyak persediaan datang daripada pembantu yang berbeza daripada DHCPv4, dan membiarkan IPv6 hidup sementara dasar VPN hanya meliputi IPv4 memberi klien laluan yang memintas terowong. Sama ada rancang bahagian IPv6 atau nyahdayakannya pada antara muka hotspot dengan alasan bertulis.

Siapa yang sebenarnya menjawab pada port 53

Senaraikan setiap proses yang mendengar pada port 53 sebelum mengubah konfigurasi. Pada Pi yang menjalankan stub resolver tempatan, Pi-hole dan pembantu perkongsian, senarai pendengar ialah satu-satunya peta yang boleh dipercayai tentang siapa yang menjawab pertanyaan:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

Panduan antara muka Pi-hole menjelaskan bahawa mod penerimaan yang terhad kepada satu antara muka masih boleh menggunakan soket wildcard dan membuang ketibaan di tempat lain. Itu bukan sama dengan hanya mengikat antara muka terpilih, iaitu susunan yang dimaksudkan apabila perkhidmatan DNS lain perlu berkongsi mesin.

Dua proses biasanya tidak boleh mengikat alamat dan port yang sama, walaupun SO_REUSEPORT boleh membuat pengikatan berkongsi berjaya; walaupun begitu, pendengar wildcard boleh mengambil ketibaan yang ditujukan untuk perkhidmatan yang lebih sempit. Pilih mod yang didokumenkan untuk peranan yang anda mahu dan mulakan semula perkhidmatan dalam urutan yang dimaksudkan.

Jauhkan halaman pentadbiran Pi-hole daripada rangkaian hotspot. Klien memerlukan resolver, bukan antara muka web atau API yang boleh mengubah konfigurasi resolver.

Dua kaki DNS, satu dasar setiap satu

Pertanyaan klien bergerak dari telefon ke Pi, dan pertanyaan berasingan bergerak dari Pi ke resolver huluannya. Peraturan penghalaan yang sepadan dengan trafik hotspot yang dihantar tidak terpakai secara automatik pada kaki kedua, kerana Pi menjana trafik itu secara tempatan. Jika VPN sepatutnya membawa DNS, laluan tempatan memerlukan dasarnya sendiri.

Awas gelung. Menghalakan hulu Pi-hole ke alamat yang dilayan oleh Pi sendiri, secara langsung atau melalui port-forward, menghasilkan pertanyaan yang berputar sehingga tamat masa. Berikannya hulu sebenar atau penghantar bersyarat untuk domain yang tidak dapat dijawabnya.

Tentukan apa yang berlaku apabila terowong terputus. Kembali ke resolver tempatan mengekalkan pelayaran tetapi boleh membocorkan nama di luar VPN; menyekat mengekalkan dasar itu utuh dan menjadikan gangguan itu sebagai ralat yang kelihatan. Kedua-dua pilihan boleh dipertahankan, tetapi ia mesti dipilih dan bukan diwarisi daripada nilai lalai.

Buktikan laluan dan tingkah laku semasa gangguan

Uji secara berlapis: klien mendapat alamat, klien menyelesaikan nama melalui Pi, Pi menyelesaikan melalui hulu yang dimaksudkan, dan aplikasi menyelesaikan permintaan. Ping yang berjaya tidak memberitahu apa-apa tentang DNS, dan carian yang berjaya tidak memberitahu apa-apa tentang penghantaran.

dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1

Kemudian hentikan terowong dan ulangi. Tingkah laku yang dimaksudkan sepatutnya muncul dalam beberapa saat, bukan selepas memulakan semula Pi-hole atau perkhidmatan hotspot secara manual. Periksa tetapan resolver klien semasa gangguan, kerana resolver awam sekunder akan terus menjawab walaupun dasar itu menjangka kegagalan.

Kekalkan satu pemilik untuk penghantaran dan NAT dan sahkan daripada klien, bukan daripada Pi itu sendiri. Permintaan yang keluar daripada Pi dengan jayanya masih boleh digugurkan dalam perjalanan balik, dan klien ialah satu-satunya tempat di mana seluruh laluan kelihatan.