Menambahkan subnet kedua ke VPN situs-ke-situs: dua jalur
Tunnel berbasis kebijakan butuh selektor yang cocok di kedua sisi; yang berbasis rute butuh rute. Pilih jalur yang tepat dan perbaiki rute balik lebih dulu.
Menambahkan subnet kedua ke tunnel situs-ke-situs yang berjalan butuh lima menit pada satu desain dan hampir sepanjang sore pada desain lain. Saat tunnel memasang rute untuk prefiks yang Anda sebut, Anda menambahkan rute dan lalu lintas mengikutinya. Saat ia merundingkan satu pasangan selektor tetap, prefiks baru tetap tanpa perlindungan sampai kedua sisi sepakat atas pasangan yang cocok. Tiga hal menentukan: apa yang sebenarnya dijelaskan konfigurasi tiap sisi, apakah lalu lintas yang dirundingkan menyempit ke pasangan terkecil yang cocok, dan siapa pemilik rute balik untuk rentang baru.
Baca kernel, bukan label status
Tunnel yang melaporkan terhubung telah memasang setidaknya satu asosiasi anak, tetapi belum tentu yang Anda duga. Di Linux kernel menunjukkan apa yang diterapkan: ip xfrm policy mendaftar pasangan selektor, dan swanctl --list-sas (atau ipsec statusall yang lama) menunjukkan apa yang dirundingkan, termasuk selektor lalu lintas di tiap arah. Bila prefiks baru tidak ada di keduanya, ia tanpa perlindungan, apa pun kata berkas konfigurasi.
Bandingkan dengan tabel rute. Pada desain berbasis rute, perangkat tunnel adalah hop berikutnya bagi prefiks yang dilindungi. Desain berbasis kebijakan sering tidak punya rute khusus untuk subnet jauh, hanya rute bawaan, karena kebijakan yang memilih lalu lintas, bukan tabel.
Tunnel berbasis kebijakan: kedua sisi harus mendaftar prefiks baru
Dalam istilah strongSwan selektor berada di local_ts dan remote_ts pada konfigurasi anak, penerus leftsubnet dan rightsubnet. Prefiks baru harus muncul di kedua sisi secara cermin: yang disebut lokal oleh situs A disebut jauh oleh situs B. Ketidakcocokan jarang memberi galat bersih. Kedua sisi menyempit ke irisan, prefiks lama tetap bekerja dan hanya yang baru gagal diam-diam.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyDi pfSense atau OPNsense itu berarti entri Phase 2 kedua yang memasangkan subnet lokal baru dengan subnet jauh baru, lalu diterapkan. Pertahankan entri lama; menggantinya memindahkan subnet asli alih-alih menambah. Bila Phase 2 yang ada sudah mencakup supernet seperti 0.0.0.0/0 atau rentang terangkum, jangan tambahkan entri lebih sempit di sampingnya: selektor yang tumpang tindih memasang kebijakan bersaing dan urutan evaluasi menentukan pemenangnya.
IKEv1 menjadikan tiap pasangan subnet Phase 2 sendiri, dan sisi yang menerima satu pasangan per pertukaran membuang sisanya. IKEv2 dapat membawa beberapa pasangan selektor dalam satu anak, tetapi hanya bila kedua implementasi menerimanya. Daftar dari swanctl --list-sas adalah kebenaran; yang Anda ketik adalah permintaan.
Tunnel berbasis rute: rute adalah kebijakan
Antarmuka XFRM atau perangkat VTI membawa lalu lintas menurut tabel rute. Anda mengarahkan prefiks baru ke perangkat di kedua situs, dan status yang terikat pada transformasi antarmuka berlaku. Tidak ada pasangan selektor untuk disinkronkan, karena itu desain ini lebih baik menskala saat subnet bertambah. Panduan penerusan strongSwan membahas sisi kernel lebih rinci.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard membawa gagasan itu lebih jauh. AllowedIPs sekaligus daftar izin kripto dan, lewat wg-quick, entri tabel rute. Tambahkan prefiks hanya di satu sisi dan Anda mendapat handshake, paket keluar dan keheningan, karena sisi jauh membuang paket yang sumbernya tidak ada di daftarnya. Bentuk wg set mengganti seluruh daftar, jadi sebutkan ulang prefiks yang sudah bekerja atau Anda akan memutusnya:
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 wg0Perintah kedua itu tidak opsional bila Anda memakai wg set alih-alih wg-quick. Kernel langsung menerima daftar baru, tetapi tidak ada yang menambahkan rute untuknya, jadi lalu lintas yang dibuat lokal tetap keluar lewat gateway bawaan. Inilah alasan paling umum subnet WireGuard baru bekerja dari host tunnel dan bukan dari laptop.
Rute balik lebih sering gagal daripada tunnel
Host di subnet jauh baru harus mengirim balasan lewat gateway VPN. Bila gateway itu bukan router bawaan mereka, balasan menuju router LAN, yang membuangnya atau meneruskannya ke internet dengan alamat sumber privat. Uji dari host di sisi jauh, bukan dari gateway: ip route get 10.30.20.15 di Linux atau Find-NetRoute -RemoteIPAddress 10.30.20.15 di PowerShell menunjukkan hop berikutnya yang benar-benar dipakai host. Bila jawabannya bukan titik ujung tunnel, tambahkan rute statis untuk prefiks baru di sana.
NAT sumber di situs yang tidak punya rute balik adalah alternatif sah dan cara banyak penerapan hub-and-spoke menghindari menyentuh tiap server. Terapkan juga pada prefiks baru di gateway sisi tujuan:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEBiayanya nyata. Log jauh berhenti menampilkan alamat sumber individual, dan aturan firewall yang berpatokan pada subnet asli menyusut menjadi satu aturan untuk gateway. Pilih itu dengan sadar, bukan karena rute hilang.
Firewall adalah separuh lain rute balik. Perangkat berbasis zona tidak memperluas zona antarmuka tunnel yang ada ke subnet baru secara otomatis, dan aturan yang ditulis untuk prefiks lama tidak akan cocok. Tambahkan subnet baru ke zona atau ke pasangan aturan di kedua arah sebelum menyalahkan IPsec.
Putuskan dengan tiga pertanyaan, lalu verifikasi dengan lalu lintas
Versi singkat: apakah konfigurasi sisi menyebut prefiks (berbasis kebijakan), atau lalu lintas dirutekan ke antarmuka (berbasis rute)? Apakah kedua ujung mendaftar prefiks baru? Adakah jalan balik dari subnet baru ke rentang sumber asli?
| 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 |
Verifikasi adalah tempat sebagian besar perubahan ditutup terlalu cepat. Ping dari gateway membuktikan sedikit, karena gateway bersumber dari dirinya sendiri dan sering cocok dengan kebijakan berbeda dari host. Ping dari host di subnet baru, lalu jalankan aplikasi yang memicu perubahan, dan lihat penghitung, bukan ikon status.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showPada tunnel berbasis kebijakan, penghitung ip xfrm state harus naik di kedua arah; penghitung datar berarti paket dirutekan tetapi tidak dipilih. Pada WireGuard, wg show melaporkan transfer per sisi, dan handshake tanpa byte diterima menunjuk daftar sisi jauh atau rute baliknya.
Akhiri dengan mencatat prefiks, selektor atau rute sisi, keputusan rute balik dan entri firewall bersama sisa inventaris tunnel. Lalu boot ulang satu gateway dan uji lagi: rute yang ditambahkan manual hilang, dan orang berikutnya tidak perlu menemukannya lagi.