OpenVPN-Problem - Die TLS-Schlüsselaushandlung konnte nicht innerhalb von 60 Sekunden durchgeführt werden

Ich konfiguriere einen OpenVPN-Server (Version 2.3.10) auf einem Windows 2012-Server, kann ihn jedoch nicht zum Laufen bringen.

Der Server befindet sich hinter einem Router, und ich habe den 1194-Port geöffnet und eine Regel erstellt, um den Datenverkehr auf diesem Port an den Server weiterzuleiten.

Hier ist das Protokoll, das auf dem Server angezeigt wird, wenn ich versuche, eine Verbindung von einem Client aus herzustellen:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 TLS Error: TLS handshake failed
Mon Mar 21 11:12:48 2016 XX.XX.XX.XX:57804 SIGUSR1[soft,tls-error] received, client-instance restarting

Wobei XX.XX.XX.XX die IP des Clients ist. Daraus ergibt sich, dass der Client zumindest auf dem Server ankommen kann, sodass keine Routing- oder Firewall-Probleme auftreten.

Ich habe die hier angegebene Beschreibung befolgt. Easy Windows Guide Irgendwelche Ideen?

Interessant ist, wie sich die Portnummer während des Streams ändert:

Mon Mar 21 11:11:47 2016 XX.XX.XX.XX: 57804 TLS : Erstes Paket von [AF_INET] XX.XX.XX.XX: 57804, sid = fdf7a7ac 0264c7f3

Mon Mar 21 11:12:38 2016 XX.XX.XX.XX: 55938 TLS : Erstes Paket von [AF_INET] XX.XX.XX.XX: 55938, sid = 1f242a3f e454a525

Dies lässt mich denken, dass irgendwo zwischen Client und Server ein sich schlecht verhaltendes NAT-Gerät vorhanden ist, ein Gerät mit sehr kurzlebigen Statustabelleneinträgen, das die Quellportnummer ändert, die es auf den vom Client eingerichteten Stream anwendet, wodurch der Server dazu veranlasst wird Denken Sie, dass zwei kurzlebige Kommunikationen im Gange sind, anstatt eine kontinuierliche.

Solche Geräte tun dies im Allgemeinen nur mit UDP. Ich habe Ihnen daher empfohlen, zu bestätigen, dass Sie UDP verwenden, und stattdessen TCP zu versuchen. Dies haben Sie getan und festgestellt, dass es das Problem behebt. Der nächste Schritt besteht darin, das sich schlecht verhaltende NAT-Gerät zu identifizieren, es mit einem Hammer zu schlagen und es durch ein Gerät zu ersetzen, das nicht den Hauptfehler macht, anzunehmen, dass alle UDP-Kommunikationen kurzlebig sind. Sie haben jedoch angegeben, dass Sie mit der Umstellung auf TCP als Problemumgehung zufrieden sind, und die Angelegenheit ist damit abgeschlossen.

Dies ist einer der häufigsten Fehler beim Einrichten von Openvpn und es gibt einen FAQ-Eintrag dafür. Ich werde dies hier zitieren:

TLS-Fehler: Die TLS-Schlüsselaushandlung konnte nicht innerhalb von 60 Sekunden durchgeführt werden (überprüfen Sie Ihre Netzwerkverbindung).

Eines der häufigsten Probleme beim Einrichten von OpenVPN besteht darin, dass die beiden OpenVPN-Dämonen auf beiden Seiten der Verbindung keine TCP- oder UDP-Verbindung miteinander herstellen können.

Dies ist fast ein Ergebnis von:

• Eine Perimeter-Firewall im Netzwerk des Servers filtert eingehende OpenVPN-Pakete heraus (standardmäßig verwendet OpenVPN die UDP- oder TCP-Portnummer 1194).
• Eine Software-Firewall, die auf dem OpenVPN-Server ausgeführt wird, filtert eingehende Verbindungen an Port 1194. Beachten Sie, dass viele Betriebssysteme eingehende Verbindungen standardmäßig blockieren, sofern nicht anders konfiguriert.
• Ein NAT-Gateway im Netzwerk des Servers verfügt nicht über eine Portweiterleitungsregel für TCP / UDP 1194 an die interne Adresse des OpenVPN-Servercomputers.
• Die OpenVPN-Clientkonfiguration hat nicht die richtige Serveradresse in ihrer Konfigurationsdatei. Die Remote-Direktive in der Client-Konfigurationsdatei muss entweder auf den Server selbst oder auf die öffentliche IP-Adresse des Gateways des Servernetzwerks verweisen.
• Eine weitere mögliche Ursache ist, dass die Windows-Firewall den Zugriff für die Binärdatei openvpn.exe blockiert. Möglicherweise müssen Sie eine Whitelist erstellen (zur Liste "Ausnahmen" hinzufügen), damit OpenVPN funktioniert.

Es ist sehr wahrscheinlich, dass eines dieser Probleme auch in Ihrem Fall das gleiche Problem verursacht. Gehen Sie einfach die Liste einzeln durch, um sie zu beheben.

Ref: TLS-Fehler: Die TLS-Schlüsselaushandlung konnte nicht innerhalb von 60 Sekunden durchgeführt werden (überprüfen Sie Ihre Netzwerkverbindung).

Ich habe solche Zeitüberschreitungen für die TLS-Schlüsselverhandlung erhalten. In meinem Fall wurde mir jedoch klar, dass die Remoteverbindung eine lokale IP-Adresse war.

Das VPN in unserer pfSense-Firewall wurde fälschlicherweise auf die LAN-Schnittstelle anstatt auf die WAN-Schnittstelle gestellt, und daher wurde die exportierte Konfiguration so eingestellt, dass versucht wurde, eine Verbindung zur LAN-IP-Adresse der Firewall herzustellen - was bei natürlich aktivem Client niemals funktionieren würde ein anderes LAN.

Ich denke, die wichtigsten Erkenntnisse daraus sind:

• Das Erhalten eines Zeitlimits für die Schlüsselverhandlung bedeutet nicht unbedingt, dass Sie es überhaupt geschafft haben, eine Verbindung zu irgendetwas herzustellen.

  In diesem Stadium kann es sich dennoch lohnen, zu überprüfen, ob Sie tatsächlich eine Verbindung zum richtigen Ort herstellen, und es gibt keine Firewall-Regeln, die die Verbindung blockieren usw. Insbesondere, wenn Ihre Konfiguration automatisch generiert wurde.

  Beachten Sie, dass das Abrufen einer Anmeldeaufforderung nicht bedeutet, dass Sie verbunden sind , da OpenVPN vor dem Versuch, eine Verbindung herzustellen, nach Ihren Anmeldeinformationen fragt.

• Stellen Sie sicher, dass Ihr VPN-Server die richtige Schnittstelle überwacht.

  (Dies ist natürlich eine von mehreren serverseitigen Fehlkonfigurationen, die auftreten können, z. B. Firewall-Regeln, Eingabe der falschen Portnummer, Vermischung von TCP und UDP usw.)

Ich hatte den gleichen Fehler und kein Rat half, alles schien in Ordnung zu sein: IPs, Ports, Firewall, alles. 2 Stunden lang verrückt geworden.

Die Lösung bestand darin, das Protokoll in der Client-Konfiguration von UDP auf TCP zu ändern (anscheinend habe ich UDP vor langer Zeit absichtlich deaktiviert).

Hoffe das hilft jemandem :)

LE: Dies hat mein Problem gelöst, aber es ist nicht der beste Ansatz gemäß den folgenden Kommentaren. Sie sollten UDP anstelle von TCP verwenden. Es hat mir geholfen, weil ich unterschiedliche Einstellungen zwischen der Client- und der Serverkonfiguration hatte.

Keine der zuvor genannten Lösungen hat funktioniert. In meinem Fall wurden TLS Error: TLS key negotiation failed to occur within 60 secondsdie Serverprotokolle angezeigt, obwohl das Clientprotokoll denselben Fehler aufwies VERIFY ERROR: depth=0, error=CRL has expired.

Auf dem Server wurde das Verbindungsproblem durch die folgenden Schritte behoben:

# cd <easyrsa folder>
# ./easyrsa gen-crl
above command generates new crl.pem file (in my case in pki folder)
using chown/chmod make sure 'pki/crl.pem' is readable by openvpn server (for example: chmod 640 pki/crl.pem)
# systemctl restart openvpn

Beachten Sie, dass Sie einen TLS-Schlüsselaushandlungsfehler erhalten können, ohne erfolgreich eine Verbindung zum OpenVPN-Server herzustellen - oder überhaupt eine erfolgreiche Verbindung zu irgendetwas herzustellen!

Ich habe eine VPN-Konfiguration geändert, um eine Verbindung zu localhost an einem Port herzustellen, der nichts abhört:

OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] wurde am 26. April 2018 erstellt
Windows Version 6.2 (Windows 8 oder höher) 64-Bit
Bibliotheksversionen: OpenSSL 1.1.0h 27. März 2018, LZO 2.10
TCP / UDP: Beibehaltung der zuletzt verwendeten Remote-Adresse: [AF_INET] 127.0.0.1:12345
UDP-Verbindung lokal (gebunden): [AF_INET] [undef]: 0
UDP-Verbindungsfernbedienung: [AF_INET] 127.0.0.1:12345 
TLS-Fehler: Die TLS-Schlüsselaushandlung konnte nicht innerhalb von 60 Sekunden durchgeführt werden (überprüfen Sie Ihre Netzwerkverbindung).
TLS-Fehler: TLS-Handshake fehlgeschlagen
SIGUSR1 [soft, tls-error] empfangen, Prozess neu gestartet
...

Der Fehler kann Sie in das falsche Gefühl wiegen, dass Sie mit einem VPN-Server sprechen.

Möglicherweise werden Sie sogar zuerst zur Eingabe von Anmeldeinformationen aufgefordert, aber nichts außerhalb Ihres Computers hat tatsächlich danach gefragt.

Ich bin auf diesen Fehler in AWS gestoßen, wo OpenVPN auf einem Server mit einer öffentlichen IP installiert war, aber auf einer Instanz, die sich in einem privaten Subnetz befand, dh einem Subnetz, das keine Route zu einem Internet-Gateway hatte.

Nachdem ich OpenVPN auf einem Server in einem öffentlichen Subnetz bereitgestellt hatte, funktionierte alles einwandfrei :)

In öffentlichen / privaten Subnetzen in AWS: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html

Ich bin auch auf das TLS key negotiation failed to occur within 60 secondsProblem gestoßen.

Aus dem offiziellen Vorschlag geht hervor, dass als Diamant-Post etwas in der Netzwerkverbindung nicht stimmt. Weder die Firewall noch das NAT verursachen das Problem.

In meinem Fall habe ich zuerst die Verbindung durch überprüft nc -uvz xxx.xxx.xxx.xxx 1194. Der Link ist OK.

Außerdem funktionieren mehrere andere VPN-Clients im selben LAN einwandfrei.

Von irgendwoher bemerkte ich, dass die udp-Verbindung einige Probleme mit der Antwort oder der Portweiterleitung hat.

Also stoppe ich die laufenden VPN-Clients von der größten IP zum hängenden Client, z. B. von "10.8.0.100" bis "10.8.0.50".

Starten Sie dann die gestoppten VPN-Clients in umgekehrter Reihenfolge.

Knall! Alle VPN-Clients arbeiten ordnungsgemäß.

Zusammenfassend besteht die Möglichkeit, TLS key negotiation failed to occur within 60 secondsdass mehrere VPN-Clients in einem LAN in einer falschen Reihenfolge beginnen.