Legg til et andre subnett i en site-til-site VPN: to veier
Policydrevne tunneler trenger samsvarende selektorer på begge sider; rutedrevne trenger en rute. Velg riktig vei og reparer returruten først.
Å legge til et andre subnett i en fungerende site-til-site-tunnel tar fem minutter i det ene designet og nesten hele ettermiddagen i det andre. Når tunnelen installerer ruter for prefiksene du navngir, legger du til en rute, og trafikken følger den. Når den forhandler om ett fast selektorpar, forblir det nye prefikset ubeskyttet til begge sider blir enige om et samsvarende par. Tre ting avgjør: hva hver sides konfigurasjon faktisk beskriver, om den forhandlede trafikken innsnevres til det minste samsvarende paret, og hvem som eier returveien for det nye området.
Les kjernen, ikke statusetiketten
En tunnel som melder tilkobling har installert minst én barneassosiasjon, men ikke nødvendigvis den du tror. På Linux viser kjernen hva som brukes: ip xfrm policy lister selektorparene, og swanctl --list-sas (eller den eldre ipsec statusall) viser hva sidene forhandlet, inkludert trafikkselektorene i hver retning. Hvis det nye prefikset ikke finnes i noen av dem, er det ubeskyttet, uansett hva konfigurasjonsfilen sier.
Sammenlign med rutetabellen. I et rutedrevet oppsett er tunnelens enhet neste hopp for de beskyttede prefiksene. Et policydrevet oppsett har ofte ingen egen rute for det fjerne subnettet, bare standardruten, fordi policyen velger trafikken og ikke tabellen.
Policydrevet: begge sider må liste det nye prefikset
I strongSwan-termer ligger selektoren i local_ts og remote_ts under barnekonfigurasjonen, etterfølgerne til leftsubnet og rightsubnet. Det nye prefikset må vises på begge sider speilvendt: det side A kaller lokalt, kaller side B fjernt. Uoverensstemmelse gir sjelden en ren feil. Sidene snevres inn til snittet, det gamle prefikset virker fortsatt, og bare det nye feiler lydløst.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyPå pfSense eller OPNsense betyr det en ekstra Phase 2-oppføring som parer det nye lokale subnettet med det nye fjerne, og deretter bruk. Behold den gamle oppføringen; å erstatte den flytter det opprinnelige subnettet i stedet for å legge til. Hvis en eksisterende Phase 2 allerede dekker et supernett som 0.0.0.0/0 eller et oppsummert område, ikke legg til en smalere oppføring ved siden av: overlappende selektorer installerer konkurrerende policyer, og evalueringsrekkefølgen avgjør vinneren.
IKEv1 gjør hvert subnettpar til sin egen Phase 2, og en side som tar ett par per utveksling dropper resten. IKEv2 kan bære flere selektorpar i ett barn, men bare hvis begge implementasjonene godtar dem. Listen fra swanctl --list-sas er sannheten; det du skrev er en forespørsel.
Rutedrevet: ruten er policyen
Et XFRM-grensesnitt eller en VTI-enhet bærer trafikk etter rutetabellen. Du peker det nye prefikset mot enheten på begge steder, og tilstanden bundet til grensesnittets transformasjon gjelder. Det er ikke noe selektorpar å synkronisere, derfor skalerer dette designet bedre når subnett blir flere. strongSwans videresendingsveiledning går gjennom kjernesiden i detalj.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard går lenger. AllowedIPs er både krypto-tillatelseslisten og, via wg-quick, oppføringen i rutetabellen. Legg til prefikset bare på én side, og du får håndtrykk, utgående pakker og stillhet, fordi den fjerne siden dropper pakker hvis kilde ikke er på listen. Formen wg set erstatter hele listen, så gjenta prefiksene som allerede virket, ellers kutter 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 andre kommandoen er ikke valgfri når du brukte wg set i stedet for wg-quick. Kjernen godtar den nye listen med en gang, men ingenting legger til en rute for den, så lokalt generert trafikk går fortsatt ut via standardgatewayen. Det er den vanligste grunnen til at et nytt WireGuard-subnett virker fra tunnelverten og ikke fra en bærbar.
Returveien feiler oftere enn tunnelen
Verter på det nye fjerne subnettet må sende svar tilbake gjennom VPN-gatewayen. Når den gatewayen ikke er deres standardruter, går svaret til LAN-ruteren, som enten dropper det eller videresender det til internett med en privat kildeadresse. Test fra en vert på den fjerne siden, ikke fra gatewayen: ip route get 10.30.20.15 på Linux eller Find-NetRoute -RemoteIPAddress 10.30.20.15 i PowerShell viser neste hopp som verten faktisk bruker. Hvis svaret ikke er tunnelens endepunkt, legg til en statisk rute for det nye prefikset der.
Kilde-NAT på stedet som mangler returruten er et legitimt alternativ og måten mange hub-and-spoke-utrullinger unngår å røre hver server. Bruk det også på det nye prefikset på gatewayen på målsiden:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEKostnaden er reell. Fjernlogger slutter å vise individuelle kildeadresser, og brannmurregler knyttet til det opprinnelige subnettet faller sammen til én regel for gatewayen. Velg det med vilje, ikke fordi en rute manglet.
Brannmurer er den andre halvdelen av returveien. Sonebaserte enheter utvider ikke sonen til et eksisterende tunnelgrensesnitt til et nytt subnett automatisk, og en regel skrevet for det gamle prefikset vil ikke samsvare. Legg det nye subnettet til sonen eller regelparet i begge retninger før du klandrer IPsec.
Avgjør med tre spørsmål, verifiser så med trafikk
Kortversjonen: navngir sidens konfigurasjon prefikser (policydrevet), eller rutes trafikken inn i et grensesnitt (rutedrevet)? Lister begge ender det nye prefikset? Finnes det en vei tilbake fra det nye subnettet til det opprinnelige kildeområdet?
| 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 |
Verifisering er der de fleste endringer lukkes for tidlig. En ping fra gatewayen beviser lite, fordi gatewayen sender fra seg selv og ofte samsvarer med en annen policy enn en vert. Ping fra en vert på det nye subnettet, kjør så applikasjonen som motiverte endringen, og se på tellere 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 policydrevet tunnel skal ip xfrm state-tellerne stige i begge retninger; flate tellere betyr at pakken rutes men ikke velges. På WireGuard rapporterer wg show overføring per side, og et håndtrykk med null mottatte byte peker på den fjerne sidens liste eller dens returrute.
Avslutt med å registrere prefikset, sidens selektor eller rute, beslutningen om returveien og brannmur-oppføringen sammen med resten av tunneloversikten. Start så én gateway på nytt og test igjen: en rute lagt til for hånd forsvinner, og neste person bør ikke måtte oppdage det på nytt.