Bigarren azpisare bat gune arteko VPNari gehitzea: bi bide
Politikan oinarritutako tunelek hautatzaile berdinak behar dituzte mutur bietan; bideetan oinarritutakoek bide bat. Aukeratu bide egokia eta konpondu itzulera-bidea lehenengo.
Funtzionatzen duen gune arteko tunel bati bigarren azpisare bat gehitzeak bost minutu hartzen ditu diseinu batean eta ia arratsalde osoa bestean. Tunelak izendatzen dituzun prefijoei bideak instalatzen dizkienean, bide bat gehitzen duzu eta trafikoak jarraitzen dio. Hautatzaile pare finko bat negoziatzen duenean, prefijo berria babesik gabe geratzen da bi muturrek pare bat adosten duten arte. Hiru gauzek erabakitzen dute kasua: mutur bakoitzaren konfigurazioak benetan zer deskribatzen duen, negoziatutako trafikoak pare txikienarekin bat egiten duen eta nor den tarte berriaren itzulera-bidearen jabea.
Irakurri nukleoa, ez egoera-etiketa
Konexioa jakinarazten duen tunelak gutxienez erlazio haur bat instalatu du, baina ez duzun uste duzuna. Linuxen nukleoak aplikatzen dena erakusten du: ip xfrm policy-k hautatzaile pareak zerrendatzen ditu eta swanctl --list-sas-ek (edo ipsec statusall zaharrak) muturrek negoziatu zutena erakusten du, norabide bakoitzeko trafiko-hautatzaileak barne. Prefijo berria batean ere agertzen ez bada, babesik gabe dago, konfigurazio-fitxategiak zer esan ere.
Konparatu bide-taularekin. Bideetan oinarritutako diseinuan tunelaren gailua da babestutako prefijoen hurrengo jauzia. Politikan oinarritutako diseinuak sarritan ez du bide zehatzik urruneko azpisarerako, lehenespen-bidea soilik, politikak hautatzen baitu trafikoa eta ez taulak.
Politikan oinarritutako tunelak: bi muturrek prefijo berria zerrendatu behar dute
strongSwan terminoetan hautatzailea haur-konfigurazioko local_ts eta remote_ts barruan bizi da, leftsubnet eta rightsubnetren ondorengoak. Prefijo berria bi muturretan ispilu gisa agertu behar da: A guneak tokikotzat duena B guneak urruntzat du. Desadostasunak gutxitan ematen du errore garbirik. Muturrek ebakiduraraino estutzen dira, prefijo zaharrak funtzionatzen jarraitzen du eta berriak isilik huts egiten du.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policypfSense edo OPNsense-n horrek esan nahi du tokiko azpisare berria urruneko berriarekin parekatzen duen Phase 2 sarrera bat gehiago, eta gero aplikatu. Mantendu sarrera zaharra; ordezkatzeak jatorrizko azpisarea mugitzen du gehitu beharrean. Dagoen Phase 2 batek 0.0.0.0/0 bezalako super-sare bat edo laburbildutako tarte bat estaltzen badu, ez gehitu sarrera estuagoa ondoan: hautatzaile gainjarriek politika lehiakorrak instalatzen dituzte eta ebaluazio-ordenak erabakitzen du nork irabazi.
IKEv1-ek azpisare pare bakoitza bere Phase 2 bihurtzen du, eta truke bakoitzeko pare bat hartzen duen muturrak gainerakoak baztertzen ditu. IKEv2-k hainbat hautatzaile pare eraman ditzake haur bakar batean, baina bi inplementazioek onartzen badituzte soilik. swanctl --list-sas-tik datorren zerrenda da egia; idatzi duzuna eskaera bat da.
Bideetan oinarritutako tunelak: bidea da politika
XFRM interfaze batek edo VTI gailu batek bide-taularen arabera eramaten du trafikoa. Prefijo berria gailura zuzentzen duzu bi guneetan, eta interfazearen transformazioari lotutako egoera aplikatzen da. Ez dago sinkronizatzeko hautatzaile parearik, horregatik diseinu honek hobeto eskalatzen du azpisareak ugaritzean. strongSwan-en birbidaltze-gidak nukleoaren aldea xehetasunez azaltzen du.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard-ek ideia urrunago eramaten du. AllowedIPs aldi berean kripto-baimen zerrenda da eta, wg-quick bidez, bide-taulako sarrera. Gehitu prefijoa mutur batean soilik eta eskuko keinua, irteerako paketeak eta isiltasuna lortuko dituzu, urruneko aldeak bere zerrendan iturririk ez duen paketea baztertzen baitu. wg set formak zerrenda osoa ordezkatzen du, beraz errepikatu lehen funtzionatzen zuten prefijoak edo moztu egingo dituzu:
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 wg0Bigarren komando hori ez da hautazkoa wg set wg-quickren ordez erabili baduzu. Nukleoak berehala onartzen du baimen-zerrenda berria, baina ezerk ez dio biderik gehitzen, beraz tokian sortutako trafikoak lehenespen-atebidea erabiltzen jarraitzen du. Hori da WireGuard azpisare berri bat tunelaren ostalaritik funtzionatzearen eta eramangarritik ez funtzionatzearen arrazoi ohikoena.
Itzulera-bideak tunelek baino gehiagotan huts egiten du
Urruneko azpisare berriko ostalariek erantzunak VPN atebidetik bidali behar dituzte. Atebide hori haien lehenespen-bideratzailea ez denean, erantzuna LAN bideratzailera joaten da, eta hark baztertu edo internet-era birbidaltzen du iturri-helbide pribatuarekin. Probatu urruneko aldeko ostalari batetik, ez atebidetik: ip route get 10.30.20.15 Linuxen edo Find-NetRoute -RemoteIPAddress 10.30.20.15 PowerShell-en ostalarik benetan erabiliko duen hurrengo jauzia erakusten du. Erantzuna tunelaren amaiera ez bada, gehitu han bide estatikoa prefijo berriarentzat.
Itzulera-bidea falta duen gunean iturri-NAT alternatiba zilegia da eta hub-and-spoke hedapen askok horrela saihesten dute zerbitzari bakoitza ukitzea. Aplikatu prefijo berriari helmugako aldeko atebidean ere:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEKostua erreala da. Urruneko erregistroek iturri-helbide indibidualak erakusteari uzten diote, eta jatorrizko azpisareari lotutako suebaki-arauak atebidearentzako arau bakarrean biltzen dira. Aukeratu hori nahita, ez bide bat falta zelako.
Suebakiek itzulera-bidearen beste erdia osatzen dute. Eremutan oinarritutako gailuek ez dute tunel-interfaze baten eremua automatikoki azpisare berrira zabaltzen, eta prefijo zaharrerako idatzitako arauak ez du bat egingo. Gehitu azpisare berria eremura edo arau-pareari bi norabideetan IPsec-i errua bota aurretik.
Erabaki hiru galderarekin, gero egiaztatu trafikoarekin
Bertsio azkarra: muturreko konfigurazioak prefijoak izendatzen ditu (politikan oinarritua) edo trafikoa interfaze batera bideratzen da (bideetan oinarritua)? Bi muturrek zerrendatzen dute prefijo berria? Bada biderik azpisare berritik jatorrizko iturri-tartera?
| 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 |
Egiaztatzea da aldaketa gehienak goizegi ixten diren tokia. Atebidetik egindako ping-ek gutxi frogatzen du, atebideak bere burutik bidaltzen baitu eta sarritan ostalariak baino politika desberdinarekin bat egiten baitu. Egin ping azpisare berriko ostalari batetik, gero exekutatu aldaketa eragin zuen aplikazioa, eta begiratu kontagailuei, ez egoera-ikonoari.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showPolitikan oinarritutako tunelean ip xfrm state-ren kontagailuek bi norabideetan igo behar dute; kontagailu lauek paketea bideratuta baina hautatu gabe dagoela esan nahi dute. WireGuard-en wg show-k mutur bakoitzeko transferentzia erakusten du, eta zero byte jasotako eskuko keinuek urruneko aldearen zerrendara edo haren itzulera-bidera seinalatzen dute.
Amaitu prefijoa, muturreko hautatzailea edo bidea, itzulera-bidearen erabakia eta suebaki-sarrera tunel-inbentarioaren gainerakoarekin batera erregistratuz. Gero berrabiarazi atebide bat eta probatu berriro: eskuz gehitutako bide bat desagertu egiten da eta hurrengo pertsonak ez luke berriro aurkitu behar.