chrony als NTP-Server für ein LAN betreiben: allow, local stratum und UDP 123 in der Firewall

Ziel

chrony so konfigurieren, dass es anderen Hosts in einem lokalen Netz die Zeit bereitstellt; entscheiden, ob es sich ohne externe Quelle überhaupt als autoritativ ausgeben soll; beides auf der Kommandozeile überprüfen.

Voraussetzungen

chrony ist installiert und synchronisiert bereits mit Upstream-Quellen. Root-Zugriff ist vorhanden, um /etc/chrony.conf (unter Debian und Ubuntu /etc/chrony/chrony.conf) zu bearbeiten und den Dienst neu zu starten.

Schritte

1. Eine allow-Zeile für das Subnetz ergänzen, das bedient werden soll, zum Beispiel allow 10.0.0.0/24. Die Direktive legt ein bestimmtes Subnetz fest, aus dem NTP-Clients auf den Rechner als NTP-Server zugreifen dürfen. Ohne sie ist standardmässig kein Client-Zugriff erlaubt.
2. chronyd neu starten, damit die neue allow-Direktive wirksam wird (systemctl restart chronyd; unter Debian und Ubuntu heisst die Unit chrony). chronyd kennt kein Neuladen der Konfiguration. chronyc allow 10.0.0.0/24 wendet dieselbe Regel zur Laufzeit ohne Neustart an, sie geht aber beim nächsten Neustart verloren, wenn sie nicht auch in der Datei steht.
3. Eine local stratum <n>-Direktive nur dann ergänzen, wenn dieser Server auch dann als synchronisiert erscheinen soll, wenn er keine Upstream-Quelle hat oder sie verloren hat – typischerweise in einem isolierten Netz. Die Option legt das Stratum fest, das Clients gemeldet wird, solange die lokale Referenz aktiv ist (Standard 10; höher wählen als jedes reale Stratum im Netz). Mehrere solcher Server sollten alle local stratum <n> orphan verwenden und sich gegenseitig abfragen, damit sie sich auf einen von ihnen einigen und die Clients nicht verwirren. Auf einem Server, der ansonsten die reale Zeit verfolgen soll, ist die Direktive nicht zu setzen, da sie einen tatsächlichen Ausfall der Upstream-Synchronisation gegenüber nachgelagerten Clients verdecken kann.
4. In der Firewall UDP-Port 123 eingehend aus dem bedienten Subnetz öffnen. Der Kommando- und Monitoring-Port von chrony ist davon getrennt und sollte auf localhost oder explizit per cmdallow freigegebene Hosts beschränkt bleiben.
5. Prüfen, ob Clients den Server tatsächlich nutzen: chronyc clients (als root ausführen) zeigt eine Liste der Clients, die über den NTP-, den Kommando- oder den NTS-KE-Port auf den Server zugegriffen haben, samt Anzahl der Anfragen pro Client.
6. Für Clients in einem nicht vertrauenswürdigen Netz statt eines vorab geteilten symmetrischen Schlüssels pro Client Network Time Security (NTS, chrony 4.0 und neuer) in Betracht ziehen: ntsservercert und ntsserverkey auf ein von chronyd lesbares PEM-Zertifikat und einen ebensolchen Schlüssel verweisen lassen, zusätzlich zu UDP 123 den TCP-Port 4460 (NTS-KE) öffnen und die Option nts in den server-Zeilen der Clients ergänzen.

Erwartetes Ergebnis

chronyc clients listet die LAN-Hosts auf, die den Server abfragen. Die eigene Tracking-Ausgabe eines Clients zeigt diesen Host als Quelle. Anfragen von ausserhalb des erlaubten Subnetzes bleiben ohne Antwort.

Grenzen und Prüfbasis

allow ohne Subnetz-Argument oder allow all öffnet den Dienst für alles, was die Firewall durchlässt – den Zugriff daher explizit eingrenzen. Ein local-Stratum lässt den Server für nachgelagerte Clients auch bei einem echten Ausfall der Upstream-Quellen als synchronisiert erscheinen; es ist nur dort einzusetzen, wo dieser Kompromiss beabsichtigt ist. Bei einem Neustart bleibt die Drift-Datei erhalten, sodass sich die Uhr schnell erholt; dennoch ist mit chronyc clients zu prüfen, statt anzunehmen, dass der Neustart allein erfolgreich war.