NTP: Warum Zeitgenauigkeit im Betrieb kritisch ist

NTP (Network Time Protocol) hält die Uhren von Rechnern synchron. Das klingt nach einem nebensächlichen Detail – ist aber eine der wichtigsten Grundlagen im Betrieb. Ohne genaue Zeit sind Protokolle unbrauchbar, Zertifikate ungültig und verteilte Systeme fehlerhaft.

Warum Zeitgenauigkeit kritisch ist

Zeit ist die einzige gemeinsame Referenz in verteilten Systemen.

Falsche Zeit bedeutet konkret:
  - TLS: Ein Zertifikat wird als "noch nicht gueltig" oder
    "abgelaufen" abgelehnt, weil die Client-Uhr daneben liegt.

  - Kerberos/AD und 802.1X: Ein Zeitversatz ueber 5 Minuten
    laesst die Anmeldung fehlschlagen - mit der irrefuehrenden
    Meldung "Anmeldedaten ungueltig".

  - Protokolle: Ereignisse erscheinen in falscher Reihenfolge.
    Eine Ursache-Wirkungs-Analyse ist unmoeglich.

  - Verteilte Datenbanken: Konsensverfahren (Raft, Paxos)
    verweigern den Dienst bei zu grosser Zeitabweichung.

  - CI/CD und Signaturen: Signierte Artefakte werden abgelehnt.

  - Abrechnung und Messwerte: Zeitreihen sind nicht korrelierbar.

Faustregel: Alle Systeme sollten innerhalb weniger Millisekunden
zueinander liegen. Fuer Protokollauswertung genuegen 100 ms,
fuer Kerberos sind es maximal 5 Minuten (aber nie anstreben!).

NTP und chrony

NTP ist das Protokoll; die verbreitetsten Programme sind chrony (moderne Empfehlung) und ntpd (klassisch).

# chrony installieren
apt install chrony
timedatectl                          # Ueberblick: Zeitzone, NTP-Status
timedatectl set-timezone Europe/Berlin
timedatectl set-ntp true

# /etc/chrony/chrony.conf
# Provider-Zeitserver oder oeffentliche Pools
pool 2.debian.pool.ntp.org iburst     # iburst: schnelle Erstausrichtung
server ntp1.example.org iburst
server ntp2.example.org iburst

# Erreichbarkeit einschraenken (Standard: nur lokale Netze)
allow 10.0.0.0/24

# Zeitsprunge im Betrieb vermeiden
makestep 1.0 3
#   Sprung erlaubt, wenn Abweichung > 1 s und in den ersten 3
#   Ausrichtungen. Danach wird die Zeit nur noch gestreckt
#   ("slew"), damit keine Protokolle durcheinanderkommen.

# Genauigkeit und Protokoll
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
log measurements statistics tracking

# Ueberwachung
cmdallow 127.0.0.1

Diagnose: die wichtigsten Kommandos

# Ueberblick
chronyc tracking
#   Reference ID    : der aktuell gewaehlte Server
#   Stratum         : Abstand zur Atomuhr (1 = direkt, 2 = ueber einen mehr)
#   System time     : aktuelle Abweichung (sollte im Mikrosekundenbereich sein)
#   Last offset     : Abweichung der letzten Messung
#   Root delay      : Signallaufzeit zur Referenz
#   Leap status     : Normal / Not synchronised

# Welche Server werden verwendet?
chronyc sources -v
#   M  ^*  aktuell ausgewaehlt (bester)
#      ^+  akzeptabel (Reserve)
#      ^-  ausgeschlossen
#      ^?  nicht erreichbar (Firewall? Falscher Name?)
#   S  Spalte mit dem Stratum je Server

chronyc sourcestats -v
#   Zeigt je Quelle: Anzahl Messungen, Schaetzung des Versatzes,
#   Standardabweichung. Gute Werte sind im Bereich von Millisekunden
#   oder besser mit kleiner Streuung.

# Genauigkeit messen - wichtigste Einzelmessung
chronyc tracking | grep -E 'System time|Last offset'
#   "System time: 0.000034 seconds fast of NTP time"
#   -> 34 Mikrosekunden - ausgezeichnet

# Zeit manuell setzen und sofort ausrichten (bei grosser Abweichung)
chronyc makestep
timedatectl set-time '2026-09-26 23:30:00'    # nur bei gestopptem NTP

# Hardware-Zeit (RTC) pruefen
hwclock --show
hwclock --systohc                # Systemzeit in die Hardware-Uhr schreiben

# Ist die Zeitsynchronisation ueberhaupt aktiv?
timedatectl | grep -E 'NTP|synchronized'
systemctl status chronyd
#   Bei Containern/VMs: Zeit vom Host uebernehmen, kein eigener NTP-Dienst!
#   Ausnahme: NTP im Container ist unnoetig und kann stoeren.

NTP-Server für das eigene Netz

# Ein Server holt die Zeit von aussen, alle anderen holen sie von ihm.
# Das reduziert externe Abfragen und funktioniert auch ohne Internet.

# Auf dem Zeitserver: Erreichbarkeit erlauben
# /etc/chrony/chrony.conf
allow 10.0.0.0/8
# Server, die selbst Zeit liefern, muessen synchron sein:
local stratum 10
#   -> Bei Ausfall des Internetzugangs bedient er das Netz
#      mit seiner eigenen (freilaufenden) Zeit weiter.

# Auf allen anderen Hosts: nur diesen Server fragen
server ntp1.example.org iburst
# KEINE oeffentlichen Pools, sonst sind die Uhren nicht
# einheitlich - zwei Hosts koennten unterschiedliche
# Referenzen nutzen und auseinanderdriften.

# Firewall
# nft add rule inet filter input udp dport 123 accept
#   NTP ist UDP 123. Ausgehende Abfragen zur Antwort
#   kommen von Port 123 zurueck - keine Verbindung im
#   eigentlichen Sinn, deshalb UDP-Regel beidseitig.

Prüfliste

Läuft auf jedem Server ein Zeitsynchronisationsdienst (außer in Containern)?
Verwenden alle Hosts dieselbe Referenz – oder den eigenen Zeitserver?
Ist der Zeitversatz kleiner als eine Millisekunde?
Sind die Uhren von Servern, Switches und Clients synchron (802.1X, Kerberos)?
Hat der Zeitserver einen Ausfallmodus (local stratum), damit das Netz nicht stillsteht?
Wird die Zeitsynchronisation überwacht – mit Alarm, wenn Leap status nicht Normal ist?
Ist die Hardware-Uhr richtig gestellt, damit ein Neustart nicht mit falscher Zeit beginnt?
Ist die Zeitzone überall korrekt gesetzt (Protokolle zeigen sonst schwer nachvollziehbare Zeiten)?

Häufige Fehler

Kein NTP auf dem Server. Häufig bei virtuellen Maschinen: Die Zeit des Hosts ist gut, aber die VM läuft ungepflegt davon. Ein chronyd in der VM behebt das dauerhaft.
Verschiedene Referenzen im Netz. Ein Host nutzt einen öffentlichen Pool, ein anderer einen anderen – die Uhren laufen auseinander, statt sich zu nähern.
UDP 123 blockiert. chronyc sources zeigt dann ^? und die Zeit läuft unaufhaltsam weg.
Zeit im Container. Container teilen die Zeit des Hosts im Kernel. Ein NTP-Dienst darin kann bis zu einer Sperre der Zeitänderung führen. Nur der Host soll die Zeit stellen.
Zeitsprünge ohne makestep-Steuerung. Ein Sprung mitten im Betrieb kann laufende Prozesse stören.
Keine Überwachung. Der Verlust der Zeitsynchronisation ist ein stiller Fehler – man merkt ihn erst, wenn die Anmeldung nicht mehr funktioniert.
Systemzeit und Hardware-Uhr auseinander. Nach einem Neustart beginnt das System mit der Zeit der Hardware-Uhr. Bei --systohc nicht ausgeführt, startet es falsch.
Zeitstempel als lokale Zeit ohne Zone. Protokolle und Daten sollten UTC speichern und erst bei der Anzeige umrechnen. Sonst entstehen zwei Mal im Jahr Mehrdeutigkeiten.

Verwandte Grundlagen: NTP, Zeitsynchronisation, TLS 1.3, Logging.

Netzwerk: DNS & Dienste