Menambah subnet kedua pada VPN antara tapak: dua laluan
Tunnel berasaskan dasar perlukan pemilih sepadan di kedua-dua belah; tunnel berasaskan laluan perlukan laluan. Pilih laluan betul dan betulkan laluan balik dahulu.
Menambah subnet kedua pada tunnel antara tapak yang berfungsi mengambil lima minit dalam satu reka bentuk dan hampir sepanjang petang dalam reka bentuk lain. Apabila tunnel memasang laluan untuk awalan yang anda namakan, anda menambah laluan dan trafik mengikutinya. Apabila ia berunding satu pasangan pemilih tetap, awalan baharu kekal tanpa perlindungan sehingga kedua-dua pihak bersetuju pasangan sepadan. Tiga perkara menentukan: apa yang sebenarnya dijelaskan konfigurasi setiap pihak, sama ada trafik yang dirunding mengecil kepada pasangan sepadan terkecil, dan siapa pemilik laluan balik bagi julat baharu.
Baca kernel, bukan label status
Tunnel yang melaporkan bersambung telah memasang sekurang-kurangnya satu persatuan anak, tetapi bukan semestinya yang anda sangka. Dalam Linux kernel menunjukkan apa yang digunakan: ip xfrm policy menyenaraikan pasangan pemilih dan swanctl --list-sas (atau ipsec statusall lama) menunjukkan apa yang dirunding, termasuk pemilih trafik dalam setiap arah. Jika awalan baharu tiada dalam kedua-duanya, ia tanpa perlindungan, apa pun kata fail konfigurasi.
Bandingkan dengan jadual laluan. Dalam susunan berasaskan laluan, peranti tunnel ialah hop seterusnya bagi awalan yang dilindungi. Susunan berasaskan dasar selalunya tiada laluan khusus untuk subnet jauh, hanya laluan lalai, kerana dasar memilih trafik dan bukan jadual.
Berasaskan dasar: kedua-dua pihak mesti menyenaraikan awalan baharu
Dalam istilah strongSwan pemilih berada dalam local_ts dan remote_ts di bawah konfigurasi anak, pengganti leftsubnet dan rightsubnet. Awalan baharu mesti muncul di kedua-dua pihak seperti cermin: apa yang tapak A sebut setempat, tapak B sebut jauh. Ketidakpadanan jarang memberi ralat bersih. Kedua-dua pihak mengecil kepada persilangan, awalan lama terus berfungsi dan hanya yang baharu gagal senyap.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy
Pada pfSense atau OPNsense itu bermakna entri Phase 2 kedua yang memasangkan subnet setempat baharu dengan subnet jauh baharu, kemudian guna pakai. Kekalkan entri lama; menggantikannya memindahkan subnet asal dan bukan menambah. Jika Phase 2 sedia ada sudah meliputi supernet seperti 0.0.0.0/0 atau julat ringkasan, jangan tambah entri lebih sempit di sebelahnya: pemilih bertindih memasang dasar bersaing dan susunan penilaian menentukan pemenang.
IKEv1 menjadikan setiap pasangan subnet Phase 2 sendiri, dan pihak yang menerima satu pasangan setiap pertukaran membuang yang lain. IKEv2 boleh membawa beberapa pasangan pemilih dalam satu anak, tetapi hanya jika kedua-dua pelaksanaan menerimanya. Senarai daripada swanctl --list-sas ialah kebenaran; apa yang anda taip ialah permintaan.
Berasaskan laluan: laluan ialah dasar
Antara muka XFRM atau peranti VTI membawa trafik mengikut jadual laluan. Anda menghalakan awalan baharu ke peranti di kedua-dua tapak, dan keadaan terikat pada transformasi antara muka digunakan. Tiada pasangan pemilih untuk disegerakkan, sebab itu reka bentuk ini berskala lebih baik apabila subnet bertambah. Panduan penghantaran strongSwan membincangkan bahagian kernel dengan terperinci.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10
WireGuard membawa idea itu lebih jauh. AllowedIPs ialah senarai kebenaran kripto dan, melalui wg-quick, entri jadual laluan. Tambah awalan pada satu pihak sahaja dan anda dapat jabat tangan, paket keluar dan kesenyapan, kerana pihak jauh membuang paket yang sumbernya tiada dalam senarainya. Bentuk wg set menggantikan seluruh senarai, jadi ulangi awalan yang sudah berfungsi atau anda akan memutuskannya:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0
Perintah kedua itu bukan pilihan apabila anda menggunakan wg set dan bukan wg-quick. Kernel menerima senarai baharu serta-merta, tetapi tiada apa menambah laluan untuknya, jadi trafik yang dijana setempat masih keluar melalui get laluan lalai. Inilah sebab paling biasa subnet WireGuard baharu berfungsi dari hos tunnel dan bukan dari komputer riba.
Laluan balik lebih kerap gagal daripada tunnel
Hos pada subnet jauh baharu mesti menghantar balasan melalui get laluan VPN. Apabila get laluan itu bukan penghala lalai mereka, balasan pergi ke penghala LAN, yang membuangnya atau memajukannya ke internet dengan alamat sumber persendirian. Uji dari hos di pihak jauh dan bukan dari get laluan: ip route get 10.30.20.15 dalam Linux atau Find-NetRoute -RemoteIPAddress 10.30.20.15 dalam PowerShell menunjukkan hop seterusnya yang benar-benar digunakan hos. Jika balasan bukan titik hujung tunnel, tambah laluan statik untuk awalan baharu di situ.
NAT sumber di tapak yang tiada laluan balik ialah alternatif sah dan cara banyak penggunaan hub-and-spoke mengelak menyentuh setiap pelayan. Gunakan juga pada awalan baharu di get laluan pihak destinasi:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE
Kosnya nyata. Log jauh berhenti menunjukkan alamat sumber individu dan peraturan firewall yang berasaskan subnet asal bergabung menjadi satu peraturan untuk get laluan. Pilih itu dengan sengaja, bukan kerana laluan hilang.
Firewall ialah separuh lagi laluan balik. Peranti berasaskan zon tidak meluaskan zon antara muka tunnel sedia ada ke subnet baharu secara automatik, dan peraturan yang ditulis untuk awalan lama tidak akan sepadan. Tambah subnet baharu ke zon atau ke pasangan peraturan dalam kedua-dua arah sebelum menyalahkan IPsec.
Putuskan dengan tiga soalan, kemudian sahkan dengan trafik
Versi ringkas: adakah konfigurasi pihak menamakan awalan (berasaskan dasar), atau trafik dihalakan ke antara muka (berasaskan laluan)? Adakah kedua-dua hujung menyenaraikan awalan baharu? Adakah ada jalan balik dari subnet baharu ke julat sumber asal?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
Pengesahan ialah tempat kebanyakan perubahan ditutup terlalu awal. Ping dari get laluan membuktikan sedikit, kerana get laluan menghantar dari dirinya dan sering sepadan dengan dasar berbeza daripada hos. Ping dari hos pada subnet baharu, kemudian jalankan aplikasi yang mencetuskan perubahan, dan lihat pembilang bukan ikon status.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show
Pada tunnel berasaskan dasar, pembilang ip xfrm state harus naik dalam kedua-dua arah; pembilang rata bermakna paket dihalakan tetapi tidak dipilih. Pada WireGuard wg show melaporkan pemindahan setiap pihak, dan jabat tangan tanpa bait diterima menunjuk senarai pihak jauh atau laluan baliknya.
Akhiri dengan merekod awalan, pemilih atau laluan pihak, keputusan laluan balik dan entri firewall bersama baki inventori tunnel. Kemudian but semula satu get laluan dan uji lagi: laluan yang ditambah dengan tangan hilang, dan orang seterusnya tidak perlu menemuinya semula.