Remote-Benotzer erreechen den zweeten Site net duerch den VPN-Hub

E Remote-Benotzer verbënnt sech mam Hub, erreecht den Dateiserver am eegenen LAN vum Hub, an alles gesond aus. Dunn mécht hien eng Fräigab op 10.20.0.50 an der Haaptdirektioun op, déi den Hub iwwer en separate Site-zu-Site-Tunnel erreecht, an et leeft an en Timeout. Béid Tunnelë sinn uewen a béid Ziele klammen, also ass keen Tunnel futti. Duerch den Hub ze goen sinn dräi Routing-Entscheedungen op dräi Geräter, an en Tunnel dréit just d’Präfixer, fir déi en gebaut gouf. Hei ass d’Uerdnung, déi ech préiwen, an de Kommando, deen weist, ob all Schrëtt stëmmt.

Den Transit brauch dräi Nokucken, net een Tunnel

All Gerät mécht seng eege längst-Prefix-Iwwereestëmmung a vergësst se. De Laptop muss 10.20.0.50 an den Tunnel schécken an net säi lokale Router. Den Hub muss e Paket, dat op der Remote-Access-Interface ukomm ass, un d’Site-zu-Site-Interface weiderginn. D’Haaptdirektioun muss eng Äntwert fir d’Adress vum Benotzer duerch den Tunnel zréck schécken. Wa just ee vun den dräi feelt, gesäit dat am Browser d’selwecht aus: Stëllt.

Dofir beweist et sou wéineg, all Tunnel eleng ze testen. De Ping op d’LAN-Adress vum Hub üübt déi éischt Entscheedung, an de Ping op den Hub aus der Haaptdirektioun déi drëtt. De Paket, dee feelt, huet de Benotzer-Pool als Quell an den zweeten Site als Zil, also schreift déi Präfixer als éischt op. Hei ass de Pool 10.80.0.0/24, den Hub-LAN 10.10.0.0/24 an d’Haaptdirektioun 10.20.0.0/24.

Schéckt de wäite Präfix un de wäite Client

Op engem OpenVPN Remote-Access-Server léiert de Client d’Routen beim Verbannen. Ouni Push schéckt e Client mat Splitt-Tunnel 10.20.0.50 un säin eegene Gateway an de Paket kënnt ni an den Tunnel.

push "route 10.20.0.0 255.255.255.0"

Eng geschéckte Route gëllt beim Verbannen vum Client, also gesäit e Benotzer, deen online bleift, näischt bis hie sech erëm verbënnt. Préift um Client: ip route get 10.20.0.50 op Linux, route print op Windows. D’Ausgab soll d’Tunnel-Interface nennen.

De Push hëlleft dem Hub net. Et ass eng Noriicht un de Client, keng Route um Server an och keng Erlaabnes fir weiderzeleeën, also verléiert en Hub mat der perfekter Push-Linn de Floss trotzdem een Hop méi spéit. Dat ass de gewéinleche Grond, firwat Leit schléissen, de Push wier feelgeschloen.

Gitt dem Hub eng richteg Egress-Route

Den Hub brauch säin eegene nächsten Hop fir de Präfix vun der Haaptdirektioun. Op engem gerouteten Tunnel ass dat eng gewéinlech Route duerch d’Site-zu-Site-Interface, an een eenzege Kommando weist souwuel déi gewielte Route wéi och déi gewielte Quell:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Wann de Site-zu-Site-Deel selwer OpenVPN ass, kann d’Route an där Konfiguratioun liewen, mam Tunneladress vum Peer als Gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. De Gateway ass net fakultativ. Loosst en ewech an de nächsten Hop fält op en Implementatiouns-Default, deen tëscht engem Single-Peer-Client an engem Hub mat multiple Peers ënnerscheet.

Policy-baséierten IPsec ass anescht: de Kernel vum Hub schéckt de Paket un säi normalen LAN-Gateway an d’Policy fänkt en um Ausgang, also mécht eng Tunnel-Route entweder näischt oder leet den Traffic laanscht d’Policy. Kuckt op d’Quell an der Kommando uewendriwwer, well 10.10.0.1 amplaz vun der Pool-Adress heescht, de Kernel huet eng Adress gewielt, déi déi wäit Säit verwäert. iroute ass och net d’Äntwert; et seet dem Server, wéi en Client en Subnet hannert sengem eegenen Tunnel besitzt, net wou den Traffic fir en drëtten Site soll hin.

Extendéiert déi wäit Säit op de Benotzer-Pool

D’Haaptdirektioun deckt schonn den Hub-LAN, 10.10.0.0/24. De Benotzer-Pool ass en zweeten Präfix an muss och an de Selektoren sinn, soss deckt keng Policy eng Äntwert déi un 10.80.0.25 adresséiert ass. All Peer nennt déiselwecht Pair vu Präfix-Sets vu senger Säit:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

D’local_ts vun engem Gerät ass d’remote_ts vum aneren. Kopéiert den Hub-Block an d’Haaptdirektioun an d’Pair ass emgedréit, also kënnt d’child SA ni erop.

Déi méi al ipsec.conf Syntax benotzt eng kommagetrennt leftsubnet. D’laafend Sécherheetsassociatioun behält d’Selektoren, déi se verhandelt huet, also baut den Tunnel nom Änneren erëm op. E Selekter, deen um 10:00 geännert gouf an deen géint eng SA getest gëtt, déi um 09:40 eropkomm ass, feelt nach ëmmer, wärend d’Konfiguratiounsdatei déi ganz Zäit richteg ausgesäit.

Dann préift den leschten Hop. ip route get 10.80.0.25 um wäiten Endpunkt sollt an den Tunnel weisen. Wann de Service e LAN-Router als Standard-Gateway benotzt, brauch deen Router och de Retour, soss stierft d’Äntwert do. tcpdump -ni eth1 host 10.80.0.25 op deem Segment auszeféieren weist, ob d’Äntwert den Endpunkt iwwerhaapt verlooss huet.

Erlaabt de Floss um Hub

Weiderleeung muss aktivéiert sinn an de Wee erlaabt. Begrenzt d’Reegele op déi zwee Präfixer amplaz alles tëscht den Interface ze akzeptéieren.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

D’Filtere vum Retourwee ass de stille Feeler dernieft: wa béid Been op verschiddenen Interface sinn, kann rp_filter=1 d’Äntwert verwerfen, wärend de Compteur vun der Akzeptanz-Reegel ni beweegt. Vergläicht iptables -vnL FORWARD virun an nom Versuch. Eng Reegel, déi ni klëmmt, gëtt net erreecht, also kuckt eng Schicht méi déif amplaz se ëmzeschreiwen.

Wann just eng Grupp den Transit brauch, setzt d’Route an eng Datei pro Client ënner client-config-dir amplaz de globale Push ze verbreeden. Source-NAT um Hub eweegt och d’Noutwendegkeet vun engem wäite Retour, awer et verstoppt d’Adress vum Benotzer, also halen d’Loge vum wäite Site an adressbaséiert Reegele op, Benotzer z’ënnerscheeden.

Préift vum Client aus a récksetzt dann an ëmgekéierter Uerdnung

Test en TCP-Port, net just ICMP, well e Ping duerchgoe kann, wärend de Service blockéiert bleift. nc -vz 10.20.0.50 445 an traceroute -n 10.20.0.50 vum Client weisen, ob den zweeten Hop d’Tunneladress vum Hub ass. Um Hub tcpdump -ni tun0 host 10.20.0.50 an deeselwechte Filter op der Site-zu-Site-Interface: eng Ufro op béide mat kenger Äntwert op engem vun deenen zwee verréckelt de Problem op déi wäit Säit.

Test dann eppes, dat blockéiert musst bleiwen. Wann och en Host äntwert, deen de Pool ni däerft erreechen, hutt Dir méi wéi den Transit opgemaach a sollt d’Reegele méi enk faassen. En Hub, deen alles un all Spoke weidergëtt, besteet den éischten Test a feelt am zweeten.

Féiert eng Récksetzlëscht, well véier Objete geännert goufen an dräi einfach ze vergiessen sinn: déi geschéckt Route, d’Route vum Hub, d’Selektoren an d’Firewall-Reegele. Récksetzt se an ëmgekéierter Uerdnung, baut d’SA erëm op a loosst ee Benotzer sech erëm verbannen. En deelweisen Réckset léisst eng Route, déi op en Tunnel weist, deen net méi passt, wat schwéier ze liesen ass wéi d’Originalstëllt. D’ OpenVPN-2.6-Handbuch dokumentéiert push, route an iroute fir Är Versioun.