En zweet Subnetz zu engem Site-to-Site VPN derbäisetzen: zwee Weeër
Politikbaséiert Tunnellen brauchen op béide Säiten passend Selektoren; routbaséiert brauchen eng Route. Wielt de richtege Wee a fléckt d’Réckroute als éischt.
En zweet Subnetz zu engem funktionéierenden Site-to-Site-Tunnel derbäisetzen dauert an enger Konzept fënnef Minutten an an der anerer bal de ganzen Nomëtteg. Wann den Tunnel Routen fir déi genannten Prefixen installéiert, setzt Dir eng Route derbäi an den Traffic follegt hir. Wann en eng fix Selektorespaar verhandelt, bleift den neie Prefix ongeschützt bis béid Säiten sech op eng passend Paar eeneg ginn. Dräi Saachen entscheeden: wat d’Konfiguratioun vun all Säit wierklech beschreift, ob den ausgehandelten Traffic op déi klengst passend Paar verengt gëtt, a wiem d’Réckroute fir den neien Beräich gehéiert.
Liest de Kernel, net d’Statusetiquette
En Tunnel dee Verbindung mëttelt huet op d’mannst eng Kannerassociatioun installéiert, awer net onbedéngt déi wou Dir denkt. Ënner Linux weist de Kernel wat ugewannt gëtt: ip xfrm policy zielt d’Selektorespueren op an swanctl --list-sas (oder deenen ale ipsec statusall) weist wat d’Säiten ausgehandelt hunn, inklusiv d’Trafficselektoren an all Richtung. Wann den neie Prefix an keen vun deenen zwee steet, ass en ongeschützt, wat d’Konfiguratiounsdatei och seet.
Vergläicht dat mat der Routentabell. An enger routbaséierter Opstellung ass den Tunnelapparat den nächsten Hop fir déi geschützt Prefixen. Eng politikbaséiert Opstellung huet dacks keng eegen Route fir dat wäit Subnetz, just d’Standardroute, well d’Politik den Traffic wielt an net d’Tabell.
Politikbaséiert Tunnellen: béid Säiten mussen den neie Prefix oplëschten
An strongSwan-Begrëffer sëtzt de Selektor an local_ts an remote_ts ënner der Kannerkonfiguratioun, den Nofollger vu leftsubnet an rightsubnet. Den neie Prefix muss op béide Säiten gespigelt erschéngen: wat Site A lokal nennt, nennt Site B wäit. Eng Differenz gëtt seelen eng propper Feeler. D’Säiten verengen sech op den Schnëtt, den ale Prefix schafft weider an nëmmen den neien scheitert stëll.
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyOp pfSense oder OPNsense heescht dat en zweeten Phase 2-Andrag deen dat neit lokal Subnetz mat deem neie wäitem paart, an duerno eng Uwendung. Behaalt den alen Andrag; en ersetzen verréckelt dat ursprénglech Subnetz amplaz et derbäizesetzen. Wann en existéierende Phase 2 schonn en Iwwernet wéi 0.0.0.0/0 oder en zesummegefasste Beräich deckt, setzt keng eng méi schmuel Andrag dernieft: iwwerlappend Selektoren installéiere konkurréierend Politiken an d’Auswäertungsuerdnung entscheet de Gewënner.
IKEv1 mécht aus all Subnetzpaar eng eegen Phase 2, an eng Säit déi eng Paar pro Austausch hëlt verwërft de Rescht. IKEv2 kann e puer Selektorespueren an engem Kand droen, awer nëmmen wann béid Implementatiounen se akzeptéieren. D’Lëscht vun swanctl --list-sas ass d’Wourecht; wat Dir getippt hutt ass eng Ufro.
Routbaséiert Tunnellen: d’Route ass d’Politik
Eng XFRM-Schnittstell oder en VTI-Apparat dréit den Traffic no der Routentabell. Dir weist den neie Prefix op béide Siten op den Apparat, an den Zoustand deen un d’Transformatioun vun der Schnittstell gebonnen ass gëlt. Et gëtt keng Selektorespaar ze synchroniséieren, dofir skaléiert dës Konzept besser wann d’Subnetzen sech vermehren. Den strongSwan-Leitfaden zur Weiderleitung geet méi genee op d’Kernelsäit an.
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard geet weider. AllowedIPs ass gläichzäiteg d’Krypto-Erlafnislëscht an, iwwer wg-quick, den Andrag an der Routentabell. Setzt den Prefix just op enger Säit derbäi an Dir kritt e Handschlag, erausgehend Paketen an Stëllt, well déi wäit Säit Paketen verwërft deenen hir Quell net op hirer Lëscht steet. D’Form wg set ersetzt déi ganz Lëscht, also widderhëlt d’Prefixen déi schonn geschafft hunn, soss schneit Dir se of:
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 wg0Déi zweet Kommando ass net fakultativ wann Dir wg set amplaz wg-quick benotzt hutt. De Kernel akzeptéiert déi nei Lëscht direkt, awer näischt setzt eng Route derbäi, also geet lokal erstallten Traffic nach ëmmer iwwer de Standardgateway eraus. Dat ass de heefegste Grond firwat en neit WireGuard-Subnetz vum Tunnelhost aus funktionéiert an net vum Laptop.
D’Réckroute scheitert méi dacks wéi den Tunnel
D’Gäscht um neie wäite Subnetz mussen d’Äntwerten iwwer de VPN-Gateway zréckschécken. Wann dee Gateway net hire Standardrouter ass, geet d’Äntwert op den LAN-Router, deen se verwërft oder mat enger privater Quelladress an d’Internet weidergëtt. Test vun engem Host op der wäiter Säit, net vum Gateway: ip route get 10.30.20.15 ënner Linux oder Find-NetRoute -RemoteIPAddress 10.30.20.15 an PowerShell weist den nächsten Hop deen den Host wierklech benotzt. Wann d’Äntwert net den Endpunkt vum Tunnel ass, setzt do eng statesch Route fir den neie Prefix derbäi.
Quell-NAT op der Site dee keng Réckroute huet ass eng legitim Alternativ an de Wee wéi vill hub-and-spoke Opstellunge jidwere Server net beréieren. Setzt en och op den neie Prefix um Gateway op der Zilsäit an:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEDe Präis ass real. Wäit Logbicher weisen keng eenzel Quelladressen méi, an d’Firewallregelen déi op dat ursprénglech Subnetz baséieren falen an eng eenzeg Regel fir de Gateway zesummen. Wielt dat bewosst, net well eng Route gefehlt huet.
Firewalle sinn déi aner Halschent vun der Réckroute. Zonenbaséiert Apparater verlängeren d’Zon vun enger existéierender Tunnelschnittstell net automatesch op en neit Subnetz, an eng Regel déi fir den ale Prefix geschriwwe gouf passt net. Setzt dat neit Subnetz an d’Zon oder an d’Regelpaar a béid Richtungen, ier Dir IPsec beschëllegt.
Entscheet mat dräi Froen, da verifizéiert mat Traffic
Déi kuerz Versioun: nennt d’Konfiguratioun vun der Säit Prefixen (politikbaséiert), oder gëtt den Traffic an eng Schnittstell geroutet (routbaséiert)? Lëschten béid Enner den neie Prefix op? Gëtt et e Wee zréck vum neie Subnetz op de urspréngleche Quellberäich?
| 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 |
D’Verifikatioun ass de Punkt wou déi meescht Ännerungen ze fréi zougemaach ginn. E Ping vum Gateway beweist wéineg, well de Gateway vun sech selwer schéckt an dacks mat enger anerer Politik iwwerenee kënnt wéi en Host. Ping vun engem Host um neie Subnetz, fuert duerno d’Applikatioun déi d’Ännerung motivéiert huet, a kuckt op Zähler an net op e Statusikon.
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showOp engem politikbaséierten Tunnel sollten d’Zähler vun ip xfrm state a béid Richtungen klammen; flaach Zähler heeschen datt de Paket geroutet awer net ausgewielt gëtt. Op WireGuard mellt wg show den Transfer pro Säit, an en Handschlag mat null empfangene Byte weist op d’Lëscht vun der wäiter Säit oder hir Réckroute.
Schlussendlech notéiert den Prefix, de Selektor oder d’Route vun der Säit, d’Entscheedung iwwer d’Réckroute an den Firewall-Andrag zesumme mam Rescht vum Tunnelinventar. Start duerno ee Gateway nei a test nach eng Kéier: eng Route déi vun Hand derbäigesat gouf verschwënnt, an déi nächst Persoun sollt dat net nach eng Kéier entdecke mussen.