Eine falsche Geräteuhr kann das VPN stoppen: Prüfen Sie zuerst die Zeit

Das VPN verbindet nicht mehr, im Protokoll steht etwas über ein Zertifikat, und der erste Reflex ist, das Profil zu ersetzen. Eine Geräteuhr, die Minuten oder Stunden daneben liegt, erzeugt genau diesen Fehler, weil die Gültigkeit des Zertifikats gegen den lokalen Zeitpunkt beurteilt wird. Das Etikett der Zeitzone auf dem Bildschirm ist nicht das Problem; die zugrunde liegende Zeit ist es. Prüfen Sie die Uhr, bevor Sie irgendein Zertifikatsmaterial anfassen.

Der Fehler sieht nach einem Zertifikatsproblem aus, nicht nach einem Uhrproblem

Ein TLS-Handshake schlägt fehl, wenn das Zertifikat der Gegenstelle außerhalb seines Gültigkeitsfensters relativ zur Uhr des Prüfers liegt. Diese Prüfung läuft auf dem Client, deshalb weist eine falsche Client-Uhr ein völlig gutes Zertifikat zurück. Der Fehlertext nennt das Zertifikat, und deshalb tauschen Leute es aus und sehen denselben Fehler erneut. Die Uhr ist die billigere Hypothese und sollte zuerst getestet werden.

Eine Uhr, die der realen Zeit voraus ist, weist ein aktuelles Zertifikat als abgelaufen zurück; eine Uhr, die nachgeht, weist ein neueres als noch nicht gültig zurück. Beide Meldungen zeigen auf Daten, und beide entstehen ohne jeden Kontakt zur Zertifizierungsstelle. Das ist der Hinweis: Ein echtes Ablaufen betrifft jeden Client, während ein Uhrproblem nur die eine Maschine mit der falschen Zeit betrifft.

Lesen Sie den Zeitpunkt, dann das Zertifikat

Geben Sie die Uhr in UTC und die eigenen Daten des Zertifikats aus, bevor Sie etwas ändern. Der Vergleich zweier absoluter Zeitpunkte nimmt die Frage der Zeitzone vollständig aus der Untersuchung. Wenn das Fenster des Zertifikats den aktuellen Zeitpunkt enthält, ist das Zertifikat nicht Ihr Fehler.

date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Wenn die lokale Uhr falsch ist, prüfen Sie, ob sie synchronisiert ist und womit. Eine Maschine mit deaktivierter Synchronisierung oder mit einer Zeitquelle, die sie nicht erreicht, driftet, bis etwas ausfällt. Die Statusausgabe nennt die Quelle und die letzte erfolgreiche Anpassung, was nützlicher ist als der aktuelle Versatz allein. Ein großer Versatz ohne konfigurierte Quelle ist ein anderes Problem als ein kleiner Versatz gegenüber einer funktionierenden Quelle.

timedatectl timesync-status
chronyc tracking

Hören Sie auf, wenn das Zertifikat für jeden Client wirklich abgelaufen ist. Dann ist die Uhr in Ordnung und das Zertifikat braucht eine Erneuerung, keine Anpassung.

Anmeldecodes scheitern aus einem verwandten, aber anderen Grund

Zeitbasierte Einmalkennwörter leiten ihren Wert aus dem aktuellen Zeitschritt ab, meist dreißig Sekunden. Ein Gerät, dessen Uhr mehr als einen oder zwei Schritte daneben liegt, erzeugt Codes, die der Server nicht annimmt, selbst wenn der Nutzer die richtigen Ziffern eingegeben hat. Der Fehler sieht wie ein falsches Kennwort aus, was Leute in eine Rücksetzschleife schickt, die eine Uhr nicht reparieren kann.

Finden Sie heraus, welche Komponente den Versuch abgelehnt hat, denn VPN-Client, Gateway und Identitätsanbieter melden unterschiedliche Stufen. Wenn der Code abgelehnt, das Kennwort aber angenommen wird, ist das Konto wahrscheinlich in Ordnung und die Uhr verdächtig. Wenn beides abgelehnt wird, kann das Konto gesperrt sein und die Uhr eine falsche Spur. Folgen Sie den Wiederherstellungshinweisen des Anbieters, statt Aufforderungen zu bestätigen, die Sie nicht ausgelöst haben.

Stellen Sie die Uhr nicht zurück, damit ein Code funktioniert. Das verdeckt die Ursache und bricht die nächste zeitbasierte Prüfung.

Reparieren Sie die Quelle, nicht die angezeigte Stunde

Synchronisierung ist ein Netzwerkdienst, und der Tunnel kann ändern, ob die Zeitquelle erreichbar ist. Eine Unternehmensquelle kann den Tunnel erfordern, während eine öffentliche Quelle durch Richtlinien blockiert sein kann. Surfen kann funktionieren, während der eigene Pfad des Zeitdienstes scheitert, weshalb diese Abhängigkeit leicht übersehen wird. NTP ist das Protokoll hinter der Anpassung, und es braucht seinen eigenen Pfad wie jeder andere Dienst.

sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20

Es gibt auch ein Problem mit der Startreihenfolge: Eine stark falsche Uhr kann einen authentifizierten Tunnel verhindern, und die einzige nutzbare Zeitquelle kann hinter diesem Tunnel liegen. Eine verwaltete Flotte braucht ein dokumentiertes Verfahren für diesen Zustand, und das Umgehen der Zertifikatsprüfung ist keines. Auf einem persönlichen Gerät nutzen Sie die Zeiteinstellungen des Betriebssystems und finden Sie heraus, warum die Uhr nach dem Herunterfahren oder Wiederherstellen verloren geht. Eine Maschine, die bei jedem Start driftet, hat ein Hardware- oder Konfigurationsproblem, kein VPN-Problem.

Versuchen Sie nach der Reparatur erneut die ursprüngliche Verbindung und lesen Sie den neuen Fehler getrennt. Eine schlechte Serveridentität, ein Zertifikat, das wirklich abgelaufen ist, und ein abgelehntes Konto sind drei verschiedene Fehler, und sie zu vermischen ist der Weg, auf dem eine einfache Uhrkorrektur zu einer Woche voller Profilwechsel wird.