VPN Pi berbilang penghala: letakkan setiap laluan pada peranti yang membuat keputusan
Penghala hiliran menambah subnet klien kedua, dan setiap satu daripada empat peranti memiliki satu keputusan. Letakkan laluan, semak sumber, kemudian uji daripada klien sebenar.
Meletakkan kotak Wi-Fi di belakang Pi menjadikan satu keputusan penghalaan kepada empat, dan rancangan rosak apabila keempat-empatnya dibuat pada satu peranti. Soalan pertama bukan laluan mana untuk ditambah. Ia adalah sama ada kotak baharu menjambatani atau menghalakan, kerana jawapan itu menentukan berapa banyak subnet wujud dan peranti mana yang mesti mempelajarinya. Pilih model sambungan dahulu; setiap laluan mengikut daripadanya.
Jambatan atau penghalaan: pilihan yang menetapkan bilangan
Jambatan meletakkan klien baharu pada subnet yang sama yang sudah dilayani Pi. Satu subnet, satu autoriti DHCP dan tiada serahan untuk dihalakan. Ini susunan yang lebih mudah dan yang betul apabila rangkaian klien berasingan tidak pernah menjadi keperluan. Pautan terhalakan ialah reka bentuk berbeza: kotak menyimpan subnetnya sendiri, dan awalan itu mesti dibawa ke mana-mana sahaja trafik pergi.
Selebihnya rancangan ini mengekalkan penghala hiliran dan memelihara alamat sumber klien. Sasaran ialah satu rangkaian VPN peribadi, bukan jalan keluar internet penuh. Tulis model itu sebelum alamat, kerana senarai di bawah hanyalah contoh sambungan terhalakan.
client subnet 10.41.0.0/24
client gateway 10.41.0.1
router-to-Pi link 192.168.71.2
Pi on that link 192.168.71.1
private target 10.72.9.0/24Siapa memutuskan apa
| Decision owner | Entry that encodes the decision | Failure when the entry is missing |
|---|---|---|
| Pi VPN host | Return route for 10.41.0.0/24 via 192.168.71.2, and a tunnel route for 10.72.9.0/24 | Replies to downstream clients die at the Pi |
| Owner of the remote network | A path for 10.41.0.0/24 over the permitted tunnel | Replies stop at the first unaware hop |
| LAN router behind the Pi | Specific route for 10.72.9.0/24 via 192.168.71.1, or a suitable default | Clients never send private traffic to the Pi |
| Client machine | Default via 10.41.0.1, or a specific entry for 10.72.9.0/24 | The private network is unreachable from the client |
Setiap peranti membuat satu keputusan, dan tiada satu pun boleh membuat keputusan peranti lain bagi pihaknya. Pi memerlukan dua entri, bukan satu, dan laluan balik ialah yang orang lupakan. Trafik yang dipanjangkan tiba dengan betul di rangkaian peribadi dan kemudian mati dalam perjalanan balik, kerana Pi tidak tahu di mana 10.41.0.0/24 tinggal. Itu kelihatan seperti masalah tembok api dan sebenarnya ialah laluan yang hilang.
Bahagian jauh juga memerlukan laluannya sendiri. Jika perkhidmatan di hujung jauh tidak tahu bahawa 10.41.0.0/24 boleh dicapai melalui terowong anda, balasan berhenti pada hop pertama yang tiada jawapan. Tambah kedua-dua arah sebelum membaca penapis paket.
Hop seterusnya datang daripada sambungan
Hop seterusnya mesti alamat pada rangkaian yang benar-benar boleh dicapai peranti. Alamat awam rakan VPN bukan hop seterusnya untuk subnet peribadi, dan rangkaian perkhidmatan jauh sama sekali bukan hop seterusnya. Laluan ke get laluan yang tidak dapat dicapai kelihatan betul dalam senarai dan menggugurkan setiap paket. Semak sama ada get laluan menjawab sebelum menyalahkan destinasi.
Kekalkan rakan VPN luar Pi boleh dicapai melalui laluan lapisan bawahnya sendiri. Entri itu berasingan daripada laluan muatan, dan mencampurkannya memberi terowong yang tidak dapat dibina semula selepas perubahan laluan.
Dokumentasi laluan statik menjelaskan perbezaan antara destinasi dan get laluan, walaupun setiap platform menamakan menunya secara berbeza. Baca dokumentasi peranti di hadapan anda dan bukannya menyalin skrin vendor lain. Perintah di bawah menunjukkan bentuk entri pada Linux.
# on the Pi
ip route add 10.41.0.0/24 via 192.168.71.2
ip route add 10.72.9.0/24 dev tun0
# on the downstream router
ip route add 10.72.9.0/24 via 192.168.71.1Apa yang terjemahan lakukan kepada sumber
Jika penghala hiliran sudah menterjemah kliennya ke alamat transit, Pi melihat satu sumber terjemahan dan bukannya alamat setiap klien sendiri. Itu reka bentuk berbeza daripada yang memelihara sumber di atas. Ia mengubah dasar berasaskan sumber, pengelogan, dan pihak mana yang boleh memulakan sambungan. Kedua-dua reka bentuk berfungsi; mereka menjawab soalan berbeza.
Apabila perkhidmatan VPN huluan enggan menghalakan awalan klien kembali, terjemahan sempit di egress terowong Pi boleh menjadi penyelesaian sah sementara. Itu bukan bukti bahawa laluan yang hilang itu tidak perlu. Catat alamat mana yang benar-benar dilihat rangkaian jauh dan laluan balik apa yang terhasil.
Pemilihan laluan, kebenaran pemajuan dan terjemahan sumber kekal tiga kerja berasingan. Mengosongkan rantai NAT kongsi atau membenarkan setiap antara muka kerana satu klien berwayar berfungsi ialah cara ujian yang berfungsi menjadi pemaju terbuka.
Membuktikannya daripada mesin klien
Hantar permintaan daripada mesin di LAN hiliran, kemudian ikuti sumbernya keluar dan balik. Ping yang dikeluarkan Pi tidak pernah menggunakan laluan balik hiliran, sebab itu ping yang berjaya membuktikan lebih sedikit daripada yang kelihatan. Tambah ujian kedua daripada klien berwayar di LAN Pi sendiri supaya kedua-dua laluan boleh dibandingkan. Ulangi kedua-duanya selepas menghidupkan semula mana-mana peranti.
Laluan yang ditambah dengan tangan dan terjemahan yang tidak pernah disimpan hilang bersama. Pasangan itu kemudian kelihatan seperti kerosakan baharu dan bukannya kerja yang belum selesai.
Simpan model sambungan bersama laluan, perkhidmatan peribadi yang dibenarkan dan apa-apa terjemahan dalam satu nota. Nota itulah yang menghalang orang seterusnya daripada menganggap penempatan wayarles sebagai persoalan dasar penghalaan.