Tilføj et ekstra subnet til en site-to-site VPN: to veje
Politikbaserede tunneler kræver matchende selektorer i begge ender; rutebaserede kræver en rute. Vælg den rigtige vej, og ret først returruten.
At tilføje et ekstra subnet til en fungerende site-to-site-tunnel tager fem minutter i det ene design og det meste af en eftermiddag i det andet. Når tunnelen installerer ruter for de præfikser, du angiver, tilføjer du en rute, og trafikken følger den. Når den forhandler ét fast selektorpar, forbliver det nye præfiks ubeskyttet, indtil begge sider bliver enige om et matchende par. Tre ting afgør sagen: hvad hver sides konfiguration reelt beskriver, om den forhandlede trafik indsnævres til det mindste matchende par, og hvem der ejer returvejen for det nye område.
Læs kernen, ikke statusmærket
En tunnel, der melder forbindelse, har installeret mindst én underordnet association, men ikke nødvendigvis den, du tror. På Linux viser kernen, hvad der anvendes: ip xfrm policy viser selektorparrene, og swanctl --list-sas (eller den ældre ipsec statusall) viser, hvad siderne forhandlede, inklusive trafikselektorerne i hver retning. Hvis det nye præfiks ikke optræder nogen af stederne, er det ubeskyttet, uanset hvad konfigurationsfilen siger.
Sammenlign med rutetabellen. I et rutebaseret design er tunnelens enhed næste hop for de beskyttede præfikser. Et politikbaseret design har ofte ingen specifik rute til det fjerne subnet, kun standardruten, fordi politikken vælger trafikken og ikke tabellen.
Politikbaserede tunneler: begge sider skal angive det nye præfiks
I strongSwan-termer ligger selektoren i local_ts og remote_ts under underkonfigurationen, efterfølgerne til leftsubnet og rightsubnet. Det nye præfiks skal optræde på begge sider spejlet: det, som site A kalder lokalt, kalder site B fjernt. Uenighed giver sjældent en ren fejl. Siderne indsnævres til snittet, det gamle præfiks virker fortsat, og det nye fejler lydløst.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyPå pfSense eller OPNsense betyder det en ekstra Phase 2-post, der parrer det nye lokale subnet med det nye fjerne, og derefter anvendelse. Behold den gamle post; en erstatning flytter det oprindelige subnet i stedet for at tilføje. Hvis en eksisterende Phase 2 allerede dækker et supernet som 0.0.0.0/0 eller et opsummeret område, må du ikke tilføje en smallere post ved siden af: overlappende selektorer installerer konkurrerende politikker, og evalueringsrækkefølgen afgør vinderen.
IKEv1 gør hvert subnetpar til sin egen Phase 2, og en side, der tager ét par pr. udveksling, dropper resten. IKEv2 kan bære flere selektorpar i én underordnet association, men kun hvis begge implementeringer accepterer dem. Listen fra swanctl --list-sas er sandheden; det, du skrev, er en anmodning.
Rutebaserede tunneler: ruten er politikken
En XFRM-grænseflade eller en VTI-enhed bærer trafik efter rutetabellen. Du peger det nye præfiks mod enheden på begge sites, og tilstanden bundet til grænsefladens transformation anvendes. Der er intet selektorpar at holde synkroniseret, og derfor skalerer designet bedre, når subnets formerer sig. strongSwans videresendelsesguide gennemgår kernelsiden i detaljer.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard går videre. AllowedIPs er både krypto-tilladelseslisten og, via wg-quick, posten i rutetabellen. Tilføjer du præfikset på kun den ene side, får du et håndtryk, udgående pakker og tavshed, fordi den fjerne side dropper pakker, hvis kilde ikke er på dens liste. Formen wg set erstatter hele listen, så gentag de præfikser, der allerede virkede, ellers afskærer du dem:
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 wg0Den anden kommando er ikke valgfri, når du brugte wg set i stedet for wg-quick. Kernen accepterer den nye liste med det samme, men intet tilføjer en rute til den, så lokalt genereret trafik forlader stadig standardgatewayen. Det er den hyppigste grund til, at et nyt WireGuard-subnet virker fra tunnelværten og ikke fra en bærbar.
Returvejen fejler oftere end tunnelen
Værter på det nye fjerne subnet skal sende svar tilbage gennem VPN-gatewayen. Når den gateway ikke er deres standardrouter, går svaret til LAN-routeren, som enten dropper det eller videresender det til internettet med en privat kildeadresse. Test fra en vært på den fjerne side i stedet for fra gatewayen: ip route get 10.30.20.15 på Linux eller Find-NetRoute -RemoteIPAddress 10.30.20.15 i PowerShell viser det næste hop, som værten faktisk bruger. Hvis svaret ikke er tunnelens endepunkt, tilføj en statisk rute for det nye præfiks der.
Kilde-NAT på det site, der mangler returruten, er et legitimt alternativ og måden, hvorpå mange hub-and-spoke-udrulninger undgår at røre hver server. Anvend det også på det nye præfiks på gatewayen på destinationssiden:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEPrisen er reel. Fjernlogs holder op med at vise individuelle kildeadresser, og firewallregler bundet til det oprindelige subnet smelter sammen til én regel for gatewayen. Vælg det bevidst, ikke fordi en rute manglede.
Firewalls er den anden halvdel af returvejen. Zonebaserede enheder udvider ikke automatisk en eksisterende tunnelgrænseflades zone til et nyt subnet, og en regel skrevet mod det gamle præfiks vil ikke matche. Tilføj det nye subnet til zonen eller regelparret i begge retninger, før du bebrejder IPsec.
Beslut med tre spørgsmål, og verificer så med trafik
Den korte version: angiver sidens konfiguration præfikser (politikbaseret), eller routes trafikken ind i en grænseflade (rutebaseret)? Angiver begge ender det nye præfiks? Er der en vej tilbage fra det nye subnet til det oprindelige kildeområde?
| 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 |
Verifikation er der, hvor de fleste ændringer lukkes for tidligt. Et ping fra gatewayen beviser lidt, fordi gatewayen sender fra sig selv og ofte matcher en anden politik end en vært. Ping fra en vært på det nye subnet, kør derefter applikationen, der motiverede ændringen, og se på tællere i stedet for et statusikon.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showPå en politikbaseret tunnel skal ip xfrm state-tællerne stige i begge retninger; flade tællere betyder, at pakken routes men ikke vælges. På WireGuard viser wg show overførsel pr. side, og et håndtryk med nul modtagne bytes peger på den fjerne sides tilladelsesliste eller dens returrute.
Afslut med at registrere præfikset, sidens selektor eller rute, beslutningen om returvejen og firewallposten sammen med resten af tunnelopgørelsen. Genstart derefter én gateway, og test igen: en rute tilføjet i hånden forsvinder, og den næste person bør ikke opdage det igen.