Falsche Serverzeit: So prüfen Sie die Zeitsynchronisation
Fehler bei Zertifikaten, abgelehnte Tokens und unklare Zeitabläufe. Was Sie in UTC und chrony prüfen sollten, bevor Sie die Serveruhr korrigieren.
Ein Zertifikat liegt noch innerhalb seines Gültigkeitszeitraums, doch ein Client lehnt es ab. Die Anmeldung meldet ein Problem mit der Gültigkeit eines Tokens, und Ereignisse verschiedener Server passen zeitlich nicht zusammen. Prüfen Sie bei solchen Symptomen auch die Uhr des Geräts, das die Validierung durchführt. Eine falsche Zeit ist eine mögliche Ursache, noch keine Diagnose. Der folgende Ablauf gilt für Linux mit systemd; die Messbeispiele verwenden chrony.
Vergleichen Sie dieselbe Zeit statt unterschiedlicher Zeitzonen
Der Befehl date -u zeigt die Systemzeit in UTC an. Ergänzen Sie timedatectl status und erfassen Sie Datum, Zeitzone und Synchronisationsstatus. Unterschiedliche lokale Anzeigen bedeuten nicht zwangsläufig, dass eine Uhr nachgeht. Eine Änderung der Zeitzone ersetzt keine Korrektur der Synchronisation. Ermitteln Sie den Dienst, der die Zeit auf diesem Host verwaltet; die Uhrzeit allein zeigt keine Abweichung von einer Zeitquelle.
Bei der Zertifikatsprüfung zählt der Zeitraum zwischen notBefore und notAfter im Vergleich zur aktuellen Zeit. JWT verwendet exp für das Ende und nbf für den Beginn der Gültigkeit, sofern diese Claims vorhanden sind. Prüfen Sie deshalb auch die Uhr des Clients oder des validierenden Backends. Lassen Sie Gültigkeitsprüfungen bei der Diagnose aktiv und verlängern Sie Token-Laufzeiten nicht automatisch. Erfassen Sie zuerst den genauen Fehler und vergleichen Sie die Zeiten.
Prüfen Sie die Messung und die Erreichbarkeit der Quelle
Beginnen Sie bei chrony mit chronyc tracking. Das Feld System time zeigt den Unterschied zwischen der Systemuhr und der von chrony geführten Zeit; es ist nicht mit Last offset gleichzusetzen. Prüfen Sie auch Leap status, das Not synchronised melden kann. Speichern Sie die Ausgabe und vergleichen Sie sie später mit einer weiteren Messung. Eine einzelne kleine Zahl ohne die übrigen Angaben reicht zur Beurteilung der Synchronisation nicht aus.
Der Befehl chronyc sources -v zeigt die verwendeten Quellen. Ein Stern kennzeichnet die ausgewählte Quelle. Ein Fragezeichen kann eine unerreichbare oder nicht synchronisierte Quelle oder zu wenige Messungen bedeuten. Prüfen Sie bei fehlenden Antworten DNS und den Weg der NTP-Pakete einschließlich Firewall. Gewöhnliche NTP-Anfragen gehen an UDP-Port 123. Funktionierender HTTPS-Zugriff bestätigt für sich genommen nicht, dass diese Kommunikation funktioniert.
Unterscheiden Sie allmähliche Korrektur und Zeitsprung
Chrony korrigiert die Zeit normalerweise allmählich durch Anpassung der Geschwindigkeit der Uhr. Der Mechanismus makestep erlaubt einen Zeitsprung; die Konfigurationsdirektive kann ihn auf die ersten Aktualisierungen nach dem Start von chronyd begrenzen. Die Dokumentation warnt vor Auswirkungen solcher Sprünge auf manche Anwendungen. Ermitteln Sie bei einer großen Abweichung zuerst deren Ursache und beurteilen Sie, wie die laufenden Dienste die Korrektur verkraften.
Übernehmen Sie eine Korrekturkonfiguration für den Systemstart nicht ungeprüft in einen laufenden Vorfall. Erfassen Sie den Zustand vor der Änderung und planen Sie einen Ablauf für abhängige Dienste. Prüfen Sie nach dem Eingriff erneut die Synchronisation und die zuvor fehlgeschlagene Operation. Wenn Sie die Erreichbarkeit einer Quelle wiederherstellen, beobachten Sie auch, ob sich die Uhr tatsächlich korrigiert. Zurückkehrende Netzwerkantworten allein schließen die Diagnose noch nicht ab.
Überwachen Sie die Abweichung und messen Sie Dauern richtig
Messen Sie die Dauer einer Operation mit geeigneten monotonen Uhren, die Ihre Laufzeitumgebung bereitstellt. Linux CLOCK_MONOTONIC bleibt von einem plötzlichen Sprung der Systemzeit unbeeinflusst, wird jedoch durch Frequenzkorrekturen beeinflusst. Verwenden Sie für Ereigniszeitstempel weiterhin Kalenderzeit mit eindeutiger Zeitzone und Hostkennung. Die Dauer einer Anfrage und ihr Startzeitpunkt sind unterschiedliche Angaben.
Nehmen Sie Abweichung und Synchronisationszustand in Ihre Betriebsübersicht auf. Wählen Sie die Alarmschwelle anhand der Anforderungen der Anwendung statt einer universellen Millisekundenzahl. Prüfen Sie nach einem Neustart oder Quellenwechsel, ob die Messung weiterläuft. Vergleichen Sie diesen Zustand bei einem Vorfall mit TLS-Fehlern, fehlgeschlagenen Token-Prüfungen und den Logs der betroffenen Hosts.
- Erfassen Sie UTC und unterscheiden Sie Zeitzonenfehler und Uhrenfehler.
- Prüfen Sie chrony, die ausgewählte Quelle und NTP-Antworten.
- Beurteilen Sie die Auswirkungen einer Korrektur vor einem Zeitsprung.
- Prüfen Sie nach dem Eingriff Synchronisation und ursprüngliche Nutzeroperation.
Was Sie mitnehmen
Prüfen Sie bei Verdacht auf eine falsche Zeit das Gerät, das über die Gültigkeit der Operation entscheidet. Messen Sie zuerst Synchronisation und Erreichbarkeit der Quelle und planen Sie dann die Korrektur. Bestätigen Sie die Behebung durch Messungen und die Funktion des Dienstes.
