Reverse-VPN für entferntes Netzwerk

Moin.

Ich möchte in der Lage sein von meinem Heimnetz (1) (bzw. erst einmal von meinem Server selbst) auf ein entferntes Heimnetz (2) zu kommen.
Allerdings hat dieses Netzwerk DS-Lite, auch würde ich dort eine Portfreigabe gerne vermeiden.

Daher war der Plan auf meinem Server einen OpenVPN-Server aufzusetzen, auf den der Router aus Heimnetz (2) dann connected.
Soweit so gut, also tun/routed-VPN aufgesetzt, sieht dann entsprechend aus:

               ------------------                                    ------------------
10.234.1.2/26 -| OpenVPN-Server |- 10.234.12.1    <-    10.234.12.2 -| OpenVPN-Client |- 192.168.2.1/24
Heimnetz (1)   |   Debian 9.5   |                                    | OpenWrt-Router |    Heimnetz (2)
               ------------------             VPN-Tunnel             ------------------  

Auf die 10.234.12.2, sprich die VPN-IP-Adresse des Routers komme ich drauf und kann diesen auch Fernwarten.
Also habe ich auf dem Debian-Server folgende Route angelegt:

ip route add 192.168.2.0/24 via 10.234.12.2

Die hat er laut Routing-Tabelle auch geschluckt.
Allerdings kommt da nichts zurück. Mein erster Gedanke an eine Firewall auf dem OpenWrt habe ich schon überprüft.

Interessant ist, dass die LAN-LED am OpenWrt-Router beim ping auf 10.234.12.2 blinkt, beim ping auf irgendwas anderes aber nicht, sprich offensichtlich geht die Verbindung gar nicht den weg über die VPN-Verbindung...

Habe ich wieder einen Quer im Hirn?
Die Pings habe ich auf dem Server selbst gemacht, sprich an den Routing-Regeln aus dem Heimnetz (1) hängt es nicht...
Bitte helft mir -_-

OpenVPN-Server-Config:

port ...
proto udp
dev tun-mgmt
route 192.168.0.0 255.255.0.0 10.234.12.2
ca ...
cert ...
key ...
dh ...
server 10.234.12.0 255.255.255.248
ifconfig-pool-persist /tmp/openvpn-mgmt-ipp.txt
topology subnet
keepalive 10 120
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
#compress lz4-v2
;push "compress lz4-v2"  
comp-lzo
max-clients 5
user nobody
#group nobody
persist-key
persist-tun
#status openvpn-status.log
log /var/log/openvpn-mgmt.log
verb 3
mute 20
explicit-exit-notify 1

OpenVPN-Client Config:

client
remote ...
proto udp
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
auth SHA512
comp-lzo
mute 20
cipher AES-256-CBC
tls-version-min 1.2
remote-cert-tls server
remote-cert-eku "TLS Web Server Authentication"  
verify-x509-name ...
cert ...
key ...
<ca>...

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 386053

Url: https://administrator.de/contentid/386053

Ausgedruckt am: 21.11.2024 um 13:11 Uhr

10 Kommentare

Neuester Kommentar

Grias di

Also mir fällt auf.......

- du hast sehr ungewöhnliche netmask. ich hoffe auf allen nodes sind die gleich.
- der vpn Client aus netzwerk 2 hat den tunnel aufgemacht ? Sonst scheitert es an der portfreigabe.

kannst du infos über den zustand des tunnels liefern?
der müsste ja vorher schon stehen.

Servus

Das tut er auch. Ja, die /26er-Maske vom Heimnetz und die /28er vom VPN ist mit Absicht so gewählt, daran liegt es nicht, denn ich habe neben der OpenVPN-Server-Instanz auch noch eine Private, welche dann 10.234.11.0/28 fährt. Die verwende ich aber halt für mobile Endgeräte um den Internetzugriff & Netzzugang zu tunneln - das funktioniert auch.

Die Netmasks habe ich damals mal gewählt, leider komme ich auch noch aus der Zeit IPv4, wo man spart wo es geht... xD

Der Tunnel steht sicherlich, denn wie oben erwähnt komme ich ja auch über die direkte VPN-IP drauf, somit ist der Tunnel aktiv.

kannst vom heimnetz 2 die routingtable posten.
ich würde jetzt tippen, das der wrt den default-weg nimmt und der zeigt irgendwohin.
quasi noch außerhalb des tunnel es schief läuft.

schon mal ein traceroute bzw tracert probiert?

Lösung gefunden: https://openvpn.net/index.php/open-source/documentation/howto.html#scope

An meinen Routen lag es soweit nicht, allerdings scheint dem Server die IP-Route selbst nicht zu reichen, siehe Zeile "iroute" und darunter.
Tracert hatte ich vorher gemacht, hatte nicht funktioniert, jetzt alles kein Problem.

Grundsätzlich bucht sich der OpenWrt-Router dann von fern bei mir Zuhause ein, ich komme auf das Netzwerk.
Da ich nicht möchte, dass aus dem entfernten Heimnetz (2) auf meins zugegriffen werden kann noch ein NAT drauf, so spare ich mir auf dem OpenWrt-Router die Rückroute, zusätzlich ist das Routing auf dem Server aus dem VPN-Tunnel nur bereits bestehenden/aufgebauten Verbindungen erlaubt.

Perfektes Setup um Remote-Standorte Fernzuverwalten / für diese zentral Monitoring zu implementierten.
Natürlich wäre ein verteiltes Monitoring cooler, da es hier aber um ein Heimnetz und keine Firma geht sollte diese Bastellösung ausreichen..

Wie muss ich die routen konfigurieren, wenn ich den gesamten Traffic von Heimnetz 1 zu Heimnetz 2 geroutet haben möchte und der router an Heimnetz 2 dann als Internet Gateway gelten soll?

Sollte auch gehen - dann muss am Standort 1 aber der VPN-Router auch Gateway sein. Am Standort 2 wo es dann ins Internet geht nicht zwingend, dann muss es aber mindestens eine Rückroute auf dem Gateway für das Netz geben bzw. ein NAT auf dem Ausgang vom VPN ins dortige LAN.
Dann einfach wie bei einem Roadwarrior-VPN dort ein "redirect-gateway def1" eingetragen und schon sollte alles durch den VPN-Tunnel gehen.

Bei mir mache ich das z.B. für das Gast-Netz - hier geht der Traffic über mein VPS ins Internet.
Sollte klar sein, dass das die Performance ein wenig senkt - gerade bei Downloads. Sollte dein Standort 2 dann auch nur eine kleine Leitung haben wohl noch mehr.

So einfach scheint es wohl nicht zu sein, ich habe folgendes als Grundlage:
https://serverfault.com/questions/978081/openvpn-how-to-route-internet-t ...

Wenn ich nun mit 'dev tun' konfiguriere, bekomme ich den gesamten Traffic auf den gewünschten Client. Aber von da nicht weiter ins Internet. (Einen 'dev tap' geht es nicht.)

Meine Config ist:
Client Heimnetz (192.168.255.1), ccd config:
#tun
ifconfig-push 192.168.255.1 192.168.255.2
iroute 192.168.255.1 255.255.255.255

Auf dem Server (192.168.255.2),
route 192.168.255.1 255.255.255.255
route 192.168.255.3 255.255.255.255
push "route 192.168.255.2 255.255.255.255"
push "route 192.168.255.1 255.255.255.255"
push "route 192.168.255.3 255.255.255.255"
route 1.0.0.0 255.0.0.0
...(wie im Artikel beschrieben)

FernClient, (192.168.255.3) - von da soll es ins Internet, ccd config,
ifconfig-push 192.168.255.3 192.168.255.2
iroute 192.168.255.3 255.255.255.255
push "route 192.168.255.0 255.255.255.0 192.168.255.2"
iroute 1.0.0.0 255.0.0.0
...(wie im Artikel)

Im Artikel steht zwar, "..packets cannot be sent through another client as the gateway using the TUN interface", aber it dev TAP funktioniert die Config nicht (wenn ich TAP am FernClient einstelle, dann muss ich es auch am Server und beim lokalen Client).

tracert 8.8.8.8 zeigt bis 192.168.255.3 - route is soweit richtig, aber von da geht nicht weiter ins Internet.

Es gibt 2 Möglichkeiten,
- wie bekomme ich den Traffic auf dem FernClient ins Internet?
oder
- wie bekomme ich die gleiche route mit dev tap hin?

Ich habe deinen Aufbau noch nicht verstanden - gerade der Servervault-Artikel. Ist der auch von dir oder nur ein ähnliches Szenario?

Mach bitte mal eine grobe Skizze von den beiden Standorten mit den jeweiligen LAN-IP-Bereichen. Mir scheint das 192.168.255.0/24er das Transfernetz zwischen deinen Servern zu sein...

Die Routen die du gepostet hast machen für mich gerade noch keinen Sinn, da diese im Transfernetz nicht notwendig sind / von OpenVPN selbst verwaltet werden.

Grundsätzlich kann ich dir aber sagen, dass ich mittlerweile auch einen VPS habe (wie beim ServerVault-Artikel), wo mehrere VPN-Clients dranhängen, siehe Grafik. Ich bin am Standort mit Client1 und route meinen Internetzugang wahlweise über den Server oder über Client2. Das funktioniert, setzt aber voraus dass bei diesem entsprechend in seiner ccd-Konfiguration ein

iroute 0.0.0.0 0.0.0.0

gesetzt ist und auf Client1 und Server jeweils auch. Wie schon gesagt, neben einer Route braucht OpenVPN diese auch noch einmal zusätzlich, damit es den Traffic wirklich weitergibt!
Auch muss der VPN-Client am anderen Ende NAT verwenden, wenn er nicht Default-Gateway ist.

Der Servervault Artikel beschreibt ein ähnliches Scenario, ist aber nicht von mir. Deine Graphik scheint auch in diese Richtung zu gehen. Aber nun eine Graphik von mir.

PC----------------------------Router 1--------------------------------------------------Router 2----------------------------linux device
192.168.67.10 ---- 192.168.67.1 |NAT| public IP ------------- public IP |NAT| 192.168.68.1 --- 192.168.68.10
VPN Client 1 --- VPN Server (port Forwarding on)-----------------------------------------------------------------VPN client 2

VPN IP:
192.168.255.1 --------- 192.168.255.2 ----------------------------------------------------------------------------------- 192.168.255.3

Der VPN Server befindet sich zwar im Heimnetz/ gleichen Netz wie Client 1, Client 1 könnte aber auch irgendwo ausserhalb sein.
Nun sollen sich der Client 1 und der Client 2 mit dem Server verbinden, was kein Problem ist. Der gesamte Traffik von client 1 soll über den Server zu Client 2 geroutet werden und dann über Client 2 ins Internet.

Wie müssen die ccd Configs für den Client 1/ 2 sein und wie die Server Config? Geht das mit TAP Interface? wie wird verhindert, dass der Traffik zu Client 2 geht und nicht über den Server ins Internet?
Muss evt noch zusätzlich zu OpenVPN etwas am Client2 konfiguriert werden?

Ich habs nicht ausprobiert, im Artikel https://serverfault.com/questions/875586/openvpn-client-as-a-gateway-for ... steht, dass iroute 0.0.0.0... nicht funktioniert, deswegen diese route/ iroute Liste.

Mein nächster Versuch wäre, mit 'dev tap0' bei client 1/2 und server
ccd/client01:
ifconfig-push 192.168.255.1 255.255.255.0
push "route 192.168.255.1 255.255.255.0 192.168.255.2" # muss das sein ??? redirect-gateway müsste reichen
iroute 192.168.255.1 255.255.255.0
route 192.168.255.1 255.255.255.0 192.168.255.2 # muss das sein ???
push "redirect-gateway def1"

ccd/client02:
ifconfig-push 192.168.255.3 255.255.255.0
push "route 192.168.255.0 255.255.255.0 192.168.255.2"
iroute 0.0.0.0 0.0.0.0