Waarom een nauwkeurige servertijd belangrijk is (de basis van NTP)

Waarom klokken afdrijven

De hardwareklok van een server is niet perfect nauwkeurig. Door normale variatie in de oscillator loopt hij een fractie te snel of te langzaam, en die kleine afwijking stapelt zich op na verloop van tijd. Blijft de klok ongecorrigeerd, dan kan hij dagen of weken na de laatste synchronisatie seconden of meer afdrijven, en nog meer als de hardwareklok bijzonder onnauwkeurig is of de server al lang draait zonder sync. Die afwijking valt dag in dag uit niet op, totdat iets dat van een nauwkeurige tijd afhankelijk is begint te falen op een manier die op het eerste gezicht niets met de klok te maken lijkt te hebben.

NTP lost dit op door de klok van een server periodiek te vergelijken met externe referentietijdbronnen en die weer bij te sturen. Waar mogelijk gebeurt dat geleidelijk in plaats van met een abrupte sprong, zodat gewone tijdgebonden processen niet halverwege worden verstoord.

Wat er daadwerkelijk misgaat als de klok afdrijft

• TLS/SSL-certificaatvalidatie. Elk certificaat heeft een geldigheidsperiode met een begin- en einddatum. Loopt de klok van een client ver genoeg uit de pas, dan kan een werkelijk geldig certificaat verlopen lijken, of nog niet geldig, en mislukt de verbinding terwijl er in werkelijkheid niets mis is met het certificaat zelf. Zie Hoe SSL/TLS-certificaten werken voor hoe die geldigheidsperiode wordt gecontroleerd.
• Tijdgebonden authenticatietokens. Sommige SSH- en Kerberos-achtige authenticatieschema's, en schema's voor het ondertekenen van API-requests, werken met een token of handtekening die maar kort geldig is. Wijken de klok van client en server meer af dan dat venster toelaat, dan worden geldige requests geweigerd alsof ze verlopen of vervalst zijn.
• Cronjobs die op het verkeerde moment starten. Een geplande taak wordt getriggerd op basis van de systeemklok, niet op basis van een externe notie van de juiste tijd. Een afgedreven klok betekent dat de taak te vroeg, te laat, of in de verkeerde volgorde ten opzichte van taken op andere servers draait.
• Logcorrelatie tussen servers. Bij een incident dat meerdere servers raakt, hangt het achterhalen van de werkelijke volgorde van gebeurtenissen af van tijdstempels die met elkaar overeenkomen. Is de klok van elke server onafhankelijk afgedreven, dan wordt het reconstrueren van wat er gebeurde, en in welke volgorde, juist een stuk lastiger op het moment dat nauwkeurigheid het hardst nodig is.

Wat klokdrift bijzonder lastig maakt om te diagnosticeren, is dat geen van deze storingen duidelijk naar de klok wijst. Een certificaatfout lijkt een certificaatprobleem, een geweigerde API-request lijkt een authenticatiebug, en een cronjob die op het verkeerde moment draait lijkt een planningsfout. Controleer de systeemklok vroeg in het proces als een storing anders niet te verklaren is, niet pas als laatste redmiddel.

Een NTP-client draaien

De praktische oplossing is simpel: draai een NTP-client die de systeemklok op de achtergrond gesynchroniseerd houdt, in plaats van te vertrouwen op wat de hardwareklok toevallig aangeeft. Moderne Linux-distributies leveren doorgaans standaard een van deze twee opties mee:

• chrony. Een volwaardige NTP-client die geschikt is voor servers, ook servers die af en toe verbinding hebben of in een gevirtualiseerde omgeving draaien.
• systemd-timesyncd. Een lichtgewicht client die met systemd wordt meegeleverd, voldoende voor eenvoudige tijdsynchronisatie zonder de uitgebreidere functies van chrony.

Beide zijn een goede standaardkeuze voor een server. Belangrijker dan welke client je kiest, is dat er daadwerkelijk één draait en synchroniseert. Controleer actief of de sync werkt in plaats van dat aan te nemen: een dienst die geïnstalleerd is maar niet draait, biedt helemaal geen bescherming tegen afdrijven.