Klien hotspot di Pi tidak menjangkau LAN rumah lewat VPN TUN

Klien Wi-Fi dan Ethernet lokal tersambung ke hotspot Pi, mengambil alamat dari cakupan DHCP-nya, dan memuat halaman internet tanpa keluhan. Klien yang sama kemudian kehabisan waktu saat membuka berbagi berkas atau antarmuka web di LAN rumah, padahal Pi sendiri menjangkau LAN itu lewat terowongan. Tidak ada yang rusak di lapisan nirkabel. Yang kurang adalah kontrak terutekan: prefiks hotspot harus dibawa ke antarmuka TUN, dan sesuatu di sisi rumah harus tahu cara mengirim balasan kembali ke sana. Kedua belahan harus ada sebelum satu paket pun bisa menyelesaikan perjalanan pulang-pergi.

Tiga sambungan dengan tiga tugas berbeda

Jembatan Ethernet Linux meneruskan frame berdasarkan alamat MAC tujuan. OpenVPN dalam mode TUN membawa paket IP dan sama sekali tidak punya lapisan MAC, jadi menambahkan jembatan lokal tidak pernah mendaftarkan terowongan sebagai porta. dokumentasi kernel TUN/TAP menjelaskan pemisahan itu: perangkat TAP tampak seperti antarmuka Ethernet, perangkat TUN tidak. Rancangan yang menjembatani dua porta lokal lalu merutekan adalah perute, apa pun kata nama antarmukanya.

Pembedaan itu menentukan kepemilikan. Subnet klien, gerbang default mereka, dan wewenang DHCP untuk cakupan itu milik rencana lokal Pi. Siaran DHCP rumah tidak menyeberangi terowongan terutekan, dan tidak ada pengaturan jembatan yang mengubahnya; mengarahkan klien ke server DHCP rumah adalah rancangan relai terpisah dan sengaja dengan mode kegagalannya sendiri.

Jauhkan modem dari jembatan klien juga. Sambungan PPP bukan perangkat Ethernet dengan label lain, dan logika rute default pppd yang terdokumentasi berjalan setelah negosiasi IPCP dan menarik rutenya saat tautan itu putus. Menyalin templat DHCP dan mengganti nama setiap usb0 menjadi ppp0 tidak membuktikan apa pun tentang gerbang, metrik, atau siklus hidup.

Pilih prefiksnya sebelum Anda menyunting konfigurasi apa pun

Prefiks yang bertumpuk menghabiskan lebih banyak malam daripada aturan firewall, karena tumpang tindih mengirim pencarian rute ke antarmuka yang salah bahkan saat terowongan sehat. Mulailah dengan mendaftar apa yang sudah ada di Pi, lalu baca hasilnya sebagai empat kumpulan terpisah.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Kumpulan pertama adalah alamat underlay yang diberikan operator ke modem; alamat itu harus tetap di luar setiap rencana yang menghadap klien. Yang kedua adalah subnet terowongan yang dipilih server, sering kali /24 privat miliknya sendiri. Yang ketiga adalah jembatan hotspot, dan yang keempat adalah prefiks rumah yang ingin Anda jangkau. Dalam penelusuran ini hotspot mendapat 172.28.90.0/24 dengan jembatan di 172.28.90.1, dan LAN layanan rumah mempertahankan 192.168.77.0/24, yang menghindari default 192.168.1.0/24 dan 10.0.0.0/24 bawaan perute konsumen serta rentang operator 100.64.0.0/10.

Umumkan alamat jembatan sebagai gerbang di cakupan DHCP hotspot dan tidak lebih. Jangan pernah memberi klien hotspot alamat rumah sebagai gerbang; mereka tidak punya jalur lapisan tautan ke segmen itu.

Rutekan setiap arah di sisi yang memilikinya

Pi memerlukan rute untuk prefiks rumah lewat terowongan. Server dalam mode server biasanya mendorong rute itu, jadi pastikan dulu penerusan aktif dan kernel menyelesaikan alamat rumah dari tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Jika ip route get masih melaporkan antarmuka underlay, berhenti di situ; tidak ada yang lebih jauh di jalur dapat memperbaiki pencarian yang salah.

Perangkat rumah tidak punya rute ke 172.28.90.0/24, jadi balasannya mengikuti gerbang default dan mati di perute. Ada dua perbaikan yang didukung. Entah tambahkan rute statis di perute rumah yang mengarahkan prefiks hotspot ke alamat LAN server VPN, atau, saat server itu sendiri adalah gerbang, daftarkan prefiks klien di tabel perutean server itu sendiri. Dalam mode banyak klien OpenVPN, direktori khusus klien membawa asosiasi itu: berkas bernama sesuai nama umum sertifikat klien, berisi iroute 172.28.90.0 255.255.255.0 plus baris route yang cocok yang memasangnya di kernel server. Rute kernel yang ditebak di server bukan pernyataan yang sama dengan memberi tahu server klien mana yang memiliki prefiks.

Jangan pindahkan layanan DHCP jaringan rumah ke server VPN agar ini berfungsi. Mengganti gerbang default untuk seluruh rumah adalah perubahan yang jauh lebih besar daripada menambahkan satu rute balik privat, dan itu menyeret DNS, reservasi alamat, dan setiap perangkat yang mengabaikan sewa baru ke dalam kegagalan.

Buka penerusan tanpa menebak-nebak firewall

Penerusan yang aktif tidak berarti paket diizinkan lewat. Lalu lintas dari jembatan ke terowongan tetap menabrak aturan penyaringan, dan kebijakan penerusan default drop membuang lalu lintas hotspot sementara lalu lintas Pi sendiri tetap berjalan, yang menghasilkan persis gejala terbelah di atas.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Cari aturan terima dari br0 ke tun0 dan arah balasan yang cocok, serta aturan postrouting yang mungkin menulis ulang sumber. Jika kebijakan rantai adalah drop dan tidak ada aturan yang cocok, tambahkan penerimaan sempit dan uji ulang alih-alih membalik kebijakan menjadi accept.

Penerjemahan adalah pilihan kebijakan, bukan keharusan. NAT sumber ke LAN rumah membuat setiap klien hotspot tampak seperti alamat terowongan Pi, yang menghilangkan atribusi per klien di log rumah dan merusak layanan yang mengharapkan sumber asli. Perutean tanpa NAT menjaga alamat klien tetap terlihat tetapi bergantung pada rute balik di atas. Pilih satu dan tangani DNS serta IPv6 dengan cara yang sama, karena jalur IPv4 yang berfungsi di samping jalur IPv6 yang rusak tetap terbaca setengah rusak di peramban.

Verifikasi perjalanan pulang-pergi, lalu rusak dengan sengaja

Uji dari klien hotspot, jangan pernah dari Pi, karena lalu lintas Pi sendiri melewati jalur maju dan jalur balik. Amati kedua antarmuka saat satu klien mencoba menjangkau layanan rumah.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Baca kedua tangkapan bersama. Permintaan di br0 yang tidak pernah muncul di tun0 berarti Pi tidak meneruskan atau rutenya menunjuk ke tempat lain. Permintaan di tun0 tanpa balasan berarti sisi rumah tidak punya rute balik atau server menyaring paket. Balasan di tun0 yang tidak pernah muncul lagi di br0 berarti aturan saring terbalik hilang, saat terowongan tampak sempurna dan klien tetap tidak melihat apa pun.

Lalu rusak jalurnya dengan sengaja. Turunkan sambungan modem dan naikkan lagi serta jalankan ulang pemeriksaan rute dan tangkapan; rute yang bertahan melewati terowongan tetapi hilang saat menyambung ulang termasuk dalam profil sambungan, bukan perintah sekali pakai. Pastikan transport terowongan masih keluar lewat underlay dan bukan lewat dirinya sendiri, lingkaran klasik saat rute default yang didorong diterima tanpa rute host ke rekan.

Terima rancangan hanya ketika klien hotspot dapat menyelesaikan nama rumah, membuka layanan TCP, dan menjaga sesi tetap hidup melewati satu penyambungan ulang modem. Jika aplikasi benar-benar memerlukan penemuan tingkat Ethernet di segmen rumah, pilih rancangan Layer 2 yang didukung alih-alih menyebut jembatan lokal sebagai terjembatani dan menunggu siaran muncul.