Að bæta öðru undirneti við VPN milli staða: tveir vegir
Stefnugrunduð göng þurfa samsvarandi valara á báðum hliðum; leiðargrunduð þurfa leið. Veldu rétta leið og lagaðu afturleiðina fyrst.
Að bæta öðru undirneti við virkt gang milli staða tekur fimm mínútur í annarri hönnun og næstum allan síðdegis í hinni. Þegar gangið setur upp leiðir fyrir forskeytin sem þú nefnir bætirðu leið við og umferðin fylgir henni. Þegar það semur um eitt fast valarapar, verður nýja forskeytið áfram óvarið þar til báðar hliðar samþykkja samsvarandi par. Þrjú atriði ráða: hvað stilling hvorrar hliðar lýsir í raun, hvort semjað umferð þrengist að minsta samsvarandi pari og hver á afturleiðina fyrir nýja bilið.
Lestu kjarnann, ekki stöðumerkið
Gang sem tilkynnir tengingu hefur sett upp að minnsta kosti eina barnasamtengingu, en ekki endilega þá sem þú heldur. Á Linux sýnir kjarninn hvað er beitt: ip xfrm policy telur upp valarapörin og swanctl --list-sas (eða eldra ipsec statusall) sýnir hvað hliðarnar semdu um, þar á meðal umferðarvalara í hvora átt. Ef nýja forskeytið er í hvorugu er það óvarið, hvað sem stillingaskráin segir.
Berðu þetta saman við leiðatöfluna. Í leiðargrunduðu fyrirkomulagi er gangtækið næsta stökk fyrir varin forskeyti. Stefnugrundað fyrirkomulag hefur oft enga sérstaka leið fyrir fjarlæga undirnetið, aðeins sjálfgefnu leiðina, því stefnan velur umferðina en ekki taflan.
Stefnugrunduð göng: báðar hliðar verða að telja upp nýja forskeytið
Í hugtökum strongSwan býr valarinn í local_ts og remote_ts undir barnastillingunni, arftakum leftsubnet og rightsubnet. Nýja forskeytið verður að birtast á báðum hliðum speglað: það sem staður A kallar staðbundið kallar staður B fjarlægt. Ósamræmi gefur sjaldan hreina villu. Hliðarnar þrengjast að sniðmótinu, gamla forskeytið heldur áfram að virka og aðeins það nýja bregst hljóðlaust.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyÁ pfSense eða OPNsense þýðir það aðra Phase 2 færslu sem parar nýja staðbundna undirnetið við nýja fjarlæga, og svo beitingu. Haltu gömlu færslunni; að skipta henni færir upprunalega undirnetið í stað þess að bæta við. Ef fyrirliggjandi Phase 2 nær þegar yfir ofurnet eins og 0.0.0.0/0 eða samantektarbil, bættu ekki þrengri færslu við hliðina: skarast valarar setja upp samkeppnandi stefnur og matsröðin ræður sigurvegaranum.
IKEv1 gerir hvert undirnetspar að eigin Phase 2 og hlið sem tekur eitt par fyrir hver skipti hendir hinum. IKEv2 getur borið nokkur valarapör í einu barni, en aðeins ef báðar útfærslur samþykkja þau. Listinn frá swanctl --list-sas er sannleikurinn; það sem þú skrifaðir er beiðni.
Leiðargrunduð göng: leiðin er stefnan
XFRM viðmót eða VTI tæki ber umferð samkvæmt leiðatöflunni. Þú beinir nýja forskeytinu að tækinu á báðum stöðum og staðan sem bundin er umbreytingu viðmótsins gildir. Ekkert valarapar er að samstilla, þess vegna skalar þessi hönnun betur þegar undirnetum fjölgar. Leiðarvísir strongSwan um framsendingu fer ítarlega í kjarnahliðina.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard gengur lengra. AllowedIPs er bæði dulritunarleyfislistinn og, í gegnum wg-quick, færslan í leiðatöflunni. Bættu forskeytinu aðeins við aðra hlið og þú færð handaband, útfararpakka og þögn, því fjarlæga hliðin hendir pökkum sem eiga uppruna sinn ekki á listanum. Formið wg set skiptir um allan listann, svo endurtaktu forskeytin sem virkuðu þegar eða þú skerð þau 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 wg0Þessi seinni skipun er ekki valkvæð þegar þú notaðir wg set í stað wg-quick. Kjarninn samþykkir nýja listann strax, en ekkert bætir við leið fyrir hann, svo umferð sem verður til staðbundið fer enn út um sjálfgefnu gáttina. Þetta er algengasta ástæðan fyrir því að nýtt WireGuard undirnet virkar frá ganghýslinu en ekki fartölvu.
Afturleiðin bregst oftar en gangið
Hýslar á nýja fjarlæga undirnetinu verða að senda svör til baka um VPN-gáttina. Þegar sú gátt er ekki sjálfgefni beinirinn þeirra fer svarið til LAN-beinisins, sem annaðhvort hendir því eða sendir það áfram á netið með einka upprunafangi. Prófaðu frá hýsli á fjarlægu hliðinni, ekki frá gáttinni: ip route get 10.30.20.15 á Linux eða Find-NetRoute -RemoteIPAddress 10.30.20.15 í PowerShell sýnir næsta stökk sem hýsillinn notar í raun. Ef svarið er ekki endapunktur gangsins skaltu bæta kyrrstæðri leið fyrir nýja forskeytið þar.
Upprunanat á staðnum sem vantar afturleiðina er lögmætur valkostur og leiðin sem margar hub-and-spoke uppsetningar forðast að snerta hvern netþjón. Beittu því einnig á nýja forskeytið á gátt áfangastaðar:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEKostnaðurinn er raunverulegur. Fjarlæg skrár hætta að sýna einstök upprunaföng og eldvarnarreglur sem byggja á upprunalega undirnetinu falla saman í eina reglu fyrir gáttina. Veldu það af ásettu ráði, ekki vegna þess að leið vantaði.
Eldveggir eru hinn helmingurinn af afturleiðinni. Tæki sem byggja á svæðum víkka ekki svæði fyrirliggjandi gangviðmóts út á nýtt undirnet sjálfkrafa og regla skrifuð fyrir gamla forskeytið passar ekki. Bættu nýja undirnetinu við svæðið eða regluparið í báðar áttir áður en þú kennir IPsec um.
Ákveddu með þremur spurningum og staðfestu svo með umferð
Stutta útgáfan: nefnir stilling hliðarinnar forskeyti (stefnugrundað), eða er umferð beint inn í viðmót (leiðargrundað)? Telja báðir endar upp nýja forskeytið? Er leið til baka frá nýja undirnetinu að upprunalega upprunabilinu?
| 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 |
Staðfesting er þar sem flestar breytingar eru lokaðar of fljótt. Ping frá gáttinni sannar lítið, því gáttin sendir frá sér og passar oft við aðra stefnu en hýsill. Pingaðu frá hýsli á nýja undirnetinu, keyrðu svo forritið sem olli breytingunni og fylgstu með teljurum, ekki stöðutákni.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showÁ stefnugrunduðu gangi eiga teljarar ip xfrm state að hækka í báðar áttir; flöt tölur þýða að pakkinn er leiðbeint en ekki valinn. Á WireGuard sýnir wg show flutning á hverri hlið og handaband með núll mótteknum bætum vísar á lista fjarlægu hliðarinnar eða afturleið hennar.
Endaðu á að skrá forskeytið, valara eða leið hliðarinnar, ákvörðunina um afturleiðina og eldvarnarfærsluna með restinni af gangseigninni. Endurræstu svo eina gátt og prófaðu aftur: leið sem bætt var við handvirkt hverfur og næsta manneskja ætti ekki að þurfa að uppgötva það aftur.