Hotspot VPN berjembatan: rute default mana yang dipakai ponsel?
Rute default Pi bukan gateway ponsel. Pisahkan kedua keputusan itu, jaga uplink di luar jembatan, dan uji lease sebelum tunnel.
Ponsel di hotspot berjembatan Anda mendapatkan alamat dan gateway-nya dari suatu tempat, dan itu bukan rute default Pi. Mengubah default Pi mengubah ke mana Pi mengirim trafiknya sendiri. Ponsel tetap memakai gateway yang diberitahukan kepadanya, dan ketika gateway itu berada di LAN jarak jauh, frame-nya cukup menyeberangi jembatan. Dua konsumen, dua keputusan. Memisahkan keduanya menjelaskan sebagian besar laporan hotspot tanpa internet sementara Pi sendiri baik-baik saja.
Dua perangkat, dua keputusan gateway yang berbeda
Pi punya tumpukan IP dan rute default sendiri. Ponsel punya tumpukan IP dan rute default sendiri.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
Tabel itu adalah seluruh modelnya. Gateway ponsel adalah alamat di LAN jarak jauh, dan frame-nya diteruskan pada lapisan 2 menuju router tersebut. Rute default Pi menyangkut transport luar Pi sendiri, yang harus mencapai peer VPN melalui uplink perjalanan.
Jembatan meneruskan frame, bukan merutekan paket
Jembatan Linux meneruskan frame Ethernet berdasarkan MAC tujuan, dan hanya itu yang dilakukannya di antara port-portnya. Frame ponsel yang dialamatkan ke MAC router jarak jauh dialihkan ke port TAP dan menyeberangi tunnel tanpa menyentuh tabel perutean Pi. Karena itu rute default Pi yang rusak bisa membuat ponsel tetap bekerja, dan karena itu rute yang benar tidak bisa memperbaiki ponsel yang diberi gateway salah.
TAP membawa frame Ethernet dan bisa menjadi port jembatan. TUN membawa paket IP dan tidak bisa. Jika desain Anda mengganti yang satu dengan yang lain, jembatan itu bukan jembatan dan sisanya tidak berlaku.
Putuskan siapa yang membagikan lease ponsel
Opsi 3 DHCP adalah opsi router, dan ia memberi tahu klien gateway mana yang harus dipakai untuk subnetnya. Ketika server DHCP LAN jarak jauh adalah satu-satunya pembagi, ponsel mendapat gateway jarak jauh dan desainnya konsisten. Ketika sesuatu yang lain di sisi perjalanan menjawab lebih dulu, ponsel mendapat gateway lokal, trafik internetnya keluar lewat uplink perjalanan, dan trafiknya ke LAN jarak jauh tidak punya jalur sama sekali.
Jalankan satu pembagi untuk domain siar itu, dan catat apa yang dibagikannya.
Pi adalah kasus terpisah meskipun ia mengambil alamat dari lease yang sama. Putuskan dengan sengaja apakah ia harus memasang rute yang ditawarkan lease itu, karena default jarak jauh yang diimpor dapat menyeret transport VPN Pi sendiri ke dalam tunnel yang ingin dijaganya tetap hidup. Dengan systemd-networkd keputusan itu adalah UseRoutes= di bagian DHCP; dengan dhclient itu adalah opsi routers dalam daftar permintaan.
Jaga uplink di luar LAN berjembatan
Antarmuka yang membawa koneksi VPN luar Pi tidak boleh menjadi port jembatan. Jika menjadi, transport terenkripsi dialihkan ke LAN yang diperluas dan tunnel akhirnya membawa paket luarnya sendiri, yang gagal dengan cara yang terlihat seperti kehilangan paket alih-alih loop. Jaga juga kemampuan AP dan dukungan jembatan tetap eksplisit. Antarmuka nirkabel dalam mode station biasanya tidak bisa menjadi port jembatan, karena header 802.11 tidak punya ruang untuk alamat MAC kedua yang dibutuhkan jembatan.
Tentukan domain siar yang diperluas, satu rencana alamat, dan penyaringan frame yang benar-benar Anda inginkan. Mengizinkan pendengar VPN di Pi tidak memberi setiap klien berjembatan akses ke layanan manajemen Pi. Itu aturan terpisah, dan memperlakukannya sebagai satu adalah cara hotspot diam-diam menjadi pintu terbuka.
Uji keempat hal itu secara terpisah saat rusak
Ketika ponsel tidak dapat mencapai LAN jarak jauh, empat pengamatan memisahkan penyebabnya. Jalankan dalam urutan ini dan berhenti pada yang pertama gagal.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpMulai dari lease: apakah ponsel memegang alamat dan gateway di subnet jarak jauh? Lalu lihat jembatan, dan pastikan port AP dan port TAP keduanya meneruskan. Lalu baca tabel tetangga, karena entri yang belum terselesaikan untuk router jarak jauh berarti frame keluar dan tidak ada yang menjawab. Terakhir amati frame di jembatan saat ponsel melakukan ping, yang memberi tahu Anda apakah kesalahan ada di bawah IP atau tidak.
Catat perangkat mana yang memiliki setiap rute default saat selesai. Satu baris dokumentasi mengubah egress lokal versus jarak jauh menjadi keputusan klien yang disengaja, dan referensi jembatan layak disimpan di sebelahnya.