In twadde subnet tafoegje oan in site-to-site VPN: twa paden
Beliedsbasearre tunnels freegje oan beide kanten passende selektors; rûtebasearre freegje in rûte. Kies it goede paad en reparearje earst de weromrûte.
In twadde subnet tafoegje oan in wurkjende site-to-site tunnel kostet by it iene ûntwerp fiif minuten en by it oare hast de hiele middei. As de tunnel rûtes ynstallearret foar de foarheaksels dy’t neamst, foegest in rûte ta en it ferkear folget dy. As er ien fêst selektorpear ûnderhannelt, bliuwt it nije foarheaksel ûnbeskerme oant beide kanten it iens binne oer in passend pear. Trije dingen beslisse dyn gefal: wat de konfiguraasje fan elke kant echt beskriuwt, oft it ûnderhannele ferkear ferneaud wurdt ta it lytste passende pear, en wa’t de weromrûte foar it nije berik hat.
Lês de kernel, net it statuslabel
In tunnel dy’t ferbining meldt hat teminsten ien bernassoasje ynstallearre, mar net needsaaklik dy’tsto tinkst. Under Linux lit de kernel sjen wat tapast wurdt: ip xfrm policy listet de selektorpearen en swanctl --list-sas (of de âldere ipsec statusall) lit sjen wat de kanten ûnderhannele hawwe, ynklusyf de ferkearsselektors yn elke rjochting. As it nije foarheaksel yn gjinien stiet, is it ûnbeskerme, wat it konfiguraasjebestân ek seit.
Fergelykje dat mei de rûtetabel. By in rûtebasearre opset is it tunnelapparaat de folgjende hop foar de beskerme foarheaksels. In beliedsbasearre opset hat faak gjin spesifike rûte foar it fiere subnet, allinnich de standertrûte, om’t it belied it ferkear kiest en net de tabel.
Beliedsbasearre tunnels: beide kanten moatte it nije foarheaksel liste
Yn strongSwan-termen wennet de selektor yn local_ts en remote_ts ûnder de bernkonfiguraasje, de opfolgers fan leftsubnet en rightsubnet. It nije foarheaksel moat oan beide kanten spegele ferskine: wat side A lokaal neamt, neamt side B fier. In ôfwiking jout selden in skjinne fout. De kanten ferneauje har ta de trochsneed, it âlde foarheaksel bliuwt wurkjen en allinnich it nije mislearret stil.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyOp pfSense of OPNsense betsjut dat in twadde Phase 2-ynfier dy’t it nije lokale subnet mei it nije fiere pearet, en dan tapasse. Hâld de âlde ynfier; ferfangen ferpleatst it orizjinele subnet yn stee fan it ta te foegjen. As in besteande Phase 2 al in supernet lykas 0.0.0.0/0 of in gearfette berik beslacht, foegje dan gjin smeller ynfier derneist ta: oerlaapjende selektors ynstallearje konkurrearjende belieden en de folchoarder fan beoardieling beslisset wa’t wint.
IKEv1 makket fan elk subnetpear syn eigen Phase 2, en in kant dy’t ien pear per útwikseling nimt, lit de rest falle. IKEv2 kin ferskate selektorpearen yn ien bern drage, mar allinnich as beide ymplemintaasjes se akseptearje. De list fan swanctl --list-sas is de wierheid; watsto typt hast is in fersyk.
Rûtebasearre tunnels: de rûte is it belied
In XFRM-ynterface of in VTI-apparaat draacht ferkear neffens de rûtetabel. Do rjochtest it nije foarheaksel op it apparaat yn beide siden, en de tastân dy’t oan de transformaasje fan de ynterface bûn is jildt. Der is gjin selektorpear te syngronisearjen, dêrom skaleart dit ûntwerp better as subnetten tanimme. De strongSwan-doorstjoergids giet details yn op de kernkant.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard giet fierder. AllowedIPs is tagelyk de kryptobystânlist en, fia wg-quick, de ynfier yn de rûtetabel. Foegje it foarheaksel allinnich oan ien kant ta en do krigest in hânskodding, útgeande pakketten en stilte, om’t de fiere kant pakketten fuortsmyt waans boarne net op syn list stiet. De foarm wg set ferfangt de hiele list, dus werhelje de foarheaksels dy’t al wurken, oars snijst se ôf:
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 wg0Dy twadde opdracht is net opsjoneel as do wg set brûkt hast yn stee fan wg-quick. De kernel akseptearret de nije list daliks, mar neat foeget der in rûte oan ta, dus lokaal makke ferkear giet noch altyd troch de standertgateway. Dat is de meast foarkommende reden dat in nij WireGuard-subnet fan de tunnelhost wurket en net fan in laptop.
De weromrûte mislearret faker as de tunnel
Hosts op it nije fiere subnet moatte antwurden weromstjoere troch de VPN-gateway. As dy gateway net harren standertrouter is, giet it antwurd nei de LAN-router, dy’t it fuortsmit of nei it ynternet trochstjoert mei in privee boarneadres. Test fan in host oan de fiere kant, net fan de gateway: ip route get 10.30.20.15 yn Linux of Find-NetRoute -RemoteIPAddress 10.30.20.15 yn PowerShell lit de folgjende hop sjen dy’t de host echt brûkt. As it antwurd net it tunnel-einpunt is, foegje dêr in statyske rûte ta foar it nije foarheaksel.
Boarne-NAT op de side sûnder weromrûte is in legitym alternatyf en sa foarkomme in protte hub-and-spoke-opsets dat elke tsjinner oanrekke wurdt. Pas it ek ta op it nije foarheaksel by de gateway oan de bestimmingskant:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEDe kosten binne echt. Fiere logboeken stopje mei it sjen litten fan yndividuele boarneadressen, en firewallregels dy’t op it orizjinele subnet basearre binne falle gear ta ien regel foar de gateway. Kies dat bewust, net om’t in rûte miste.
Firewalls binne de oare helte fan de weromrûte. Sônebasearre apparaten wreidzje de sône fan in besteande tunnelinterface net automatysk út nei in nij subnet, en in regel skreaun foar it âlde foarheaksel sil net passe. Foegje it nije subnet ta oan de sône of oan it regelpear yn beide rjochtingen foardat do IPsec beskylgje.
Beslis mei trije fragen, kontrolearje dan mei ferkear
De koarte ferzje: neamt de konfiguraasje fan de kant foarheaksels (beliedsbasearre), of wurdt ferkear nei in ynterface rûte (rûtebasearre)? Listet beide einen it nije foarheaksel? Is der in paad werom fan it nije subnet nei it orizjinele boarneberik?
| 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 |
Kontrôle is it plak dêr’t de measte feroarings te betiid sletten wurde. In ping fan de gateway bewiist net folle, om’t de gateway fan himsels stjoert en faak by in oar belied past as in host. Ping fan in host op it nije subnet, rin dan de applikaasje dy’t de feroaring feroarsake, en sjoch nei tellers, net nei in statusikoan.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showOp in beliedsbasearre tunnel moatte de tellers fan ip xfrm state yn beide rjochtingen omheech gean; flakke tellers betsjutte dat it pakket rûte wurdt mar net selektearre. Op WireGuard rapportearret wg show oerdracht per kant, en in hânskodding mei nul ûntfongen bytes wiist op de list fan de fiere kant of syn weromrûte.
Einigje mei it fêstlizzen fan it foarheaksel, de selektor of rûte fan de kant, it beslút oer de weromrûte en de firewallynfier mei de rest fan de tunnelynventaris. Herstart dan ien gateway en test op’nij: in mei de hân tafoege rûte ferdwynt, en de folgjende persoan soe dat net op’nij ûntdekke moatte.