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

Sebuah ponsel bergabung ke hotspot Pi, mendapat alamat, dan halamannya tetap gagal. Pi menjalankan pembantu hotspot, Pi-hole, dan klien VPN, dan masing-masing mengira memiliki sebagian jalur. Sebagian besar rakitan ini gagal bukan karena komponennya rusak, melainkan karena dua komponen mengerjakan tugas yang sama. Tetapkan satu pemilik per fungsi sebelum menyetel salah satunya.

Tetapkan satu pemilik per fungsi

Ada empat fungsi yang penting di sini, dan masing-masing butuh tepat satu pemilik. Tabel di bawah menyebutkan fungsinya, pemilik yang layak, dan apa yang salah ketika dua layanan mengklaimnya.

Tumpang tindih biasanya datang satu paket demi satu paket. Pembantu hotspot memasang instans dnsmasq-nya sendiri, Pi-hole menginginkan porta 53, dan klien VPN menambahkan rute. Tiap langkah tampak wajar sendiri-sendiri, dan bersama-sama menghasilkan mesin di mana layanan kedua yang mulai diam-diam mengubah perilaku layanan pertama.

Tuliskan pemiliknya sebelum mengaktifkan apa pun yang lain. Tabel singkat di catatan rakitan mencegah pemasangan berikutnya mengambil alih fungsi yang sudah punya pemilik.

Pilih satu rentang dan jauhkan dari tunnel

Pilih rentang hotspot, alamat Pi di dalamnya, kumpulan DHCP, dan resolver yang diterima klien. Jauhkan rentang itu dari LAN hulu dan dari rentang tunnel VPN, karena subnet yang tumpang tindih mengubah masalah perutean menjadi proyek penerjemahan alamat. Rentang yang tumpang tindih dengan tunnel membuat Pi menjadi router tak sengaja di antara dua prefiks yang identik. Tuliskan rentang dan kumpulan itu ke konfigurasi hotspot alih-alih membiarkannya pada nilai bawaan.

Jika mode shared NetworkManager yang memiliki hotspot, periksa koneksi efektifnya sebelum menambahkan server DHCP. Mode shared menjalankan pembantunya sendiri dan mengaktifkan penerusan, jadi ia sudah menjadi pemilik rencana alamat untuk antarmuka itu. Menambahkan server kedua karena tersedia menciptakan tawaran yang bersaing, bukan redundansi.

Putuskan IPv6 secara sengaja. Iklan router dan DHCPv6 di banyak penyiapan berasal dari pembantu yang berbeda dari DHCPv4, dan membiarkan IPv6 menyala sementara kebijakan VPN hanya mencakup IPv4 memberi klien jalur yang melewati tunnel. Rencanakan sisi IPv6 atau matikan di antarmuka hotspot dengan alasan tertulis.

Siapa yang sebenarnya menjawab di porta 53

Daftar setiap proses yang mendengarkan porta 53 sebelum mengubah konfigurasi. Pada Pi yang menjalankan stub resolver lokal, Pi-hole, dan pembantu berbagi, daftar pendengar adalah satu-satunya peta andal tentang siapa yang menjawab kueri:

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

Panduan antarmuka Pi-hole menjelaskan bahwa mode penerimaan yang dibatasi ke satu antarmuka masih dapat memakai soket wildcard dan membuang kedatangan di tempat lain. Itu tidak sama dengan hanya mengikat antarmuka terpilih, yaitu susunan yang dimaksud ketika layanan DNS lain harus berbagi mesin.

Dua proses biasanya tidak dapat mengikat alamat dan porta yang sama, meskipun SO_REUSEPORT dapat membuat pengikatan bersama berhasil; bahkan begitu, pendengar wildcard dapat mengambil kedatangan yang ditujukan untuk layanan yang lebih sempit. Pilih mode yang didokumentasikan untuk peran yang Anda inginkan dan mulai ulang layanannya dalam urutan yang dimaksud.

Jauhkan halaman administrasi Pi-hole dari jaringan hotspot. Klien membutuhkan resolver, bukan antarmuka web atau API yang dapat mengubah konfigurasi resolver.

Dua kaki DNS, satu kebijakan masing-masing

Kueri klien berjalan dari ponsel ke Pi, dan kueri terpisah berjalan dari Pi ke resolver hulunya. Aturan perutean yang cocok dengan lalu lintas hotspot yang diteruskan tidak otomatis berlaku untuk kaki kedua, karena Pi menghasilkan lalu lintas itu secara lokal. Jika VPN seharusnya membawa DNS, jalur lokal memerlukan kebijakannya sendiri.

Waspadai loop. Mengarahkan hulu Pi-hole ke alamat yang dilayani Pi sendiri, langsung atau melalui port-forward, menghasilkan kueri yang berputar sampai timeout. Beri ia hulu nyata atau forwarder bersyarat untuk domain yang tidak dapat dijawabnya.

Putuskan apa yang terjadi ketika tunnel putus. Kembali ke resolver lokal menjaga penjelajahan tetap hidup tetapi dapat membocorkan nama ke luar VPN; memblokir menjaga kebijakan tetap utuh dan mengubah gangguan menjadi kesalahan yang terlihat. Keduanya dapat dipertahankan, tetapi harus dipilih, bukan diwarisi dari nilai bawaan.

Buktikan jalur dan perilaku saat gangguan

Uji berlapis: klien mendapat alamat, klien me-resolve nama melalui Pi, Pi me-resolve melalui hulu yang dimaksud, dan aplikasi menyelesaikan permintaan. Ping yang berhasil tidak mengatakan apa pun tentang DNS, dan lookup yang berhasil tidak mengatakan apa pun tentang penerusan.

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

Lalu hentikan tunnel dan ulangi. Perilaku yang dimaksud seharusnya muncul dalam beberapa detik, bukan setelah memulai ulang Pi-hole atau layanan hotspot secara manual. Periksa pengaturan resolver klien selama gangguan, karena resolver publik sekunder akan terus menjawab meskipun kebijakan mengharapkan kegagalan.

Pertahankan satu pemilik untuk penerusan dan NAT dan verifikasi dari klien, bukan dari Pi itu sendiri. Permintaan yang keluar dari Pi dengan sukses masih bisa dibuang dalam perjalanan kembali, dan klien adalah satu-satunya tempat di mana seluruh jalur terlihat.