Leggje til eit andre subnett i ein site-til-site VPN: to vegar
Policystyrte tunnelar treng samsvarande selektorar på begge sider; rutestyrte treng ei rute. Vel rett veg og reparer returruta fyrst.
Å leggje til eit andre subnett i ein fungerande site-til-site-tunnel tek fem minutt i det eine designet og nesten heile ettermiddagen i det andre. Når tunnelen installerer ruter for prefiksa du namngjev, legg du til ei rute, og trafikken følgjer henne. Når han forhandlar om eitt fast selektorpar, vert det nye prefikset verande uverna til begge sider blir samde om eit samsvarande par. Tre ting avgjer: kva kvar side si konfigurasjon faktisk skildrar, om den forhandla trafikken blir snevra inn til det minste samsvarande paret, og kven som eig returvegen for det nye området.
Les kjernen, ikkje statusetiketten
Ein tunnel som melder tilkopling har installert minst éin barneassosiasjon, men ikkje nødvendigvis den du trur. På Linux viser kjernen kva som blir brukt: ip xfrm policy listar selektorpara, og swanctl --list-sas (eller den eldre ipsec statusall) viser kva sidene forhandla, inkludert trafikkselektorane i kvar retning. Finst ikkje det nye prefikset i nokon av dei, er det uverna, kva konfigurasjonsfila enn seier.
Samanlikn med rutetabellen. I eit rutestyrt oppsett er tunneleininga neste hopp for dei verna prefiksa. Eit policystyrtoppsett har ofte inga eiga rute for det fjerne subnettet, berre standardruta, fordi policyen vel trafikken og ikkje tabellen.
Policystyrte: begge sider må liste det nye prefikset
I strongSwan-termar ligg selektoren i local_ts og remote_ts under barnekonfigurasjonen, etterfylgjarane til leftsubnet og rightsubnet. Det nye prefikset må visast på begge sider spegelvendt: det side A kallar lokalt, kallar side B fjernt. Uoverenskomst gjev sjeldan ein rein feil. Sidene blir snevra inn til snittet, det gamle prefikset verkar vidare, og berre det nye feilar lydlaust.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyPå pfSense eller OPNsense tyder det ein ekstra Phase 2-oppføring som parar det nye lokale subnettet med det nye fjerne, og så bruk. Hald på den gamle oppføringa; å byte henne flyttar det opphavlege subnettet i staden for å leggje til. Om ein eksisterande Phase 2 alt dekkjer eit supernett som 0.0.0.0/0 eller eit oppsummert område, ikkje legg til ei smalare oppføring ved sida: overlappande selektorar installerer konkurrerande policyar, og vurderingsrekkjefølgja avgjer vinnaren.
IKEv1 gjer kvart subnettpar til sin eigen Phase 2, og ei side som tek eitt par per utveksling droppar resten. IKEv2 kan bera fleire selektorpar i eitt barn, men berre om begge implementasjonane godtek dei. Lista frå swanctl --list-sas er sanninga; det du skreiv er ein førespurnad.
Rutestyrte: ruta er policyen
Eit XFRM-grensesnitt eller ei VTI-eining ber trafikk etter rutetabellen. Du peikar det nye prefikset mot eininga på begge stadene, og tilstanden bunden til transformasjonen av grensesnittet gjeld. Det er ikkje noko selektorpar å synkronisere, difor skalerer dette designet betre når subnett blir fleire. strongSwan si vidaresendingrettleiing går gjennom kjernesida 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-tillatingslista og, via wg-quick, oppføringa i rutetabellen. Legg til prefikset berre på éi side, og du får handtrykk, utgåande pakkar og stille, fordi den fjerne sida droppar pakkar der kjelda ikkje står på lista. Forma wg set byter ut heile lista, så repeat prefiksa som alt verka, elles kuttar du dei:
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 ikkje valfri når du brukte wg set i staden for wg-quick. Kjernen godtek den nye lista med ein gong, men ingenting legg til ei rute for henne, så lokalt generert trafikk går framleis ut via standardporten. Det er den vanlegaste grunnen til at eit nytt WireGuard-subnett verkar frå tunnelverten og ikkje frå ein berbar.
Returvegen feilar oftare enn tunnelen
Vertar på det nye fjerne subnettet må senda svar tilbake gjennom VPN-porten. Når den porten ikkje er standardrutaren deira, går svaret til LAN-rutaren, som anten droppar det eller sender det vidare til internett med ei privat kjeldeadresse. Test frå ein vert på den fjerne sida, ikkje frå porten: 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 brukar. Om svaret ikkje er endepunktet til tunnelen, legg til ei statisk rute for det nye prefikset der.
Kjelde-NAT på staden som manglar returruta er eit legitimt alternativ og måten mange hub-and-spoke-utrullingar unngår å røre kvar tenar. Bruk det òg på det nye prefikset på porten på målssida:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEKostnaden er reell. Fjernlogger sluttar å vise individuelle kjeldeadresser, og brannmurreglar knytte til det opphavlege subnettet fell saman til éin regel for porten. Vel det med vilje, ikkje fordi ei rute mangla.
Brannmurar er den andre halvdelen av returvegen. Sonebaserte einingar utvidar ikkje sona til eit eksisterande tunnelgrensesnitt til eit nytt subnett automatisk, og ein regel skriven for det gamle prefikset vil ikkje passe. Legg det nye subnettet til sona eller regelpareet i båe retningar før du klandrar IPsec.
Avgjer med tre spørsmål, verifiser så med trafikk
Kortversjonen: namngjev konfigurasjonen til sida prefiks (policystyrtoppsett), eller blir trafikken ruta inn i eit grensesnitt (rutestyrt)? Listar båe endane det nye prefikset? Finst det ein veg tilbake frå det nye subnettet til det opphavlege kjeldeområ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 dei fleste endringane blir lukka for tidleg. Ein ping frå porten beviser lite, fordi porten sender frå seg sjølv og ofte passar med ein annan policy enn ein vert. Ping frå ein vert på det nye subnettet, køyr så applikasjonen som motiverte endringa, og sjå på teljarar i staden for eit statusikon.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showPå ein policystyrtoppsett skal ip xfrm state-teljarane stige i båe retningar; flate teljarar tyder at pakken blir ruta men ikkje vald. På WireGuard melder wg show overføringa per side, og eit handtrykk med null mottekne byte peikar på lista til den fjerne sida eller returruta hennar.
Avslutt med å registrere prefikset, selektoren eller ruta til sida, avgjerda om returvegen og brannmur-oppføringa saman med resten av tunneloversynet. Start så ein port på nytt og test igjen: ei rute lagd til for hand forsvinn, og neste person bør ikkje måtte oppdage det på nytt.