Tweede subnet by ’n site-tot-site-VPN voeg: twee weë
Beleidsgebaseerde tonnels het passende keurders aan beide kante nodig; roetegebaseerde een ’n roete. Kies die regte pad en maak eers die terugroete reg.
Om ’n tweede subnet by ’n werkende site-tot-site-tonnel te voeg, neem vyf minute met die een ontwerp en ’n hele middag met die ander. Wanneer die tonnel roetes vir die voorvoegsels installeer, voeg jy ’n roete by en die verkeer volg dit. Wanneer dit een vaste keurderpaar onderhandel, bly die nuwe voorvoegsel onbeskermd totdat beide kante oor ’n passende paar ooreenkom. Drie dinge bepaal in watter geval jy is: wat elke kant se konfigurasie werklik beskryf, of die onderhandelde verkeer tot die kleinste passende paar vernou word, en wie die terugpad vir die nuwe reeks besit.
Lees die kernel, nie die statusetiket nie
’n Tonnel wat as verbind rapporteer, het ten minste een kindassosiasie geïnstalleer, nie noodwendig die een wat jy dink nie. Op Linux wys die kernel wat toegepas word: ip xfrm policy lys die keurderpare, en swanctl --list-sas (of die ouer ipsec statusall) wys wat die kante onderhandel het, insluitend die verkeerskeurders in elke rigting. As die nuwe voorvoegsel in nie een verskyn nie, is dit onbeskermd, ongeag wat die konfigurasielêer sê.
Vergelyk dit met die roetetabel. By ’n roetegebaseerde opstelling is die tonneltoestel die volgende sprong vir die beskermde voorvoegsels. ’n Beleidsgebaseerde opstelling het dikwels geen spesifieke roete vir die afgeleë subnet nie, net die verstekroete, omdat die beleid verkeer kies eerder as die tabel.
Beleidsgebaseerde tonnels: beide kante moet die nuwe voorvoegsel lys
In strongSwan-terme woon die keurder in local_ts en remote_ts onder die kindkonfigurasie, die opvolgers van leftsubnet en rightsubnet. ’n Nuwe voorvoegsel moet op beide kante verskyn, gespieël: wat werf A plaaslik noem, noem werf B afgeleë. ’n Wanverhouding lewer selde ’n skoon fout. Die kante vernou tot die snijpunt, so die ou voorvoegsel bly werk en net die nuwe een misluk stil.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyOp pfSense of OPNsense beteken dit ’n tweede Phase 2-inskrywing wat die nuwe plaaslike subnet met die nuwe afgeleë subnet paar, en dan toe te pas. Hou die ou inskrywing; om dit te vervang skuif die oorspronklike subnet eerder as om by te voeg. As ’n bestaande Phase 2 reeds ’n supernet soos 0.0.0.0/0 of ’n saamgevatte reeks dek, moenie ’n nouer inskrywing daarlangs byvoeg nie: oorvleuelende keurders installeer mededingende beleide, en evalueringsorde bepaal wie wen.
IKEv1 maak elke subnetpaar sy eie Phase 2, en ’n kant wat een paar per uitruiling neem, laat die res val. IKEv2 kan verskeie keurderpare in een kind dra, maar net as beide implementasies dit aanvaar. Die lys van swanctl --list-sas is die waarheid; wat jy getik het, is ’n versoek.
Roetegebaseerde tonnels: die roete is die beleid
’n XFRM-koppelvlak of ’n VTI-toestel dra verkeer volgens die roetetabel. Jy wys die nuwe voorvoegsel op beide terreine na die toestel, en die toestand wat aan die koppelvlak se transformasie gebind is, geld. Daar is geen keurderpaar om in sync te hou nie, en daarom skaleer hierdie ontwerp beter soos subnette vermeerder. Die strongSwan-aanstuurhandleiding behandel die kernelkant daarvan in meer detail.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard neem dieselfde idee verder. AllowedIPs is gelyktydig die kripto-toelaatlys en, via wg-quick, die roetetabelinskrywing. Voeg die voorvoegsel net op een kant by en jy kry ’n handdruk, uitgaande pakkette en stilte, want die verre kant laat pakkette val wie se bron nie in sy toelaatlys is nie. Die wg set-vorm vervang die hele lys, so herhaal die voorvoegsels wat reeds gewerk het, of jy sny hulle af:
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 wg0Daardie tweede opdrag is nie opsioneel wanneer jy wg set in plaas van wg-quick gebruik het nie. Die kernel aanvaar die nuwe toelaatlys dadelik, maar niks voeg ’n roete daarvoor by nie, so plaaslik gegenereerde verkeer verlaat steeds die verstekpoort. Dit is die algemeenste rede waarom ’n nuwe WireGuard-subnet van die tonnelgasheer werk en nie van ’n skootrekenaar nie.
Die terugpad misluk dikwels meer as die tonnel
Gashere op die nuwe afgeleë subnet moet antwoorde deur die VPN-poort terugstuur. Wanneer daardie poort nie hul verstekroeteerder is nie, gaan die antwoord na die LAN-roeteerder, wat dit óf laat val óf dit met ’n private bronadres na die internet aanstuur. Toets van ’n gasheer aan die verre kant eerder as van die poort: ip route get 10.30.20.15 op Linux of Find-NetRoute -RemoteIPAddress 10.30.20.15 in PowerShell wys die volgende sprong wat die gasheer werklik sal gebruik. As die antwoord nie die tonnel-eindpunt is nie, voeg ’n statiese roete vir die nuwe voorvoegsel daar by.
Bron-NAT op die terrein sonder die terugroete is ’n geldige alternatief en hoe baie hub-en-spoke-ontplooiings vermy om elke bediener aan te raak. Pas dit ook op die nuwe voorvoegsel by die poort aan die bestemmingskant toe:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEDie koste is werklik. Afgeleë logboeke wys nie meer individuele bronadresse nie, en firewall-reëls wat op die oorspronklike subnet gemik is, val saam in een reël vir die poort. Kies dit doelbewus, nie omdat ’n roete ontbreek het nie.
Firewalls is die ander helfte van die terugpad. Sonegebaseerde toestelle brei nie outomaties ’n bestaande tonnelkoppelvlak se sone na ’n nuwe subnet uit nie, en ’n reël wat teen die ou voorvoegsel geskryf is, sal nie pas nie. Voeg die nuwe subnet by die sone of die reëlpaar in beide rigtings voordat jy IPsec blameer.
Besluit in drie vrae en verifieer dan met verkeer
Die vinnige weergawe: noem die konfigurasie van die kant voorvoegsels (beleidsgebaseerd), of roeteverkeer na ’n koppelvlak (roetegebaseerd)? Lys beide kante die nuwe voorvoegsel? Is daar ’n pad terug van die nuwe subnet na die oorspronklike bronreeks?
| 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 |
Verifikasie is waar die meeste veranderinge te vroeg gesluit word. ’n Ping vanaf die poort bewys min, want die poort stuur vanaf homself en pas dikwels ’n ander beleid as ’n gasheer. Ping vanaf ’n gasheer op die nuwe subnet, hardloop dan die toepassing wat die verandering gemotiveer het, en kyk na tellers eerder as na ’n statusikoon.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showOp ’n beleidsgebaseerde tonnel behoort die ip xfrm state-tellers in beide rigtings te styg; plat tellers beteken die pakket word gerouteer maar nie gekies nie. Op WireGuard rapporteer wg show oordrag per kant, en ’n handdruk met nul ontvangde grepe wys na die verre kant se toelaatlys of sy terugroete.
Sluit af deur die voorvoegsel, die keurder of roete aan die kant, die terugpad-besluit en die firewall-inskrywing saam met die res van die tonnelinventaris te boekstaaf. Herbegin dan een poort en toets weer: ’n roete wat met die hand bygevoeg is, verdwyn, en die volgende persoon moet dit nie weer ontdek nie.