Sechzig-Sekunden-TLS-Timeout: Welche Seite hat tatsächlich aufgehört?

Der Client gibt nach sechzig Sekunden mit einer Meldung zur Schlüsselaushandlung auf, und der Laptop äußert keine Meinung dazu, warum. Dieser Satz beschreibt die Geduld des Clients, nicht das Verhalten des Servers. Drei ganz verschiedene Situationen erzeugen ihn: Das Paket erreichte nie den richtigen Dienst, der Dienst verwarf es, bevor er etwas protokollierte, oder der Dienst lehnte es ab und sagte es an einer Stelle, die der Client nicht sehen kann. Erst die Korrelation eines Versuchs an beiden Enden trennt diese Fälle.

Geben Sie einem Versuch eine Identität, nach der Sie suchen können

Notieren Sie die Startzeit mit ihrer Zeitzone, den Profilnamen, das Ziel, das der Client tatsächlich aufgelöst hat, den Port und ob die Verbindung UDP oder TCP verwendet. Enthält das Profil mehrere entfernte Einträge, notieren Sie, welchen dieser Versuch gewählt hat, denn ein erneuter Versuch kann zum nächsten Eintrag gewechselt sein, ohne die Datei zu ändern, die Sie lesen.

Nehmen Sie den Endpunkt aus dem aktiven Protokoll und nicht aus dem Download, an den Sie sich erinnern. Ein Profil, das auf eine private Adresse zeigt, ist völlig gültig und von einem Netz aus, das dorthin nicht routen kann, völlig unbrauchbar, und dieser Fall sieht genauso aus wie ein Server, der ausgefallen ist.

Bitten Sie den Betreiber dann um dasselbe Zeitfenster auf der vorgesehenen Instanz. Uhrversatz ist häufig genug, dass eine Abweichung von wenigen Minuten ein passendes Ereignis als fehlend erscheinen lässt, also halten Sie die Abweichung fest, statt zu schließen, es habe kein Ereignis gegeben.

Vier Beobachtungen, vier verschiedene nächste Schritte

Was der Server aufzeichnet, entscheidet über den Zweig. Das Fehlen jeglichen Versuchs deutet auf Adressierung, Transport oder den Weg zum Dienst hin. Ankommende Pakete, die vor einem gewöhnlichen Austausch verschwinden, deuten auf die Anforderungen des Steuerkanals des tatsächlichen Dienstes hin. Eine benannte Ablehnung deutet auf das Objekt hin, das sie benennt. Antworten, die den Server verlassen, aber den Client nie erreichen, deuten auf den Rückweg hin.

Ein leeres Anwendungsprotokoll ist schwächere Evidenz, als es aussieht. Die Protokollierung beginnt an einem bestimmten Punkt des Austauschs, und Pakete, die davor verworfen werden, hinterlassen keine Spur in der Datei, die Sie lesen. Wo es zulässig ist, kann der Betreiber Dienst- und Netzbeobachtungen nutzen, um zu sehen, ob überhaupt etwas ankam.

Halten Sie die vier Ergebnisse in Ihren Notizen getrennt. Die Versuchung ist, sie zu „Server antwortet nicht“ zu verschmelzen, und genau dieser Satz schickt Leute zum Ändern von Chiffren, wenn das eigentliche Problem eine Firewall-Regel ist. Eine Notiz, die nur das Wort Timeout festhält, hat die Unterscheidung weggeworfen, für die Sie gerade bezahlt haben.

Beheben Sie die Phase, die die Evidenz benennt

Eine abgeschlossene TCP-Verbindung beweist nur, dass etwas einen Socket angenommen hat. Sie beweist nicht, dass der Listener der von Ihnen konfigurierte OpenVPN-Dienst ist, und ein Webserver auf demselben Hostnamen antwortet einem Browser einwandfrei, während er für den Tunnel irrelevant ist.

Meldet der Server eine abgelaufene Sperrliste, ist das ein weit konkreterer Fakt als der letztendliche Timeout des Clients, und die Korrektur gehört zur Zertifizierungsstelle statt zum Netz. Wenn die beiden Enden sich über den Schutz des Steuerkanals oder gemeinsames Material uneinig sind, ändert das Zurücksetzen eines Passworts nichts, denn das Verwerfen geschieht, bevor irgendein Nachweis geprüft wird.

Ändern Sie eine Sache, die die Evidenz tatsächlich stützt, und wiederholen Sie dann dasselbe Profil gegen denselben Endpunkt. Bewahren Sie das erste neue Ereignis auf, wenn die Verbindung weiter kommt, denn dieses Ereignis ist die nächste Phase der Untersuchung und kein neues Problem.

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

Was das Verlängern des Fensters tatsächlich ändert

Sechzig Sekunden sind das Handshake-Fenster des Clients, und die Client-Referenz der Community dokumentiert die Option, die es anpasst. Eine Erhöhung lässt den Client länger warten, bevor er aufgibt. Sie lässt einen fehlenden Dienst nicht erscheinen und macht ein abgelehntes Paket nicht akzeptabel.

Ein längeres Fenster hat eine legitime Verwendung bei einer langsamen Verbindung oder einem stark belasteten Server, und es lohnt sich, es zu probieren, sobald Sie Belege haben, dass der Austausch langsam vorankommt und nicht gar nicht stattfindet. Es zuerst zu probieren, verzögert nur dieselbe Diagnose um eine weitere Minute und macht die Zeitachse schwerer lesbar. Zeigt die Zeitachse einen Austausch, der vorankommt und dann stockt, ist das Fenster ein Symptom der Last und nicht der Erreichbarkeit.