uncharted
Goto Top

OpenVPN Problematik Default Local Gateway wird verändert Nicht den kompletten Traffic über den VPNTunnel schicken

Hallo zusammen,

ich habe den folgenden Aufbau:

Lokal-Server (LS) <-> 1.VPN-Tunnel <-> RootServer1 (RS1) <-> 2.VPN-Tunnel RootServer2 (RS2)

An diesem Aufbau kann ich leider nichts ändern, dieser ist so vorgegeben.

Die VPN-Verbindung von Lokal-Server zu RootServer1 funktioniert einwandfrei.

Meine Frage bzw. mein Problem bezieht sich auf die VPN-Verbindung RootServer1 zu RootServer2.

Vorab: Ich habe keinen SSH-Zugriff (oder ähnliches) auf RootServer2 und bekomme von dort nur die OpenVPN Client-config, mehr nicht.

Das Problem ist folgendes:

1. SSH-Verbindung zu RootServer1 funktioniert einwandfrei, wenn der 1.VPN-Tunnel steht und der Server hat seine öffentliche IP (91.x.x.119), ping vom RS1 zum LS steht.
2. VPN-Verbindung (Verbindungsaufbau erfolgt über Port 1195 ausgehend und Port 1194 bei RS2) wird von RootServer1 zu RootServer2 aufgebaut
3. RootServer1 verliert seine SSH-Verbindung auf die default IP (91.x.x.119) und ist nun nur noch über die IP vom RootServer2 erreichbar (79.x.x.86), ping auf die 91.x.x.119 schlägt fehl.

Somit wird der default gateway vom RootServer1 auf den OpenVPN Server gesetzt (79.x.x.86).

Jedoch soll RootServer1 seine lokale IP (SSH soll unter 91.x.x.119 erreichbar bleiben), sowie auch den default Gateway behalten (Aufgrund der schlechten Anbindung von RS2) und nur einen gewissen Teil (nur 2 Ports) durch die VPN-Verbindung schicken.

Ich habe in der VPN Client-Config (von RS1 zu RS2) den Eintrag redirect-gateway entfernt, damit das default gateway bleibt, jedoch wird dies scheinbar ignoriert.

Gibt es eine Möglichkeit, das ich dennoch den default Gateway als prio verwenden kann, ohne den VPN-Gateway?

Ich nehme auch gerne Vorschläge zur Optimierung entgegen.

Danke im Voraus für eure Hilfe.

Gruß
uncharted


Client-Config von Openvpn (von RS1 zu RS2), leider kein Zugriff auf die Server-Config von OpenVPN:

client
dev tun1
auth-user-pass /xx/xx/xxx.txt
proto udp
remote xxxx 1194
lport 1195
resolv-retry infinite
bind
persist-key
persist-tun
comp-lzo yes
ca /xx/xx/xxx.crt
verb 3

Die Routing-Tabelle ohne aktiven VPN-Tunnel (1.VPN-Tunnel ist ebenfalls aus)

Kernel-IP-Routentabelle

Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface

0.0.0.0         91.x.x.254   0.0.0.0         UG        0 0          0 eth0

91.x.x.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Die Routing-Tabelle mit aktiven VPN-Tunnel (1.VPN-Tunnel ist ebenfalls aus)
Kernel-IP-Routentabelle

Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface

0.0.0.0         10.x.x.69    128.0.0.0       UG        0 0          0 tun0

0.0.0.0         91.x.x.254   0.0.0.0         UG        0 0          0 eth0

10.x.x.1     10.x.x.69    255.255.255.255 UGH       0 0          0 tun0

10.x.x.69    0.0.0.0         255.255.255.255 UH        0 0          0 tun0

79.x.x.86   91.x.x.254   255.255.255.255 UGH       0 0          0 eth0

91.x.x.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

128.0.0.0       10.x.x.69    128.0.0.0       UG        0 0          0 tun0

IP-Tables auf RootServer1

# bestehende Verbindungen
iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
# Über Loopback alles erlauben
iptables -I INPUT -i lo -j ACCEPT
iptables -I OUTPUT -o lo -j ACCEPT
#VPN-Freigabe für 1.VPN-Tunnel
iptables -A FORWARD -i eth0 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.9.8.0/24 -o eth0 -j ACCEPT 
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 91.x.x.119
iptables -A INPUT -s 10.9.8.0/24 -j ACCEPT
#VPN-Freigabe für 2.VPN-Tunnel
iptables -A FORWARD -i eth0 -o tun1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.x.x.69/32 -o eth0 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -A INPUT -s 10.x.x.69/32 -j ACCEPT
#VPN
iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun1 -p udp --dport 1195 -j ACCEPT

Content-Key: 232970

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

Ausgedruckt am: 28.03.2024 um 22:03 Uhr

Mitglied: 108012
108012 19.03.2014 um 03:11:48 Uhr
Goto Top
Hallo,

Ich nehme auch gerne Vorschläge zur Optimierung entgegen.
Kann es sein dass Du einfach am RootServer1
nur das Routing aktivieren musst?

Gruß
Dobby
Mitglied: uncharted
uncharted 19.03.2014 um 12:12:31 Uhr
Goto Top
Meinst du forwarding?

net.ipv4.ip_forward=1

wurde schon in /etc/sysctl.conf eingetragen als Test, jedoch brachte dies keine Änderung.
Mitglied: 108012
108012 19.03.2014 um 17:26:13 Uhr
Goto Top
Zitat von @uncharted:

Meinst du forwarding?

Nein ich dachte da eher an Routing was auf dem Root Server1 aktiviert wird!
Hier in dieser Anleitung ist es gut beschrieben worden.


Gruß
Dobby
Mitglied: uncharted
uncharted 20.03.2014 um 02:56:30 Uhr
Goto Top
also vom Verständnis habe ich es verstanden, nur unter deinem Link befindet sich leider keine Erklärung der Befehle bzw ein Howto wie man es mit Linux macht. Lediglich Webinterfaces von Firewalls und Windows Server werden dort schritt für schritt erklärt.

Ich suche mir mal eine alternative Anleitung raus, jedoch muss ich wohl nur das forwarding aktivieren, das mein interface eth0 das default gateway bleibt.

Gruß
Mitglied: aqui
aqui 21.03.2014 um 20:00:03 Uhr
Goto Top
Wie man es bei Linux macht kannst du hier nachlesen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
oder auch hier:
Netzwerk Management Server mit Raspberry Pi
oder wenn du Dr. Google mal nach "ip forwarding linux" befragst !