14.03.2022

5004

Netzwerk hinter OPENVPN-Client erreichen

Hallo zusammen,

ich versuche schon seit ein paar Tagen ein Netzwerk hinter einem OVPN-Client zu erreichen bzw. zu routen.
Nach vielem Lesen diverser Anleitungen weiß ich nun nicht mehr was nun am besten auf meine Anforderung zutrifft.

Die Verbindung vom Client (192.168.57.X) zum OVPN Server (10.0.0.100) und dem Netzwerk hinter dem Server erreiche ich ganz normal.
Nun wollte ich vom 10.0.0.0 Netzwerk auf die Geräte/Server hinter dem Client zugreifen.
Nun Frage ich mich wo die Route bzw. das "push", "route" und/oder das "iroute" schreibe.
Und ist zwingend eine statische Route in den jeweiligen Routern notwendig?

Meine Konstellation:

OVPN-Server auf einer Synology mit der IP 10.0.0.100/8
Transfernetz :172.16.8.0

server.conf:

push "route 10.0.0.0 255.0.0.0"  
push "route 172.16.8.0 255.255.255.0"  
route 10.0.0.0 255.0.0.0
dev tun

management /var/run/openvpn.sock unix

server 172.16.8.0 255.255.255.0

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 5

comp-lzo

persist-tun
persist-key

verb 3

#log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCent>
client-cert-not-required
username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
cipher AES-256-CBC
auth SHA512

die config des Clients (lokales Netzwerk: 192.168.56.0/21):

dev tun
tls-client

remote mein.dyndns 1194
pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass login.conf

Entschuldigt meine vielleicht etwas verwirrte Erklärung. Sollte ich etwas vergessen haben, einfach Fragen

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

Content-ID: 2159764577

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

Ausgedruckt am: 04.11.2024 um 18:11 Uhr

26 Kommentare

Neuester Kommentar

Moin,

Hierzu solltest Du ein Site-to-Site VPN nutzen und kein Client-to-Site.

Gruß Looser

ein Netzwerk hinter einem OVPN-Client zu erreichen bzw. zu routen.

Einfach mal die Suchfunktiuon benutzen !

Hier steht wie es geht:
OpenVPN - Erreiche Netzwerk hinter Client nicht

Das grundlegende Rüstzeug dafür:
Merkzettel: VPN Installation mit OpenVPN

Zitat von @Looser27:

Moin,

Hierzu solltest Du ein Site-to-Site VPN nutzen und kein Client-to-Site.

Gruß Looser

Stimmt, entschuldigung, ich habe vergessen dazuzuschreiben, dass es eben ohne Zugriff auf dem Router auf der Client Seite funktionieren soll.

Zitat von @148523:

ein Netzwerk hinter einem OVPN-Client zu erreichen bzw. zu routen.

Einfach mal die Suchfunktiuon benutzen !

Hier steht wie es geht:
OpenVPN - Erreiche Netzwerk hinter Client nicht

Das grundlegende Rüstzeug dafür:
Merkzettel: VPN Installation mit OpenVPN

Wie konnte ich das bei meiner Suche übersehen?!
Vielen Dank! Werde ich morgen gleich testen.

Hi,
in der "server.conf" sollte das Remote-Netz eingetragen sein.
Hier...

route 192.168.57.0 255.255.255.0

Desweiteren bedarf es einer CCD (ClientConfigDirectory), deren Pfad in der "server.conf" eingetragen ist....
Bsp.:

client-config-dir /var/etc/openvpn/server6/csc

...deren Eintrag nur den iroute-Verweis auf das Clientnetz beinhaltet.

iroute 192.168.57.0 255.255.255.0

Das sollte dann funktionieren.
Gruß orcape

Zitat von @orcape:

Hi,
in der "server.conf" sollte das Remote-Netz eingetragen sein.
Hier...

route 192.168.57.0 255.255.255.0

Desweiteren bedarf es einer CCD (ClientConfigDirectory), deren Pfad in der "server.conf" eingetragen ist....
Bsp.:

client-config-dir /var/etc/openvpn/server6/csc

...deren Eintrag nur den iroute-Verweis auf das Clientnetz beinhaltet.

iroute 192.168.57.0 255.255.255.0

Das sollte dann funktionieren.
Gruß orcape

Das habe ich jetzt versucht (jedoch mit der 192.168.56.0 255.255.248.0)

Nun bringt die Syno die routen etwas durcheinander:

root@user:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default           10.0.0.1          0.0.0.0               UG    0      0        0 eth0
10.0.0.0          172.16.8.2      255.0.0.0           UG    0      0        0 tun0
10.0.0.0          0.0.0.0            255.0.0.0           U     0      0        0 eth0
172.16.8.0      172.16.8.2      255.255.255.0   UG    0      0        0 tun0
172.16.8.2      0.0.0.0            255.255.255.255 UH    0      0        0 tun0

Nun bringt die Syno die routen etwas durcheinander:

Warum ? Was ist denn da durcheinander ?
Wichtig ist nur das die Syno auch überhaupt IP Forwarding (Routing) im System aktiviert hat !! Ansonsten ist das generell zum Scheitern verurteilt.
Merkzettel: VPN Installation mit OpenVPN

Du musst die Tunnelendpunkte pingen können.
Also 172.16.8.2 vom Netz 10.0.0.0/ aus. Genauso IP's im remoten Netz 192.168.56.0/29 .
Was bei Deiner Routing Tabelle gänzlich fehlt, ist der Verweis auf das Remote Netz über die OpenVPN-Client-IP.
Bsp.: In Deinem Fall müsste das ungefähr so aussehen....

192.168.56.0/29    172.16.8.2          UG      tun0

Leider habe ich nur ein FreeBSD-System, so das die Routing-Tabelle ein wenig anders ausschaut.
Ich schätze mal bei Dir fehlt in der Server-Config noch der...

route 192.168.56.0 255.255.248.0

...Eintrag.

Zitat von @cosmo87:

Stimmt, entschuldigung, ich habe vergessen dazuzuschreiben, dass es eben ohne Zugriff auf dem Router auf der Client Seite funktionieren soll.

wenn das so wirklich ist... wirst du wohl aug allen Endgeräten eine zusätzliche Route eintragen müssen (dein VPN-Endpunkt liegt ja nicht im Standardgateway). Das wird schwierig bei dynamischer IP-Vergabe für die Clients , wenn der Verwalter des (Haupt)Routers nichts merken soll

??!!

Oder hab ich den Satz nur falsch verstanden ? Dann setze per DHCP einfach die notwendigen Routen mit...
fred

Zitat von @fredmy:

Das wird schwierig bei dynamischer IP-Vergabe für die Clients , wenn der Verwalter des (Haupt)Routers nichts merken soll

??!!

Oder hab ich den Satz nur falsch verstanden ? Dann setze per DHCP einfach die notwendigen Routen mit...
fred

Ich glaube mal eher, der TE meint, nur ohne persönlich vor Ort zu müssen.
Bei solche "Operationen am Herzen" eines OpenVPN-Tunnels, ist es manchmal nicht verkehrt, wenn man sich noch eine Hintertür offen lässt. Ich habe in solchen Anfangsphasen bei der Tunneleinrichtungen meist den Webzugriff per ssh oder telnet, auf das Interface des Clientrouters zugelassen und diesem eine DynDNS-Adresse verpasst.

Gruß orcape

Hallo,
kann ja sein,
dann wird aber jeder Zielrechner eine extra Route zum VPN-Server brauchen (ggfs. hilft evtl. Source-NAT)

Fred

wirst du wohl aug allen Endgeräten eine zusätzliche Route eintragen müssen

Das ist dann zwangsläufig ein MUSS wenn man den Router im Netz (der ja wie der Name schon sagt routen soll !) nicht anfassen will oder darf.
Bedeutet dann zwingend immer eine statische Route auf jedem Client Rechner ala route add xyz...
Und am Ende dann das "-p" nicht vergessen sonst ist die nach jedem Reboot wie der wech !

Ihr seid einfach Super!

Hintergrund des ganzen ist eigentlich eher ein Versuch, fast schon eine Wette mit meinem vorgesetzten.
Dieser meinte dass es UNMÖGLICH sei, das ganze komplett ohne Port Freigabe bzw bei DSL-Lite um zu setzen.

Zitat von @fredmy:
wenn das so wirklich ist... wirst du wohl aug allen Endgeräten eine zusätzliche Route eintragen müssen (dein VPN-Endpunkt liegt ja nicht im Standardgateway). Das wird schwierig bei dynamischer IP-Vergabe für die Clients , wenn der Verwalter des (Haupt)Routers nichts merken soll

??!!

Oder hab ich den Satz nur falsch verstanden ? Dann setze per DHCP einfach die notwendigen Routen mit...
fred

Das habe ich ja komplett übersehen, stimmt *facepalm*.
Könnte man dann nicht mit der IP des Client im Netzwerk agieren? Wäre das nicht ein klassisches NAT?

Gruß

Ich kann nicht nachvollziehen, wo das Problem liegen soll.
Du hast einen Router, auf dem der OpenVPN-Client läuft und der eine Verbindung zum OpenVPN-Server initiiert.
Wobei es beim OpenVPN-Client egal ist, ob das ein LTE-Netz oder ein DSL-Lite Anschluß ist. Hat der Client die entsprechende Adresse im WWW in seiner Config, wird er auch eine Verbindung aufbauen.
Da auf dem Client-Router, vorausgesetzt das es ein TUN-Tunnel ist, sowieso ein anderes Netzwerk erforderlich ist, wie auf dem Hauptrouter oder wie beim TE das Synologie, ist es doch egal ob ich da DHCP fahre oder nicht.
Will ich einen bestimmten PC im Clientnetz, vom Synologie aus oder von einem Admin-PC aus dem Servernetz erreichen, sollte dieser PC im Clientnetz logischerweise eine feste IP ausserhalb des DHCP-Range haben.
Das Gateway im Client-Netz, ist in dem Fall die IP des OpenVPN-Client-Routers und die sollte selbstverständlich dort bei jedem PC oder Gerät eingetragen sein.
Alles andere betreffs Routen, ist in den OpenVPN-Servereinstellungen zu hinterlegen. Firewall des Client Routers nicht vergessen.
Gruß orcape

Nicht vergessen deinen Thread hier dann auch zu schliessen wenn keine Fragen mehr sind!!
Wie kann ich einen Beitrag als gelöst markieren?

Hallo zusammen,

nachdem ich mich wochenlang das Internet durchsucht habe, bin ich durch Zufall über die Lösung gestolpert:

"echo 1 > /proc/sys/net/ipv4/ip_forward"

Quelle: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ...

Zitat von @148523:
Bei Linux basierten Plattformen wie deinem Synology NAS und den RasPi's hier, ist das die Zeile
net.ipv4.ip_forward=1 die in der Datei /etc/sysctl.conf entkommentiert ( "#" entfernen) werden muss.

Das alleine reichte leider nicht aus.

Nun funktionieren auch eure Vorschläge endlich.
Vielen Dank nochmal dafür!

Ein Frage habe ich hierzu noch: das "push route..." kann man auch in die ccd Datei schreiben, oder?

kann man auch in die ccd Datei schreiben, oder?

Nein! Denn das ist ein globales Server Kommando und gehört normalerweise nie in die Client spezifische Konfig Datei des Servers. (Siehe Tutorial oben)
Du hast das sicher mit dem "iroute" Kommando verwechselt, kann das sein?!

Du hast das sicher mit dem "iroute" Kommando verwechselt, kann das sein?!

Oder mit "ifconfig-push" und das gehört in die CCD.

ok, danke @148523, dann habe ich das doch richtig verstanden.

Also kommt fogendes in die server.conf:
route 192.168.56.0 255.255.248.0
push "route 192.168.56.0 255.255.248.0"

und in die CCD:
iroute 192.168.56.0 255.255.248.0
ifconfig-push 172.16.8.5 255.255.255.0

braucht es dann noch die "route" in der server.conf?

was mir noch aufgefallen ist, dass in der CCD das "iroute" nach einer gewissen zeit rausgelöscht wird und
in der Routing-Tabelle taucht auch noch eine 169.254.176.1 ip auf "tun1000" auf (so weit ich mal gelernt habe
ist eine 169.254. die ip, die vergeben wird, wenn die Netzwerkkarte keine IP konfiguriert hat). Diese ist nur innerhalb des VPN Netzwerks pingbar.

braucht es dann noch die "route" in der server.conf?

Ja. Das bedient die Kernelroutetabelle des Servers. Wenn du einmal einen bescheidenen Blick in die OpenVPN Dokumentation geworfen hättest wäre diese Frage überflüssig gewesen.

dass in der CCD das "iroute" nach einer gewissen zeit rausgelöscht wird

Das dürfte niemals passieren. Ist bei dir irgendein Cronjob oder sowas aktiv der das macht oder diese Datei zyklich überschreibt?
Bei einer normalen OpenVPN Installation verschwinden diese Einträge natürlich niemals. Wie denn auch bei einer statischen Textdatei, denn OpenVPN selber fasst sie nicht an.
Die 169.254 ist eine typische APIPA bzw. ZeroConf IP. Da hast du also Recht mit deiner Vermutung. Bekommt ein Interface aber auch ausschliesslich nur bei dynamischer Adressierung die es bei OpenVPN nur in Ausnahmefällen gibt.

Ich habe die Dokumentation gelesen, aber scheinbar habe ich die falschen zusammenhänge verstanden. Entschuldigung dafür

Ein Cronjob läuft da nicht. Seltsam ist auch dass es nur bei 1 von 3 Clients ist.
Ich hätte auch schon versucht die Datei mit "chmod" auf 444 zu setzen. Trotzdem wird der Eintrag gelöscht.
der "ifconfig-push" Eintrag bleibt jedoch erhalten.

Ohne dann deine Server Konfig und auch die des betroffenen Clients zu kennen ist eine Hilfe schwer möglich...

Oh ja, natürlich. Hat sich ja mittlerweile etwas geändert.

Server.conf

push "route 10.0.0.0 255.255.0.0"  

route 192.168.18.0 255.255.255.0
push "route 192.168.18.0 255.255.255.0"  

dev tun

client-to-client
client-config-dir /var/packages/VPNCenter/etc/openvpn/ccd
topology subnet
push "topology subnet"  

management /var/run/openvpn.sock unix

server 172.16.8.0 255.255.255.0

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 10

comp-lzo

persist-tun
persist-key

verb 3

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
mssfix 1450
port 1194
cipher AES-256-CBC
auth SHA512

Client.conf

dev tun
tls-client

remote XYDomain.de 1194

pull
proto udp
script-security 2
comp-lzo
reneg-sec 0
cipher AES-256-CBC
auth SHA512
auth-user-pass

CCD File:

iroute 192.168.18.0 255.255.255.0
ifconfig-push 172.16.8.5 255.255.255.0

2 Dinge:

Compression zu benutzen ist gefährlich wegen der Voracle Attacke: https://openvpn.net/security-advisory/the-voracle-attack-vulnerability/ Es bringt heutzutage gar nichts den Tunnel Traffic zu komprimieren weil 90% aller Daten bereits vorkomprimiert sind. Solltest du gem. der OpenVPN Empfehlung besser entfernen!
Du arbeitest beim Server Setup noch mit dem stark veralteten net30 Verfahren was /30er Masken nutzt. Deine Client ccd Konfig ist aber mit Masken die das moderne subnet Verfahren nutzen konfiguriert! Das ist also eine Fehlkonfig die die Abarbeitung der User spezifischen ccd Konfig dann scheitern lässt. Das musst du mit topology subnet und push "topology subnet" im Server anpassen oder die ccd Subnetzmasken entsprechend anpassen.

Der Rest ist soweit OK.
Hilfreich wären nochmal die Routing Tabellen von Server und Client bei aktivem Tunnel. route print oder netstat -r -n -A inet oder ip r je nachdem welches OS du bei Client und Server verwendest.

Zitat von @148523:

Compression zu benutzen ist gefährlich wegen ...

auf beiden Seiten den Eintrag "comp-lzo" entfernen oder?
Sobald ich das mache ist kein erneuter Verbindungsaufbau mehrmöglich. Das werde ich bei Zeiten nochmals genauer begutachten..

Zitat von @148523:

Du arbeitest beim Server Setup noch mit dem stark veralteten net30 Verfahren

Verstehe nicht ganz. Ich habe doch in
Zeile 10 -> topology subnet
und in
Zeile 11 -> push "topology subnet"

net30 hatte ich noch in meinem Eingangspost, was ich aber dank dem Merkzettel-Link geändert habe

Zitat von @148523:
Hilfreich wären nochmal die Routing Tabellen von Server und Client bei aktivem Tunnel. route print oder netstat -r -n -A inet oder ip r je nachdem welches OS du bei Client und Server verwendest.

Client (Windows):

route print
===========================================================================
Schnittstellenliste
 14...3c 18 a0 56 de b0 ......Lenovo USB Ethernet
 12...00 ff a1 94 6c fc ......TAP-Windows Adapter V9
 22...48 a4 72 c0 05 99 ......Intel(R) Dual Band Wireless-AC 3165
 18...48 a4 72 c0 05 9a ......Microsoft Wi-Fi Direct Virtual Adapter
 21...4a a4 72 c0 05 99 ......Microsoft Wi-Fi Direct Virtual Adapter #3
 13...48 a4 72 c0 05 9d ......Bluetooth Device (Personal Area Network)
  1...........................Software Loopback Interface 1
  4...00 00 00 00 00 00 00 e0 Microsoft IP-HTTPS Platform Adapter
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      10.101.32.1     10.101.33.53     25
         10.0.0.0        255.0.0.0       172.16.8.1        172.16.8.3    281
      10.101.32.0    255.255.254.0   Auf Verbindung      10.101.33.53    281
     10.101.33.53  255.255.255.255   Auf Verbindung      10.101.33.53    281
    10.101.33.255  255.255.255.255   Auf Verbindung      10.101.33.53    281
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
       172.16.8.0    255.255.255.0   Auf Verbindung        172.16.8.3    281
       172.16.8.0    255.255.255.0       172.16.8.1        172.16.8.3    281
       172.16.8.3  255.255.255.255   Auf Verbindung        172.16.8.3    281
     172.16.8.255  255.255.255.255   Auf Verbindung        172.16.8.3    281
     192.168.18.0    255.255.255.0       172.16.8.1        172.16.8.3    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung        172.16.8.3    281
        224.0.0.0        240.0.0.0   Auf Verbindung      10.101.33.53    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung        172.16.8.3    281
  255.255.255.255  255.255.255.255   Auf Verbindung      10.101.33.53    281
===========================================================================
St„ndige Routen:
  Keine

Server (Linux/Synology):

netstat -r -n -A inet
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 eth0
10.0.0.0        0.0.0.0         255.0.0.0       U         0 0          0 eth0
169.254.144.0   169.254.144.1   255.255.248.0   UG        0 0          0 tun1000
169.254.144.0   0.0.0.0         255.255.248.0   U         0 0          0 tun1000
172.16.8.0      0.0.0.0         255.255.255.0   U         0 0          0 tun0
192.168.18.0    172.16.8.2      255.255.255.0   UG        0 0          0 tun0

was ich noch gefunden habe ist in der server.conf den Eintrag "proto udp6" und in der client steht nur "proto udp".
Kann sich hier das IPv4 und das IPv6 gegenseitig stören? Eigentlich arbeite ich hier nur mit IPv4...

auf beiden Seiten den Eintrag "comp-lzo" entfernen oder?

Ja. Siehe: https://www.equinux.com/us/faq/1797/2/I-am-using-the-Option-comp-lzo-no- ...

net30 hatte ich noch in meinem Eingangspost

Sorry übersehen....

Irgendwas stimmt an der Routing Tabelle des Servers nicht. Das 10er Netz hast du doch wohl hoffentlich nicht mit einem 8er Prefix geroutet, oder ??

Kann sich hier das IPv4 und das IPv6 gegenseitig stören?

Ja, das kann passieren wenn das nicht bei Client und Server gleich ist!
Beim Server sollte stehen:
...
dev tun
proto udp4
port 1194
...
und dann analog beim Client:
dev tun
proto udp4
remote <server_ip> 1194
...
Wenn du nur mit IPv4 arbeiten willst ansonsten wird wie üblich IPv6 präferiert. Siehe OpenVPN Kommando Referenz!

Frage Netzwerke

Mehr von cosmo87

Client Zugriff über OVPN Cloudcosmo87 - 6 Kommentare

VPN Verbindung mit einem LTE TP-Link Routercosmo87 - 19 Kommentare

HTML Inhalt als Email versendencosmo87 - 2 Kommentare

SNMP Abfrage in Datei schreiben mit Powershellcosmo87 - 15 Kommentare

Heiß diskutiert