OpenVPN: Definierte Ports über das VPN Gateway routen

[Crash1601]

Guten Morgen zusammen,

ich nutze OpenVPN auf meiner DS412+ und möchte gerne bestimmte Ports auf meinem Notebook (Bsp.: Port 80) auf das VPN Gateway umleiten und nicht über das "normale" Gateway. Gibt es hierfür eine Möglichkeit das in die OpenVPN Configdatei einzubauen?

Ein redirect des Gateways möchte ich nicht.

Danke!

Gruß
Crash1601

 

[fpo4711]

Hallo,

so ganz verstehe ich dein Vorhaben nicht. Also wenn Du, was noch verständlich ist, ein Redirect des Gateway nicht willst dann setze das Doppelkreuz vor die Directive. Wenn Du dann den Webserver mit http://lokale_ip ansprichst wird nur der Traffic für dieses Gerät über das VPN geleitet. Sprichst Du eine andere IP/Namen an wie beispielsweise http://www.heise.de dann läuft es nicht über das VPN.

Gruß Frank

 

[jahlives]

Das geht nicht via VPN direkt. Das kann nur deine lokale Firewall mit einem Portforwarding

 

[Crash1601]

Hallo,

so ganz verstehe ich dein Vorhaben nicht. Also wenn Du, was noch verständlich ist, ein Redirect des Gateway nicht willst dann setze das Doppelkreuz vor die Directive. Wenn Du dann den Webserver mit http://lokale_ip ansprichst wird nur der Traffic für dieses Gerät über das VPN geleitet. Sprichst Du eine andere IP/Namen an wie beispielsweise http://www.heise.de dann läuft es nicht über das VPN.

Gruß Frank

Hallo,

ja das wäre ja soweit der "normale" Ablauf. Ich möchte lediglich definieren welche Protokolle über den VPN Tunnel laufen und welche nicht.

Das geht nicht via VPN direkt. Das kann nur deine lokale Firewall mit einem Portforwarding

Alles klar, damit wäre die Frage beantwortet. Ich hatte gedacht, dass das OpenVPN die Möglichkeit bietet.

Gruß
Crash1601

 

[jahlives]

Ich hatte gedacht, dass das OpenVPN die Möglichkeit bietet.

das kann OVPN (wahrscheinlich auch kein anderes VPN) vom Prinzip her nicht. VPNs können Traffic routen, aber das betrifft dann alle Pakete unabhängig vom Zielport. Routing interessiert sich nicht für Ports ;-)
Letztlich brauchst du eine NAT Regel welche diesen gewünschten Traffic an den entsprechenden GW schickt

iptables -t nat -I PREROUTING -p tcp --dport 80 -j DNAT --to 10.0.0.1

wobei 10.0.0.1 die VPN IP des gewünschten Gateways wäre. Das geht aber nur auf einer Kiste, die ebenfalls im VPN hängt.
Wenn du die Regel auf einem Gateway willst, der selber nicht im VPN ist, dann muss der eine Route haben, damit er 10.0.0.1 erreichen kann

 

[horstepipe]

ich koch das hier noch mal auf:
ist es generell möglich, einen Dienst (z.B. Video Station) über das eigene Gateway laufen zu lassen, und einen anderen (z.B. Cloud Station) über VPN (OpenVPN)?

lG

 

[fpo4711]

Na dann erzähl doch mal wie Du das über OpenVPN lösen würdest und nicht wie schon geschrieben über iptables.

Gruß Frank

 

[fpo4711]

@horstepipe

Uups, gerade noch einmal gelesen. War ja keine Feststellung von Dir sondern eine Frage.

Die Antwort ist also nach wie vor ein protokollabhängiges Routing ist nach meiner Meinung nur über spezielle Regeln per iptables möglich. Also pure Handarbeit auf der DS siehe als Beispiel #5 von jahlives.

Gruß Frank

 

[jahlives]

@Frank
theoretisch würde es auch mit reinem Routing gehen, setzt aber einige Dinge voraus Zum ersten muss der Dienst, der nicht das default Routing verwenden soll eine eigene IP Adresse haben. Zum zweiten muss iproute2 vorhanden sein. Sagen wir dann, dass der fragliche Dienst die IP 192.168.1.100 konfiguriert hat und sein Gateway soll 192.168.1.2 (im Gegensatz zu 192.168.1.1, welche der default GW ist für den Rest) sein. Dann erstellt man zuerst eine Routing Tabelle

#/etc/iproute2/rt_tables
...
200  meineTabelle

der erste Wert ist die Prio und der zweite der Name der Tabelle.

# erst die Regel welche alle Pakete von der SRC durch die entsprechende Tabelle jagt
ip rule add from 192.168.1.100 table meineTabelle priority 200

# die default Route der entsprechenden Tabelle
ip route add default table meineTabelle via 192.168.1.2 metric 100

# das Subnetz welches zum Interface gehört
# ohne diese Regel würde der Traffic von SRC an eine IP im eigenen Subnetz an 192.168.1.2 geschickt, was ziemlich sinnfrei wäre ;-)
ip route add 192.168.1.0/24 dev ethX table meineTabelle metric 0

gerade die letzte Regel wird gern vergessen und das führt dann zu asymetrischem Routing. Denn sobald der Traffic eine 'rule" trifft, dann werden globalen Routen verwendet (d.h. keine default Route oder Netzwerkroute)

 

[MMD*]

Hallo,

Edit: Habe nicht aufgepasst, lesen ist kunst

 

[horstepipe]

@horstepipe
Die Antwort ist also nach wie vor ein protokollabhängiges Routing ist nach meiner Meinung nur über spezielle Regeln per iptables möglich. Also pure Handarbeit auf der DS siehe als Beispiel #5 von jahlives.

Gruß Frank

ok danke.

@Frank
theoretisch würde es auch mit reinem Routing gehen, setzt aber einige Dinge voraus Zum ersten muss der Dienst, der nicht das default Routing verwenden soll eine eigene IP Adresse haben.

also wenn ich jetzt keinen Denkfehler habe, haben doch alle Dienste von und auf der DS keine eigene IP-Adresse? Sprich ich müsste es mit der Lösung per iptables realisieren?
Ich habe vorher noch nicht mit iptables gearbeitet, können wir das vielleicht an einem Beispiel durchspielen?
Meine DS ist als Client via Openvpn mit einem VPN-Server (nvpn) verbunden. Sämtlicher Verkehr scheint ausschließlich über die VPN zu laufen und die DS ist auch nicht über die lokale externe IP erreichbar.
Nun möchte ich, dass das Paket Video Station nicht über die VPN läuft, da dafür der Traffic zu hoch ist und die Übertragung zu langsam ist.

lG

 

[horstepipe]

soo, ich glaube ich habe eine (für mich) ausreichende Lösung gefunden:
In den erweiterten Netzwerkeinstellungen im DSM einfach "mehrere Gateways aktivieren" ankreuzen.
So scheinen alle meine Dienste sowohl über VPN, als auch über meine lokale Gateway erreichbar zu sein.
Bestimmte Dienste nun auf bestimmte Gateways zu beschränken sollte doch über simple Firewall-Einträge realisierbar sein, oder?
Klärt mich auf, sollte ich etwas gravierendes übersehen.

lG

 

[jahlives]

jeder Dienst, der an ein Netzwerkinterface gebunden ist, hat auch eine IP Adresse. Sonst könntest du ihn ned erreichen ;-)
Bei Dir scheint die globale default Route zum VPN-Server zu zeigen, damit kannst du dann die Dienste von aussen nicht ohne VPN erreichen, weil die Antworten der DS in den VPN Tunnel gehen. Das wäre prädestiniert für ein policy based Routing, da du ja eine andere IP hast, wenn der Dienst von einem No-VPN-Interface aus antwortet. Schau mal auf der DS ob es die Datei /etc/iproute2/rt_tables gibt. Es kann auch sein, dass Synology andere Pfade verwendet, dann könntest du so suchen

find / -type f -name rt_tables

Falls diese Datei vorhanden ist, sollte dein Problem mit reinem Routing lösbar sein.
Im folgenden gehe ich mal davon aus, dass die Datei vorhanden ist.

Weitere Voraussetzungen:

• dein Subnetz 192.168.0.0/24
• IP der DS in diesem Subnetz 192.168.0.100
• Router in diesem Subnetz 192.168.0.1

Dann trägst du in dieser Datei eine neue Zeile ein

100 deineTabelle

Dann brauchst du eine ip Regel, die verknüpft bestimmten Traffic mit deiner Routing Tabelle. Also alle Pakete von der Source 192.168.0.100 geht durch die Tabelle deineTabelle

ip rule add from 192.168.0.100 table deineTabelle priority 100

Dann musst du diese Tabelle noch mit entsprechenden Einträgen befüllen

ip route add default table meineTabelle via 192.168.0.1 metric 100
ip route add 192.168.0.1/24 dev eth0 table meineTabelle metric 0

Wichtig: dieses Routing betrifft alle Dienste nicht nur die Videostation. Wenn du also einen Dienst im VPN erreichen willst, dann musst du ihn auch über die VPN IP der DS ansprechen. Willst Du hingegen einen Dienst ohne VPN erreichen, dann musst du mit der LAN IP der DS "reden". Eine Portweiterleitung am Router auf die LAN IP der DS sollte mit diesem Routing-Setup sauber funzen

 

[horstepipe]

jetzt scheinen wir ja fast gleichzeitig geantwortet zu haben
Ist gegen meine o.g. Lösung was einzuwenden? Diese ist ja mit deutlich weniger Aufwand verbunden.
Danke dir für die ausführlichen Antworten

 

[jahlives]

ich weiss nicht wie Syno diese "zwei Gateways" umsetzt. Drum kann ich dir das nicht beantworten. Aber das Feature deutet darauf hin, dass rt_tables vorhanden sein müsste ;-) Du kannst das aber prüfen und dir mal die Regeln anzeigen lassen

ip rule ls

dabei sollten dir neben den Systemtabellen (local, main und default) auch die Tabellen, welchje Syno für dieses "zwei Gateway" Feature nutzt, angezeigt werden. Den Inhalt einer solchen Tabelle kannst du dir folgendermassen angucken

ip route ls table TABELLEN_NAME

Nimmt mich wunder was Synology hier konfiguriert hat

 

[horstepipe]

Danke Dir!

 

[horstepipe]

soo jetzt wo das klappt hab ich das nächste Problem.
Die VPN-Server-Funktion der DS funktioniert zwar (PPTP und IPsec/L2TP), ich kann aber nicht auf die Geräte in meinem LAN zugreifen.
Wenn ich z.B. mit dem Handy per L2TP zum DS-VPN-Server verbinde, komme ich zwar ins Internet, jedoch nicht z.B. auf die DS-Weboberfläche.

Als VPN-Server trage ich MEINE externe IP ein, nicht die des Tunnels, den die DS als Client zum VPN-Anbieter aufbaut.
Ich hoffe mich halbwegs verständlich auszudrücken

lG

 

[horstepipe]

ok ich komme nur nicht auf die DS, andere Geräte im LAN sind erreichbar.
Jemand ne Idee?

 

[horstepipe]

Hier mal meine Regeln:

ip rule ls

0:      from all lookup local
2:      from all lookup static-table
3:      from 192.168.0.3 lookup eth0-table
4:      from 192.168.1.3 lookup eth1-table
5:      from 10.85.xxx.x lookup tun0-table
32766:  from all lookup main
32767:  from all lookup default

ip route ls table local

local 10.85.xxx.x dev tun0  proto kernel  scope host  src 10.85.xxx.x
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
broadcast 192.168.0.0 dev eth0  proto kernel  scope link  src 192.168.0.3
local 192.168.0.3 dev eth0  proto kernel  scope host  src 192.168.0.3
broadcast 192.168.0.255 dev eth0  proto kernel  scope link  src 192.168.0.3
broadcast 192.168.1.0 dev eth1  proto kernel  scope link  src 192.168.1.3
local 192.168.1.3 dev eth1  proto kernel  scope host  src 192.168.1.3
broadcast 192.168.1.255 dev eth1  proto kernel  scope link  src 192.168.1.3

ip route ls table eth0

default via 192.168.0.1 dev eth0
192.168.0.0/24 via 192.168.0.3 dev eth0

ip route ls table eth1

192.168.1.0/24 via 192.168.1.3 dev eth1

ip route ls table main

0.0.0.0/1 via 10.85.xxx.y dev tun0
default via 192.168.0.1 dev eth0
10.85.xxx.z via 10.85.xxx.y dev tun0
10.85.xxx.y dev tun0  proto kernel  scope link  src 10.85.xxx.x
128.0.0.0/1 via 10.85.xxx.y dev tun0
185.xx.xx.xxx via 192.168.0.1 dev eth0
185.xx.xx.xxx via 192.168.0.1 dev eth0  src 192.168.0.3
192.168.0.0/24 dev eth0  scope link  src 192.168.0.3
192.168.1.0/24 dev eth1  scope link  src 192.168.1.3

Die Tabellen static, tun0 und default sind leer.

Meine DS hat die lokale IP 192.168.0.3. Sie hat zwei LAN-Anschlüsse, der andere (192.168.1.3, eth1) geht zum Nachbarn, spielt hier aber keine Rolle.
Mein Router hat die IP 192.168.0.1.
Die VPN-IP (DS als VPN-Client zu nvpn) ist die 185.xx.xx.xxx
Die 10.85.xxx.x/y/z haben auch irgendwas mit dem VPN-Anbieter zu tun, kannst du mir sicherlich sagen was genau


Sowohl über PPTP, als auch über L2TP/IPSec (DS als VPN-Server) kann ich problemlos verbinden und ins Internet (getestet mit iPhone 5s). Auch komme ich auf andere Geräte im LAN (Webinterface vom AV-Receiver und Drucker, 192.168.0.4/5)
Nur auf die DS und alle Anwendungen dieser bekomme ich einfach keinen Zugriff. Habe schon die IP 192.168.3.1 und 10.0.0.0 ausprobiert, keine Änderung. Alle Firewall-Regeln habe ich testweise auch schon in der DS deaktiviert.

Soll ich vielleicht nochmal die Einstellung "mehrere Gateways aktivieren" rausnehmen und deinen Weg mit dem manuellen Eintragen der Regeln versuchen? Wie wäre dies denn wieder rückgängig zu machen?

lG

 

[horstepipe]

Soo ich habe "mehrere Gateways aktivieren" rausgenommen und bin deiner Anleitung gefolgt:

Dann trägst du in dieser Datei eine neue Zeile ein

100 deineTabelle

Dann brauchst du eine ip Regel, die verknüpft bestimmten Traffic mit deiner Routing Tabelle. Also alle Pakete von der Source 192.168.0.100 geht durch die Tabelle deineTabelle

ip rule add from 192.168.0.100 table deineTabelle priority 100

Dann musst du diese Tabelle noch mit entsprechenden Einträgen befüllen

ip route add default table meineTabelle via 192.168.0.1 metric 100
ip route add 192.168.0.1/24 dev eth0 table meineTabelle metric 0

Beim letzten Befehl musste ich jedoch statt

ip route add 192.168.0.1/24 dev eth0 table meineTabelle metric 0

dieses

ip route add 192.168.0.0/24 dev eth0 table meineTabelle metric 0

eingeben, da ich sonst "invalid argument" zurückbekam.

Leider führt diese Methode zu genau demselben Ergebnis wie die andere.
Bin für jeden Tipp dankbar.

lG