VPN Pi multi-router: taruh setiap rute di perangkat yang memutuskan
Router hilir menambah subnet klien kedua, dan keempat perangkat masing-masing memegang satu keputusan. Tempatkan rutenya, periksa sumbernya, lalu uji dari klien sungguhan.
Menaruh kotak Wi-Fi di belakang Pi mengubah satu keputusan perutean menjadi empat, dan rencananya rusak ketika keempatnya diambil di satu perangkat. Pertanyaan pertama bukan rute mana yang harus ditambahkan. Melainkan apakah kotak baru menjembatani atau merutekan, karena jawaban itu menentukan berapa subnet yang ada dan perangkat mana yang harus mempelajarinya. Pilih model pemasangan lebih dulu; setiap rute mengikutinya.
Jembatan atau rute: pilihan yang menetapkan jumlahnya
Jembatan menaruh klien baru di subnet yang sama dengan yang sudah dilayani Pi. Satu subnet, satu otoritas DHCP, dan tidak ada penyerahan untuk dirutekan. Ini susunan yang lebih sederhana dan yang tepat ketika jaringan klien terpisah tidak pernah menjadi keharusan. Tautan yang dirutekan adalah desain lain: kotak mempertahankan subnetnya sendiri, dan prefiks itu harus dibawa ke mana pun lalu lintas pergi.
Sisa rencana ini mempertahankan router hilir dan menjaga alamat sumber klien. Targetnya satu jaringan VPN privat, bukan pintu keluar internet penuh. Tuliskan modelnya sebelum alamat, karena daftar di bawah hanyalah contoh pemasangan yang dirutekan.
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 perangkat membuat satu keputusan, dan tidak ada yang bisa membuat keputusan perangkat lain untuknya. Pi butuh dua entri, bukan satu, dan jalur balik adalah yang orang lupakan. Lalu lintas yang diteruskan mencapai jaringan privat dengan benar lalu mati dalam perjalanan pulang, karena Pi tidak tahu di mana 10.41.0.0/24 tinggal. Itu tampak seperti masalah firewall dan sebenarnya adalah rute yang hilang.
Sisi jauh juga butuh rutenya sendiri. Jika layanan di ujung jauh tidak tahu bahwa 10.41.0.0/24 dapat dijangkau melalui terowongan Anda, balasan berhenti di lompatan pertama yang tidak punya jawaban. Tambahkan kedua arah sebelum membaca filter paket.
Lompatan berikutnya datang dari pemasangan
Lompatan berikutnya harus berupa alamat di jaringan yang benar-benar bisa dijangkau perangkat. Alamat publik rekan VPN bukan lompatan berikutnya bagi subnet privat, dan jaringan layanan jauh sama sekali bukan lompatan berikutnya. Rute ke gateway yang tak terjangkau terlihat benar di daftar dan membuang setiap paket. Periksa bahwa gateway menjawab sebelum menyalahkan tujuan.
Jaga rekan VPN luar Pi tetap terjangkau melalui rute lapisan bawahnya sendiri. Entri itu terpisah dari rute muatan, dan mencampurnya memberi terowongan yang tidak dapat dibangun ulang setelah perubahan jalur.
Dokumentasi rute statis memperjelas perbedaan antara tujuan dan gateway, meskipun setiap platform menamai menunya berbeda. Bacalah dokumentasi perangkat di depan Anda alih-alih menyalin layar vendor lain. Perintah di bawah menunjukkan bentuk entrinya di 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 dilakukan penerjemahan pada sumber
Jika router hilir sudah menerjemahkan kliennya ke alamat transit, Pi melihat satu sumber terterjemah alih-alih alamat masing-masing klien. Itu desain berbeda dari yang mempertahankan sumber di atas. Itu mengubah kebijakan berbasis sumber, pencatatan, dan sisi mana yang dapat memulai koneksi. Kedua desain bekerja; keduanya menjawab pertanyaan berbeda.
Ketika layanan VPN hulu menolak merutekan prefiks klien kembali, penerjemahan sempit di egress terowongan Pi bisa menjadi jalan keluar yang sah. Itu bukan bukti bahwa rute yang hilang tidak diperlukan. Catat alamat mana yang benar-benar dilihat jaringan jauh dan jalur balik apa yang dihasilkan.
Pemilihan rute, izin penerusan, dan penerjemahan sumber tetap tiga pekerjaan terpisah. Mengosongkan rantai NAT bersama atau mengizinkan setiap antarmuka karena satu klien kabel berfungsi adalah cara uji yang berhasil menjadi penerus terbuka.
Membuktikannya dari mesin klien
Kirim permintaan dari mesin di LAN hilir, lalu ikuti sumbernya keluar dan kembali. Ping yang dikirim Pi tidak pernah melatih rute balik hilir, karena itu ping yang berhasil membuktikan lebih sedikit daripada kelihatannya. Tambahkan uji kedua dari klien kabel di LAN Pi sendiri agar kedua jalur dapat dibandingkan. Ulangi keduanya setelah memulai ulang salah satu perangkat.
Rute yang ditambahkan dengan tangan dan penerjemahan yang tidak pernah disimpan hilang bersama. Pasangan itu lalu tampak seperti kesalahan baru alih-alih pekerjaan yang belum selesai.
Simpan model pemasangan bersama rute, layanan privat yang diizinkan, dan penerjemahan apa pun dalam satu catatan. Catatan itulah yang menghentikan orang berikutnya memperlakukan penempatan nirkabel sebagai pertanyaan kebijakan perutean.