Ich habe im Haus meiner Eltern einen RaspberryPi mit PiVPN eingerichtet und so konfiguriert, dass er mir und einigen Freunden einen persönlichen VPN-Dienst bietet. Dieses VPN hat von Anfang an einwandfrei funktioniert, ich habe es mit meinem PC verwendet und nie einen Fehler bekommen.
Ich habe vor Kurzem einen weiteren Computer mit Windows10 im Haus meiner Eltern eingerichtet, der als Server für verschiedene Zwecke fungieren soll (falls es mit diesem Problem zusammenhängt: Ich verwende ihn als Heim-Multimediaserver mit Plex Media Server und auch als Git-Repository für den persönlichen Gebrauch). Er muss automatisch eine Verbindung zum VPN herstellen, also habe ich Folgendes getan:
- Ich habe PiVPN so konfiguriert, dass die entsprechende .ovpn-Datei generiert wird, habe den OpenVPN-GUI-Client auf dem neuen Server installiert und die ovpn-Datei importiert. Tatsächlich habe ich für alle Verbindungen zu meinem VPN statische IPs konfiguriert, da ich möchte, dass sie immer die gleichen IPs haben.
- Ich habe OpenVPN so konfiguriert, dass es beim Start des Servers automatisch eine Verbindung herstellt. Dies habe ich erreicht, indem ich in diesem Ordner einen direkten Link zur OpenVPN-Benutzeroberfläche platziert habe
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. Dieser direkte Link hatte dieses Argument"C:\Program Files\OpenVPN\bin\openvpn-gui.exe" --connect ServerW10.ovpn Ich habe das Server-BIOS so konfiguriert, dass es automatisch hochfährt, wenn die Stromversorgung wiederhergestellt wird (damit der Server wieder hochfährt, wenn der Strom ausfällt) und ich habe es auch so konfiguriert, dass es sich automatisch mit dem Benutzer anmeldet, den ich bei der Installation von Win10 erstellt habe. Damit ist der Server hoffentlich immer angemeldet, wenn er eingeschaltet wird.
Da ich mir Sorgen um den Stromverbrauch im Haus meiner Eltern mache, habe ich diesen Server so konfiguriert, dass er nach 3 Stunden Inaktivität in den Ruhezustand wechselt (Windows 10-Einstellungen) und immer (mit einem Batch-Skript) um 2 Uhr morgens in den Ruhezustand wechselt.
Aufgrund der automatischen Ruhezustandsfunktion habe ich das BIOS so konfiguriert, dass Wake-on-LAN-Pakete akzeptiert werden, um den Server aufzuwecken. Ich habe das mehrmals getestet und es hat gut funktioniert. Auf diese Weise konnte ich den Server bei Bedarf für 3 Stunden aufwecken (was für meine Zwecke ausreicht).
Ich habe den Server einige Tage lang getestet: Ich habe ihn manuell in den Ruhezustand versetzt, ihn nach drei Stunden Inaktivität in den Ruhezustand versetzt, das Herunterfahren erzwungen usw., und OpenVPN hat immer gut funktioniert und die Verbindung konnte ohne Probleme wiederhergestellt werden.
Jetzt trat das Problem auf, als ich die VPN-Verbindung zum Server nach dem „2-Uhr-Schlaf“ testete. Ich weckte den Server und versuchte dann, ihn wie üblich mit seiner statischen VPN-IP anzupingen, konnte ihn aber nicht erreichen. Ich meldete mich über TeamViewer an, um zu prüfen, was los war, und als ich die GUI von OpenVPN öffnete, stellte ich fest, dass es in einer Schleife wie dieser feststeckte:
Thu Mar 01 10:26:28 2018 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Thu Mar 01 10:26:28 2018 Windows version 6.2 (Windows 8 or greater) 64bit
Thu Mar 01 10:26:28 2018 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Thu Mar 01 10:26:29 2018 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Mar 01 10:26:29 2018 TCP/UDP: Preserving recently used remote address: [AF_INET](my ip):(my port)
Thu Mar 01 10:26:29 2018 UDP link local: (not bound)
Thu Mar 01 10:26:29 2018 UDP link remote: [AF_INET](my ip):(my port)
Thu Mar 01 10:27:29 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Mar 01 10:27:29 2018 TLS Error: TLS handshake failed
Thu Mar 01 10:27:29 2018 SIGUSR1[soft,tls-error] received, process restarting
Thu Mar 01 10:27:34 2018 TCP/UDP: Preserving recently used remote address: [AF_INET](my ip):(my port)
Thu Mar 01 10:27:34 2018 UDP link local: (not bound)
Thu Mar 01 10:27:34 2018 UDP link remote: [AF_INET](my ip):(my port)
Thu Mar 01 10:28:34 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Mar 01 10:28:34 2018 TLS Error: TLS handshake failed
etc...
Ich habe das VPN mit meinem PC getestet und es funktioniert wie immer einwandfrei. Daher ist es höchstwahrscheinlich ein Fehler am Server.
Ich persönlich denke, dass das vielleicht etwas mit dem Batch-Skript zu tun hat, das ich erstellt und so programmiert habe, dass es um 2 Uhr morgens ausgeführt wird, um den PC um 2 Uhr morgens in den Ruhezustand zu versetzen, da ich mit anderen Ruhezustandsmethoden (manueller Ruhezustand und Ruhezustand bei Inaktivität) keine Probleme hatte. Das Batch-Skript sieht folgendermaßen aus:
rundll32.exe powrprof.dll,SetSuspendState 0,1,0
Ich habe dieses Skript verwendet, weil ich ein Tutorial gesehen habe, wie man ein Batch-Skript dafür erstellt. Wie in diesem Tutorial beschrieben, habe ich auch den folgenden Befehl ausgeführt, um den Ruhezustand anstelle des Ruhezustands zu aktivieren:
Powercfg -H OFF
Was könnte das Problem sein?
Antwort1
Ich habe es endlich behoben, obwohl ich zwei Probleme in meinem Setup hatte.
Zunächst gab es beim „VPN-Setup“ ein Problem: Der OpenVPN-Server (der RaspberryPi mit PiVPN) befand sich im selben Subnetz wie die Servermaschine.
Die .ovpn-Konfigurationsdatei verwies auf meinen persönlichen DNS, sodass der Server-Rechner, um eine Verbindung zum VPN des RaspberryPi herzustellen, den DNS erreichen und dann meinen RaspberryPi über die öffentliche IP des Routers meiner Eltern erreichen musste (die ich mit meinem Router verknüpft hatte). Dies ist ein Problem, da der gesamte VPN-Verkehr über einen festen UDP-Port auf die lokale IP des RaspberryPi umgeleitet wird, was bedeutet, dass die Antworten, die der RaspberryPi an den Server-Rechner sendete, als sie beim Router ankamen, aufgrund des umgeleiteten UDP-Ports im RaspberryPi landeten, sodass der Server-Rechnernie eine Antwort erhalten.
Ich habe dies behoben, indem ich die OVPN-Datei geöffnet und die Zeile geändert habe, die die Ziel-URL enthielt, um von hier aus eine Verbindung zum VPN herzustellen:
remote my.personal.dns {port_number}
dazu
remote {local_raspberry_pi_IP} {port_number}
Außerdem war das Sleep-Skript beim OpenVPN-Setup irgendwie fehlerhaft, und ich bin mir nicht ganz sicher, warum, aber ich denke, es hatte etwas mit der Deaktivierung des Ruhezustands zu tun. Ich habe heruntergeladenMicrosoft PsToolsund habe ein neues Skript erstellt, um den PC um 2 Uhr morgens in den Ruhezustand zu versetzen. Das neue Skript sieht so ausC:\{path_where_pstools_was_extracted}\PsTools\psshutdown.exe -d -t 0 -accepteula
Mit diesen Änderungen funktioniert der Server nun endlich wie erwartet.
Antwort2
Da Ihr Windows-PC (Server) sich die ganze Zeit über mit dem VPN bei Pi verbinden konnte, glaube ich nicht wirklich, dass die Portumleitung (Weiterleitung?) hier das Problem verursacht hat. Außerdem deutet die Tatsache, dass Sie das VPN (bei Pi) über die lokale IP erreichen konnten, darauf hin, dass möglicherweise ein Problem mit Ihrem Router vorliegt. Es ist möglich, dass sich Ihre öffentliche IP-Adresse in der Zwischenzeit geändert hat und Ihr DNS-Eintrag nicht gerade aktualisiert wurde.