Open VPN mit QNAP 431kx OHNE redirect Gateway?

[ynfinity]

Hallo zusammen,

ich habe mir auf meiner QNAP 431kx openvpn eingerichtet.Funktioniert auch tadellos. Ich hätte jetzt allerdings gerne ein Profil wo der gesamte Traffic durch den Tunnel geroutet wird und ein Profil wo nur der Traffic zum remote Netz durch den Tunnel geht. Ersteres, also den gesamten Traffic durch den Tunnel routen funktioniert, zweiteres leider nicht.

Wenn "Nutzen Sie diese Verbindung als Standard..." aktiviert ist wird der gesamte Traffix durch den Tunnel geroutet.
Wenn "Nutzen Sie.." deaktiviert ist kann ich weder ein Gerät remote erreichen noch funktioniert lokal mein Internet. Der LanAdapter hat bei beiden Einstellungen folgende Settings:

Bei aktiviertem "Nutzen Sie diese..." ist meine Routingtabelle wie folgt:

Bei deaktiviertem "Nutzen Sie diese..." ist meine Routingtabelle wie folgt:

Die Clientconfig die ich aus der QNAP exportiere sieht in beiden Fällen gleich aus und zwar folgendermaßen:

client
dev tun
script-security 3
remote xy.org 1194
resolv-retry infinite
nobind
auth-nocache
auth-user-pass
remote-cert-tls server
reneg-sec 0
cipher AES-256-CBC
tls-cipher TLS-ECDH...
comp-lzo
proto udp
explicit-exit-notify 1
<ca>
-----BEGIN CERTIFICATE-----
MXXXXXXXM
-----END CERTIFICATE-----
</ca>

Da die Konfig in beiden Fällen gleich ist müssen die Parameter ja Serverseitig mitgegeben werden. Die Frage wäre jetzt wie ich diese Clientseitig übergehen kann.

Kann mir da jemand weiterhelfen? Ich habe schon diverse Parameter, die ich im Netzt gefunden habe manuel in die CLientconfig eingefügt, aber ohne jeden Erfolg.

Danke für die Hilfe

 

[GaborDenes]

Ein NAS "offen" dem Internet aussetzen, ist keine gute Idee, Der VPN-Server gehört auf den Router, Lies dich mal zu der Problematik im deutschen QNAO-Forum ein.

 

[ynfinity]

Was heißt hier offen dem Internet aussetzen? Ich forwarde den Port 1194 auf meine NAS und sonst ist da garnichts offen.

 

[Raijin]

Es lassen sich mehrere Dinge feststellen:

Mit dem Haken sind ganze 3 "Default"-Routen über die VPN-Verbindung aktiviert. Zum einen eine 0.0.0.0 /0 mit Metrik 2 und zum anderen zwei gesplittete Routen 0.0.0.0 /1 + 128.0.0.0 /1

Ohne den Haken fehlen zwar die beiden gesplitteten Routen, aber es ist nach wie vor die 0.0.0.0 /0 Route vorhanden.

In beiden Fällen gibt es keine explizite Route in ein Subnetz hinter der VPN-Verbindung.



redirect-gateway hat mehrere Betriebsmodi. Ohne Parameter wird eine explizite Route zum VPN-Server über das vorhandene Gateway erstellt (um die VPN-Verbindung sicherzustellen) und anschließend wird die vorhandene Standardroute gelöscht und durch 0.0.0.0 /0 via VPN-Server hinzugefügt. Diese Methode ist jedoch nicht ganz unproblematisch und deswegen gibt es den üblicheren Modus von redirect-gateway "def1", der die bestehende Standardroute unangetastet lässt und stattdessen zwei zusätzliche Routen einbaut, die 0.0.0.0 / 128.0.0.0 bzw. 128.0.0.0 / 128.0.0.0.

Eigentlich sollte aber nur eines von beidem passieren, eine 0.0.0.0 /0 Route oder zwei /1 Routen. Das irritiert mich offen gestanden.


Wie auch immer, in beiden Modi wird offenbar die VPN-Verbindung als Standardgateway benutzt, so auch für das private Subnetz hinter dem VPN-Server. Aus deinen Aussagen ist nicht erkennbar ob du über die erste Variante überhaupt versucht hast, dich mit dem lokalen Netzwerk hinter dem VPN zu verbinden. Du sprichst in diesem Fall nur von der funktionierenden Internetverbindung. Das sind zwei Paar Schuhe und deswegen ist hier Präzision gefragt. Prüfe bitte folgendes:



Annahme: Subnetz hinter VPN = 192.168.1.0 /24 (bei den Tests an das tatsächliche Subnetz anpassen)

Jeweils mit Variante 1 und 2

Start --> cmd
--> ping 8.8.8.8
--> tracert 8.8.8.8
--> ping 192.168.1.x (x = ein Gerät, das du im Zielnetz erreichen willst)
--> tracert 192.168.1.x



Ich vermute mal, dass du in beiden Varianten keinen Zugriff haben wirst, weil die Unterschiede in der Routingtabelle eigentlich keine Auswirkungen haben dürften. Es ist daher warhscheinlicher, dass das Zielgerät - 192.168.1.x - aktiv die Verbindung verweigert. Dies geschieht dann, wenn die Firewall des Ziels Anfragen von IP-Adressen außerhalb des eigenen Subnetzes blockiert. Das ist die Standardeinstellung von vielen Diensten, weil man die Erreichbarkeit aus fremden Subnetzen häufig noch aktiv freigeben muss.
In der Windows-Firewall wäre das zB in den eingehenden Regeln bei der zutreffenden Regel der "Scope", der Bereich der zulässigen Quell-IPs. Wenn dies auf "local subnet only" steht, ist ein Zugriff via VPN nicht möglich und muss explizit auf das VPN-Subnetz erweitert bzw. mit "Any IP" voll freigegeben werden.

*edit
Es kann auch sein, dass in der QNAP-GUI irgendwo ein Haken ist, der "Zugriff auf lokales Netzwerk via VPN" gewährt. So ist das bei Synology, wenn ich mich nicht irre. Wenn dem so ist, dann steuert der Haken mit ziemlicher Sicherheit die Firewall im NAS und gibt den Zugriff auf lokale IPs frei oder blockiert sie - vollkommen unabhängig vom Routing.

 

[ynfinity]

Bin gerade unterwegs, aber ich kann bei gesetzem Haken sowohl die NAS als auch andere Geräte im remote Netz erreichen. Auf Seiten wie meineipadresse.de wird mir dann auch auf dem entfernten PC der Anschluss des remote Standortes angezeigt. Bei nicht gesetzem Haken kann ich die 8.8.8.8 per ping erreichen. Tracert kann ich mal nachreichen, wenn ich später Zuhause bin.