Å legge et andre subnett til en site-til-site VPN: to veier
Policytunneler krever samsvarende selektorer i begge ender; rutetunneler krever en rute. Velg riktig vei, og rett opp returruten først.
Å legge et andre subnett til en VPN-tunnel mellom to steder som virker tar fem minutter i det ene designet og det meste av en ettermiddag i det andre. Når tunnelen legger inn ruter for prefiksene du navngir, legger du til en rute, og trafikken følger den. Når den forhandler én fast selektorpair, blir det nye prefikset stående ubeskyttet til begge sider er enige om en samsvarende pair. Tre forhold avgjør: hva konfigurasjonen på hver side faktisk beskriver, om den forhandlede trafikken innsnevres til den minste samsvarende pairen, og hvem som eier returveien for det nye området.
Les kjernen, ikke statusetiketten
En tunnel som melder «tilkoblet» har minst én barneassosiasjon, men ikke nødvendigvis den du tror. På Linux viser kjernen hva som faktisk brukes: ip xfrm policy lister selektorpairene, og swanctl --list-sas (eller eldre ipsec statusall) viser hva sidene forhandlet frem, inkludert trafikkselektorene i hver retning. Hvis det nye prefikset ikke finnes i noen av dem, er det ubeskyttet uansett hva konfigurasjonsfilen påstår.
Sammenlign med rutetabellen. I et rutebasert oppsett er tunneleenheten neste hopp for de beskyttede prefiksene. Et policybasert oppsett mangler ofte en egen rute til det fjerne subnettet og har bare standardruten, fordi det er policyen og ikke tabellen som velger trafikken.
Policybasert: begge sider må føre opp det nye prefikset
I strongSwan-sjargong sitter selektoren i local_ts og remote_ts under barnekonfigurasjonen, etterfølgerne av leftsubnet og rightsubnet. Det nye prefikset må stå på begge sider som et speilbilde: det side A kaller lokalt, kaller side B fjernt. Uoverensstemmelse gir sjelden en ren feilmelding. Sidene snevres inn til snittet, det gamle prefikset virker fortsatt, og bare det nye feiler i stillhet.
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; erstatter du den, flyttes det opprinnelige subnettet i stedet for at det legges til. Dekker en eksisterende Phase 2 allerede et supernett som 0.0.0.0/0 eller et oppsummert område, skal du ikke legge en smalere oppføring ved siden av: overlappende selektorer installerer konkurrerende policyer, og evalueringsrekkefølgen avgjør hvem som vinner.
IKEv1 gir hvert subnettpar sin egen Phase 2, og en side som tar én pair per utveksling, dropper resten. IKEv2 kan bære flere selektorpaire i ett barn, men bare hvis begge implementasjonene godtar dem. Listen fra swanctl --list-sas er sannheten; det du skrev, er en forespørsel.
Rutebasert: 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 som er bundet til grensesnittets transformasjon, gjelder. Det finnes ingen selektorpair å holde synkronisert, og derfor skalerer dette designet bedre når subnettene blir flere. strongSwans veiledning for videresending går grundigere inn på kjernesiden.
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. Legger du prefikset bare på én side, får du håndtrykk, utgående pakker og stillhet, fordi den fjerne siden forkaster pakker der kilden ikke står 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 umiddelbart, men ingenting legger til en rute for den, så lokalt generert trafikk går fortsatt ut gjennom standardgatewayen. Det er den vanligste grunnen til at et nytt WireGuard-subnett virker fra tunnelverten og ikke fra en bærbar maskin.
Returveien svikter oftere enn selve tunnelen
Verter på det nye fjerne subnettet må sende svar tilbake gjennom VPN-gatewayen. Når den gatewayen ikke er standardruteren deres, går svaret til LAN-ruteren, som enten forkaster 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. Er svaret ikke tunnelens endepunkt, legg til en statisk rute for det nye prefikset der.
Kilde-NAT på stedet som mangler returvei, er et legitimt alternativ og måten mange hub-and-spoke-utrullinger slipper å røre hver enkelt 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 MASQUERADEPrisen er reell. Fjernlogger slutter å vise individuelle kildeadresser, og brannmurregler som er knyttet til det opprinnelige subnettet, faller sammen til én regel for gatewayen. Velg det med overlegg, ikke fordi en rute manglet.
Brannmurene er den andre halvdelen av returveien. Sonebaserte enheter utvider ikke sonen til et eksisterende tunnelgrensesnitt til et nytt subnett automatisk, og en regel som er skrevet for det gamle prefikset, vil ikke passe. Legg det nye subnettet til sonen eller regel-pairet i begge retninger før du gir IPsec skylden.
Avgjør med tre spørsmål, og verifiser med trafikk
Kortversjonen: nevner konfigurasjonen på siden prefikser (policybasert), eller rutes trafikken inn i et grensesnitt (rutebasert)? 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 |
Verifiseringen er der de fleste endringer lukkes for tidlig. En ping fra gatewayen beviser lite, fordi gatewayen sender fra seg selv og ofte treffer en annen policy enn en vert. Ping fra en vert på det nye subnettet, kjør så applikasjonen som var grunnen til 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 policybasert tunnel skal ip xfrm state-tellerne øke i begge retninger; flate tellere betyr at pakken rutes men ikke velges. På WireGuard rapporterer wg show overføringen per side, og et håndtrykk uten mottatte byte peker på den fjerne sidens liste eller returveien dens.
Til slutt: registrer prefikset, selektoren eller ruten på siden, beslutningen om returveien og brannmur-oppføringen sammen med resten av tunneloversikten. Start så én gateway på nytt og test igjen: en rute som er lagt til for hånd, forsvinner, og neste person bør slippe å oppdage det på nytt.