Klien hotspot pada Pi tidak dapat mencapai LAN rumah melalui VPN TUN

Klien Wi-Fi dan Ethernet setempat menyambung ke hotspot Pi, mengambil alamat daripada julat DHCPnya dan memuatkan halaman internet tanpa rungutan. Klien yang sama kemudian tamat masa apabila membuka perkongsian fail atau antara muka web pada LAN rumah, sedangkan Pi sendiri mencapai LAN itu melalui terowong. Tiada apa-apa dalam lapisan wayarles yang rosak. Yang hilang ialah kontrak berhalakan: awalan hotspot mesti dibawa ke antara muka TUN, dan sesuatu di sebelah rumah mesti tahu cara menghantar balasan kembali ke sana. Kedua-dua bahagian mesti wujud sebelum satu paket dapat melengkapkan perjalanan pergi dan balik.

Tiga sambungan dengan tiga tugas berbeza

Jambatan Ethernet Linux memajukan bingkai mengikut alamat MAC destinasi. OpenVPN dalam mod TUN membawa paket IP dan langsung tidak mempunyai lapisan MAC, jadi menambah jambatan setempat tidak pernah mendaftarkan terowong sebagai port. dokumentasi kernel TUN/TAP menjelaskan pemisahan itu: peranti TAP kelihatan seperti antara muka Ethernet, peranti TUN tidak. Reka bentuk yang menjambatani dua port setempat dan kemudian menghalakan ialah penghala, apa pun kata nama antara muka.

Perbezaan itu menentukan pemilikan. Subnet klien, get laluan lalai mereka dan kuasa DHCP untuk julat itu tergolong dalam pelan setempat Pi. Siaran DHCP rumah tidak melintasi terowong berhalakan, dan tiada tetapan jambatan mengubahnya; menghalakan klien ke pelayan DHCP rumah ialah reka bentuk geganti berasingan dan sengaja dengan mod kegagalannya sendiri.

Jauhkan modem daripada jambatan klien juga. Sambungan PPP bukan peranti Ethernet dengan label lain, dan logik laluan lalai pppd yang didokumenkan berjalan selepas rundingan IPCP dan menarik balik laluannya apabila pautan itu gagal. Menyalin templat DHCP dan menamakan semula setiap usb0 kepada ppp0 tidak membuktikan apa-apa tentang get laluan, metrik atau kitaran hayat.

Pilih awalan sebelum anda mengedit sebarang konfigurasi

Awalan bertindih membazirkan lebih banyak malam daripada peraturan firewall, kerana pertindihan menghantar carian laluan ke antara muka yang salah walaupun terowong sihat. Mulakan dengan menyenaraikan apa yang sudah ada pada Pi, kemudian baca hasilnya sebagai empat kolam berasingan.

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

Kolam pertama ialah alamat underlay yang diberikan operator kepada modem; ia mesti kekal di luar setiap pelan yang menghadap klien. Yang kedua ialah subnet terowong yang dipilih pelayan, selalunya /24 peribadi miliknya sendiri. Yang ketiga ialah jambatan hotspot, dan yang keempat ialah awalan rumah yang ingin anda capai. Dalam panduan ini hotspot mendapat 172.28.90.0/24 dengan jambatan pada 172.28.90.1, dan LAN perkhidmatan rumah mengekalkan 192.168.77.0/24, yang mengelakkan lalai 192.168.1.0/24 dan 10.0.0.0/24 yang dibawa penghala pengguna serta julat operator 100.64.0.0/10.

Umumkan alamat jambatan sebagai get laluan dalam julat DHCP hotspot dan tiada yang lain. Jangan sekali-kali memberi klien hotspot alamat rumah sebagai get laluan; mereka tiada laluan lapisan pautan ke segmen itu.

Halakan setiap arah di sebelah yang memilikinya

Pi memerlukan laluan untuk awalan rumah melalui terowong. Pelayan dalam mod pelayan biasanya menolak laluan itu, jadi sahkan dahulu pemajuan dihidupkan dan kernel menyelesaikan alamat rumah daripada 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 antara muka underlay, berhenti di situ; tiada apa-apa lebih jauh di laluan boleh membaiki carian yang salah.

Peranti rumah tiada laluan ke 172.28.90.0/24, jadi balasan mereka mengikut get laluan lalai dan mati di penghala. Terdapat dua pembaikan yang disokong. Sama ada tambah laluan statik pada penghala rumah yang menghalakan awalan hotspot ke alamat LAN pelayan VPN, atau, apabila pelayan itu sendiri ialah get laluan, daftarkan awalan klien dalam jadual penghalakan pelayan itu sendiri. Dalam mod berbilang klien OpenVPN, direktori khusus klien membawa persatuan itu: fail dinamakan sempena nama biasa sijil klien, mengandungi iroute 172.28.90.0 255.255.255.0 serta baris route yang sepadan yang memasangnya dalam kernel pelayan. Laluan kernel yang diteka pada pelayan bukan pernyataan yang sama dengan memberitahu pelayan klien mana yang memiliki awalan.

Jangan pindahkan perkhidmatan DHCP rangkaian rumah ke pelayan VPN untuk menjadikan ini berfungsi. Menggantikan get laluan lalai untuk seluruh rumah ialah perubahan yang jauh lebih besar daripada menambah satu laluan balik peribadi, dan ia menyeret DNS, tempahan alamat dan setiap peranti yang mengabaikan pajakan baharu ke dalam kegagalan.

Buka pemajuan tanpa meneka firewall

Pemajuan dihidupkan tidak bermakna paket dibenarkan melalui. Trafik dari jambatan ke terowong masih melanggar peraturan penapisan, dan dasar pemajuan lalai drop menggugurkan trafik hotspot sementara trafik Pi sendiri terus berfungsi, yang menghasilkan tepat simptom terbelah di atas.

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

Cari peraturan terima dari br0 ke tun0 dan arah balasan yang sepadan, serta peraturan postrouting yang mungkin menulis semula sumber. Jika dasar rantai ialah drop dan tiada peraturan sepadan, tambah penerimaan sempit dan uji semula daripada membalikkan dasar kepada accept.

Penterjemahan ialah pilihan dasar, bukan keperluan. NAT sumber ke arah LAN rumah menjadikan setiap klien hotspot kelihatan seperti alamat terowong Pi, yang kehilangan atribusi setiap klien dalam log rumah dan memecahkan perkhidmatan yang menjangka sumber asal. Penghalakan tanpa NAT mengekalkan alamat klien kelihatan tetapi bergantung pada laluan balik di atas. Pilih satu dan tangani DNS serta IPv6 dengan cara yang sama, kerana laluan IPv4 yang berfungsi di sebelah laluan IPv6 yang rosak masih dibaca sebagai separuh rosak dalam pelayar.

Sahkan perjalanan pergi dan balik, kemudian rosakkannya dengan sengaja

Uji dari klien hotspot, jangan sekali-kali dari Pi, kerana trafik Pi sendiri memintas kedua-dua laluan hadapan dan laluan balik. Perhatikan kedua-dua antara muka semasa satu klien cuba mencapai perkhidmatan 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-dua tangkapan bersama. Permintaan pada br0 yang tidak pernah muncul pada tun0 bermakna Pi tidak memajukan atau laluan menunjuk ke tempat lain. Permintaan pada tun0 tanpa balasan bermakna sebelah rumah tiada laluan balik atau pelayan menapis paket. Balasan pada tun0 yang tidak pernah muncul semula pada br0 bermakna peraturan penapisan songsang hilang, di mana terowong kelihatan sempurna dan klien masih tidak melihat apa-apa.

Kemudian rosakkan laluan dengan sengaja. Turunkan sambungan modem dan naikkan semula serta jalankan semula pemeriksaan laluan dan tangkapan; laluan yang bertahan melalui terowong tetapi hilang semasa sambung semula tergolong dalam profil sambungan, bukan arahan sekali sahaja. Sahkan bahawa pengangkutan terowong masih keluar melalui underlay dan bukan melalui dirinya sendiri, gelung klasik apabila laluan lalai yang ditolak diterima tanpa laluan hos ke rakan sebaya.

Terima reka bentuk hanya apabila klien hotspot dapat menyelesaikan nama rumah, membuka perkhidmatan TCP dan mengekalkan sesi hidup merentasi satu sambungan semula modem. Jika aplikasi benar-benar memerlukan penemuan peringkat Ethernet pada segmen rumah, pilih reka bentuk Layer 2 yang disokong daripada menerangkan jambatan setempat sebagai dijambatani dan menunggu siaran muncul.