10
Automatische OpenVPN Verbindung nur bei bestimmten Netzwerken
Hallo zusammen,
ich habe einen Laptop, der sich über OpenVPN mit unserem Hauptstandort verbindet. Dazu wird vom OpenVPN-Dienst die Verbindung beim Systemstart automatisch hergestellt. Wenn ich das von entfernten Standorten mache, funktioniert das auch. Wenn ich den (Windows)-Laptop dann am entfernten Standort in den Standby schicke und dann am Hauptstandort wieder einschalte, findet er das Netzwerk nicht. Ich muss den Laptop neu starten, damit ich überhaupt auf irgendwelche Netzwerkressourcen zugreifen kann.
Das dürfte daran liegen, dass die VPN-Verbindung im Standby offenbar "zwischengespeichert" wird und nach dem Standby das Routing nicht mehr passt. ( Vom internen Netzwerk am Hauptstandort erreiche ich die öffentliche VPN-IP-Adresse nicht - was ja auch nicht nötig ist).
Kann man da irgendwas machen?
z.B, dass das VPN abgeschaltet, wenn ich Netzwerk x.x.x.x bin? Gibt es bei OpenVPN so etwas wie eine Heartbeat/KeepAlive-Konnectivitätsprüfung?
OpenVPN-Server ist eine OPNSense, Client ein Windows 10 Laptop. Client-Software OpenVPN 2.5.7
Grüße
lcer
ich habe einen Laptop, der sich über OpenVPN mit unserem Hauptstandort verbindet. Dazu wird vom OpenVPN-Dienst die Verbindung beim Systemstart automatisch hergestellt. Wenn ich das von entfernten Standorten mache, funktioniert das auch. Wenn ich den (Windows)-Laptop dann am entfernten Standort in den Standby schicke und dann am Hauptstandort wieder einschalte, findet er das Netzwerk nicht. Ich muss den Laptop neu starten, damit ich überhaupt auf irgendwelche Netzwerkressourcen zugreifen kann.
Das dürfte daran liegen, dass die VPN-Verbindung im Standby offenbar "zwischengespeichert" wird und nach dem Standby das Routing nicht mehr passt. ( Vom internen Netzwerk am Hauptstandort erreiche ich die öffentliche VPN-IP-Adresse nicht - was ja auch nicht nötig ist).
Kann man da irgendwas machen?
z.B, dass das VPN abgeschaltet, wenn ich Netzwerk x.x.x.x bin? Gibt es bei OpenVPN so etwas wie eine Heartbeat/KeepAlive-Konnectivitätsprüfung?OpenVPN-Server ist eine OPNSense, Client ein Windows 10 Laptop. Client-Software OpenVPN 2.5.7
Grüße
lcer
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4247586100
Url: https://administrator.de/contentid/4247586100
Ausgedruckt am: 24.11.2024 um 05:11 Uhr
10 Kommentare
Neuester Kommentar
im Standby offenbar "zwischengespeichert" wird
Nicht ganz... Die Verbindung wird zwar abgebrochen (muss weil keine Keepalives mehr kommen) aber der Client versucht nach dem Aufwachen sofort den Tunnel wieder aufzubauen.Lösung:
Setze den Inactivity Timer auf einen entsprechenden Wert.
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4 ...
Nach --inactive n [bytes] suchen.
Der disconnected dann automatisch wenn n Sekunden lang nix passiert oder unter einen Treshold an Traffic fällt.. Im Default steht der auf 0 so das der Tunnel bis zum Sanktnimmerleinstag bestehen bleibt.
Das kann man in der Server Konfig setzen und automatisch an die Clients pushen lassen oder auch lokal am Client setzen.
Besser, wie immer, die bordeigenen L2TP oder IKEv2 Clients verwenden, da passiert das nicht. Deutlich performanter sind sie obendrein und die Frickelei mit externen Clients entfällt.
Ansonsten Holzhammer Metode. IP mit Powershell ermitteln und dann Kill ausführen.
Oder mit ähnlichen die IP ermitteln. Wurde die via DHCP geändert einfach einen taskkill /f /im openvpn hinterher schieben. Bin mir grad nichit sicher unter Linux gab es wohl auch ein Disconnect Kommando.
Wir hatten damals techn. nicht so versierte MA. Hab mit taskkill reconnect oder disconnect aufgebaut. Lief ganz gut. War aber über CMD ein rein manueller Prozeß.
Wo die IPs stehen, wissen wir ja - wmic. Entweder im Intervall prüfen lassen oder sowas hier
Das Aufwach-Event als Trigger nehmen und dann prüfen.
Neben Kill kann man so natürlich auch die Einwahl aufbauen. Das Kennwort kann ja hinterlegt werden und es zählt runter. Oder man gibt es in der Config mit an. Würde auch in die andere Richtung funktionieren.
$IP = Get-WmiObject win32_networkadapterconfiguration | Where-Object { $_.ipaddress -like "1*" } | Select-Object -ExpandProperty ipaddress | Select-Object -First 1 Oder mit ähnlichen die IP ermitteln. Wurde die via DHCP geändert einfach einen taskkill /f /im openvpn hinterher schieben. Bin mir grad nichit sicher unter Linux gab es wohl auch ein Disconnect Kommando.
Wir hatten damals techn. nicht so versierte MA. Hab mit taskkill reconnect oder disconnect aufgebaut. Lief ganz gut. War aber über CMD ein rein manueller Prozeß.
Wo die IPs stehen, wissen wir ja - wmic. Entweder im Intervall prüfen lassen oder sowas hier
Das Aufwach-Event als Trigger nehmen und dann prüfen.
Neben Kill kann man so natürlich auch die Einwahl aufbauen. Das Kennwort kann ja hinterlegt werden und es zählt runter. Oder man gibt es in der Config mit an. Würde auch in die andere Richtung funktionieren.
Hallo,
Ich werde mal mit testen.
@Crusher79 klar, das könnte gehen, vielleicht sogar über einen DHCP-Evenlog-getriggerten Task. Ich versuche aber erst mal die Variante auf openvpn-config-Basis
Grüße
lcer
Ich werde mal mit
openvpn [options...] --inactive 3600 --ping 10 --ping-exit 60@Crusher79 klar, das könnte gehen, vielleicht sogar über einen DHCP-Evenlog-getriggerten Task. Ich versuche aber erst mal die Variante auf openvpn-config-Basis
Grüße
lcer
Zitat von @aqui:
Besser, wie immer, die bordeigenen L2TP oder IKEv2 Clients verwenden, da passiert das nicht. Deutlich performanter sind sie obendrein und die Frickelei mit externen Clients entfällt.
Schon klar, aber IPSEC bekomme ich nicht stabil hin, da sind jeweils 2 kaskadierte NAT-Router dazwischen.Besser, wie immer, die bordeigenen L2TP oder IKEv2 Clients verwenden, da passiert das nicht. Deutlich performanter sind sie obendrein und die Frickelei mit externen Clients entfällt.
Grüße
lcer
Ich wollte damals Inaktivität nicht haben. Hab sogar einen Ping im Hintergrund mitlaufen lassen. Alles mit nirsoft verschleiert ^^
Da wäre sowas dann eher schlecht. Da es gerade ja kaum oder keine Inaktivität geben sollte. Taskkill lief robust. Musste wegen VPN Test o.ä. Notebook eig. nie neu starten. Die Scripte zum Auf- und Abbauen der Verbindung liefn einfach durch.
Hab grad die Scripte wieder gerfunden. Etwas wild. Würde ich heute mit PS machen. Im Grunde war der Ablauf so:
1. Altlasten aufräumen. Ping Lock File umbenennen und Prozesse killen
2. Einwahl ins Netz und warten bis der Tunnel steht
3. Dauer Ping via Art "lck" Datei - hier txt vor unerwünschten Loop schützen
4. Netzlaufwerke verbinden.
Ping Lock sollte verindern, dass beim Rumspielen auf einmal 50 CMD Task aufgebaut werden. Damit konnte ich eine Verbindung + 1x Dauerping im Hintergrund realisieren.
Nur ein Beipsiel! Würde es heute mit PS anders machen!
Bei sowas könnte man auch so eine Prüfung einfach einbauen
verbinden.cmd
ip_ping.cmd
ausschalten.cmd
Da wäre sowas dann eher schlecht. Da es gerade ja kaum oder keine Inaktivität geben sollte. Taskkill lief robust. Musste wegen VPN Test o.ä. Notebook eig. nie neu starten. Die Scripte zum Auf- und Abbauen der Verbindung liefn einfach durch.
Hab grad die Scripte wieder gerfunden. Etwas wild. Würde ich heute mit PS machen. Im Grunde war der Ablauf so:
1. Altlasten aufräumen. Ping Lock File umbenennen und Prozesse killen
2. Einwahl ins Netz und warten bis der Tunnel steht
3. Dauer Ping via Art "lck" Datei - hier txt vor unerwünschten Loop schützen
4. Netzlaufwerke verbinden.
Ping Lock sollte verindern, dass beim Rumspielen auf einmal 50 CMD Task aufgebaut werden. Damit konnte ich eine Verbindung + 1x Dauerping im Hintergrund realisieren.
Nur ein Beipsiel! Würde es heute mit PS anders machen!
Bei sowas könnte man auch so eine Prüfung einfach einbauen
verbinden.cmd
@echo off
c:\Scripts\nircmd.exe win hide class "ConsoleWindowClass"
rename c:\Scripts\ping.txt _ping.txt
taskkill /f /im openvpn.exe
taskkill /f /im openvpn-gui.exe
start "" "C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect OpenVPN_remote002.ovpn REM ÄNDERN!!!!!!!!!!!!!
goto :CHECK
:CHECK
ping -n 3 172.18.0.20 | find "Antwort von " >NUL
IF NOT ERRORLEVEL 1 goto :END
IF ERRORLEVEL 1 goto :CHECK
:END
rename c:\Scripts\_ping.txt ping.txt
start /b "" c:\Scripts\ip_ping.cmd
net use I: /DELETE /yes
net use I: \\172.17.0.19\test /persistent:no
exitip_ping.cmd
:LOOP
IF EXIST "C:\Scripts\ping.txt" (
ping -n 1 172.18.0.20 > NUL
ping -n 2 127.0.0.1 > NUL
goto :LOOP
) ELSE (
exit
)ausschalten.cmd
@echo off
c:\Scripts\nircmd.exe win hide class "ConsoleWindowClass"
rename c:\Scripts\ping.txt _ping.txt
taskkill /f /im openvpn.exe
taskkill /f /im openvpn-gui.exe
exitsda sind jeweils 2 kaskadierte NAT-Router dazwischen.
Das ist bei IPsec kein Hinderungsgrund denn dafür kann es ja NAT Traversal. Da können auch 20 NAT Router dazwischen sein! Weisst du als Profi ja auch selber...
Hallo,
hm.. wie weckst du den Laptop wieder auf (ohne Tunnelverbindung) ?
Ich hatte das "Problem" bisher nur (!) auf der Linuxebene , bei WinClients gings es immer mit Ein/GanzAus !
Ansonsten.. Tunnel weg-> IF weg -> Routing weg!
Openvon baut zwar den Tunnel wieder auf, arbeitet aber nicht das Start-Script ab .
Lösung war ähnlich wie beschrieben bei @Crusher79:
MinutenCronJob zum Test/neu setzen , das lief dann klaglos
Fred
hm.. wie weckst du den Laptop wieder auf (ohne Tunnelverbindung) ?
Ich hatte das "Problem" bisher nur (!) auf der Linuxebene , bei WinClients gings es immer mit Ein/GanzAus !
Ansonsten.. Tunnel weg-> IF weg -> Routing weg!
Openvon baut zwar den Tunnel wieder auf, arbeitet aber nicht das Start-Script ab .
Lösung war ähnlich wie beschrieben bei @Crusher79:
MinutenCronJob zum Test/neu setzen , das lief dann klaglos
Fred
@fredmy mir war auch so - die gelbe Hölle. Wenn es versucht, aber nicht kann.
Programme wie hide.me haben ja einen Kill-Switch drin. Bei normalen OPENvpn hatte ich so ein Verhalten nicht beobachtet. Also if und Routing weg. Wäre ja dann ok. Dann wäre der Block innerhalb der Orgainisation - IP nicht erreichbar - ja eig. ganz produktiv.
Ich teste heute Abend selber mal von zu Hause. Was da so abgeht. Oder es ist ein Konfligt auf besagten Client, der mit den allg. Windows Bedingungen zu tun hat, aber nicht pauschal das OPENvpn wiederspiegelt.
https://openvpn.net/blog/vpn-kill-switch/
@lcer00 poste doch mal deine Config. Ich meine auch, es tritt nicht bei jeder Konfiguration auf. Mit oder ohne Killswitch? Was wenn man den deativiert?
Programme wie hide.me haben ja einen Kill-Switch drin. Bei normalen OPENvpn hatte ich so ein Verhalten nicht beobachtet. Also if und Routing weg. Wäre ja dann ok. Dann wäre der Block innerhalb der Orgainisation - IP nicht erreichbar - ja eig. ganz produktiv.
Ich teste heute Abend selber mal von zu Hause. Was da so abgeht. Oder es ist ein Konfligt auf besagten Client, der mit den allg. Windows Bedingungen zu tun hat, aber nicht pauschal das OPENvpn wiederspiegelt.
https://openvpn.net/blog/vpn-kill-switch/
@lcer00 poste doch mal deine Config. Ich meine auch, es tritt nicht bei jeder Konfiguration auf. Mit oder ohne Killswitch? Was wenn man den deativiert?
1
Hallo,
nach dem Einfügen von
in die Client-Config funktioniert es. Die ursprüngliche Config wurde von der OPNSense erstellt/exportiert und enthielt die Einträge nicht.
Was genau passierte kann ich leider nicht so richtig nachvollziehen (bzw. das wäre mit gerade zu aufwändig). Ich komme nicht auf den Laptop, wenn ich keinen Domänencontroller erreiche (.. doch, mit einem lokalen Admin, aber dessen Password steht im LADPs auf dem DC und den erreiche ich ohne Laptop nur über Notfallzugänge, die ich nicht unbedingt nutzen möchte.) - Egal - Problem scheint erst mal gelöst.
Grüße
lcer
nach dem Einfügen von
inactive 3600
ping 10
ping-exit 60Was genau passierte kann ich leider nicht so richtig nachvollziehen (bzw. das wäre mit gerade zu aufwändig). Ich komme nicht auf den Laptop, wenn ich keinen Domänencontroller erreiche (.. doch, mit einem lokalen Admin, aber dessen Password steht im LADPs auf dem DC und den erreiche ich ohne Laptop nur über Notfallzugänge, die ich nicht unbedingt nutzen möchte.) - Egal - Problem scheint erst mal gelöst.
Grüße
lcer
Hallo,
kleiner Nachtrag - das Verhalten ist mit o.g. Config wie folgt:
Direkt nach dem Aufwecken aus dem Standby besteht keine Netzwerkkonnektivität. Eine Minute später verbindet sich der Laptop mit dem Domänennetzwerk.
Daher nehme ich an, dass ping-exit die Lösung darstellt. Mit der Minute Verzögerung kann ich leben.
Grüße
lcer
kleiner Nachtrag - das Verhalten ist mit o.g. Config wie folgt:
Direkt nach dem Aufwecken aus dem Standby besteht keine Netzwerkkonnektivität. Eine Minute später verbindet sich der Laptop mit dem Domänennetzwerk.
Daher nehme ich an, dass ping-exit die Lösung darstellt. Mit der Minute Verzögerung kann ich leben.
Grüße
lcer
