De klok van de router klopt niet | MikroTik Configurator

De klok staat op 1 januari 1970, of op vorige week, of een uur naast de rest. Meestal valt het pas op via iets anders: een browser die klaagt over een certificaat, een backup die om drie uur zou draaien en dat niet deed, of een logboek waarin de gebeurtenissen niet in de volgorde staan waarin ze gebeurden.

Wat het niet is: een MikroTik die na een stroomstoring even op een rare datum staat, is niet kapot. De meeste RouterBOARDs hebben geen batterij achter de klok. Ze starten op een vaste datum en wachten tot NTP ze bijwerkt. Het probleem begint pas als dat bijwerken niet gebeurt, of pas na een paar minuten waarin de router al van alles heeft gedaan.

Drie dingen breken hier meteen van. Certificaten hebben een geldigheidsvenster met een begin en een eind, en iets dat buiten dat venster wordt aangeboden of aangemaakt is ongeldig. Logregels krijgen een tijdstempel, en een verkeerde tijdstempel maakt een logboek waardeloos op het moment dat je het nodig hebt. En de planner rekent met dagen en uren: een taak om 03:30 draait niet als de router denkt dat het 1970 is.

De snelle controles, op volgorde

Wat denkt de router zelf? /system clock print. Goed antwoord: de juiste datum, de juiste tijd, time-zone-name op jouw zone en time-zone-autodetect: no. Staat er een datum uit een ander decennium, dan is er nooit gesynchroniseerd.
Heeft NTP gewerkt? /system ntp client print. Goed antwoord: enabled: yes, status: synchronized en een last-update-from met een adres erin. Staat er failed of stopped, dan kom je er niet uit.
Komt hij bij de tijdserver? /ping nl.pool.ntp.org count=3. Goed antwoord: antwoorden. Geen antwoord met een foutmelding over de naam betekent dat DNS het probleem is, niet NTP.
Lost hij de naam op? :put [:resolve nl.pool.ntp.org]. Goed antwoord: een IP-adres. Een fout hier is de echte oorzaak, zie DNS lost niets op.
Welke certificaten zijn er, en vanaf wanneer? /certificate print detail. Goed antwoord: invalid-before ligt in het verleden en invalid-after ver in de toekomst. Staat invalid-before op een datum uit 1970 of 2015, dan is dat certificaat gemaakt terwijl de klok fout stond.

De gewone oorzaken, meest voorkomend eerst

DNS werkt niet, dus NTP ook niet

NTP-servers staan meestal als naam ingevuld, niet als adres. Kan de router die naam niet opzoeken, dan vindt hij geen tijdserver. Dit is de vaakst voorkomende oorzaak en hij is verraderlijk, want alles wijst naar de klok terwijl het probleem bij DNS zit. Er zit ook een kip-en-ei in: gebruik je DNS over HTTPS met certificaatcontrole, dan heeft die controle een kloppende klok nodig, en de klok heeft DNS nodig. Zet in dat geval tijdelijk een IP-adres als NTP-server, bijvoorbeeld een van de adressen achter je pool.

De NTP-client staat uit

Een router die met de hand is ingericht heeft dit vaak niet aanstaan. Zet hem aan met /system ntp client set enabled=yes mode=unicast servers=....

De tijdzone klopt niet, of autodetect raadt verkeerd

Een uur verschil met de rest is bijna altijd de zone of de zomertijd. RouterOS kan de zone automatisch bepalen aan de hand van je publieke adres, en dat raadt bij een provider met een buitenlandse route verkeerd. Zet de zone met de hand en zet autodetect uit.

Het certificaat is gemaakt toen de klok nog fout stond

Een zelfondertekend certificaat krijgt zijn begindatum op het moment dat het wordt ondertekend. Gebeurt dat een seconde nadat de router is opgestart en voordat NTP heeft toegeslagen, dan staat er een begindatum in die nergens op slaat. Browsers kunnen daar heel verschillend op reageren. De oplossing is niet de klok maar het certificaat: verwijder het en maak het opnieuw aan als de tijd klopt. Zie Certificaatwaarschuwing.

Wat de configurator hiervan doet

Het onderdeel Systeem staat altijd aan, en daar staan Tijdzone en NTP-client. De NTP-client staat standaard aan, met nl.pool.ntp.org,time.cloudflare.com als servers. Je kunt daar zelf adressen of namen neerzetten.
Het script schrijft /system clock set time-zone-name=... time-zone-autodetect=no. Dat no is een keuze: de zone die jij kiest blijft staan, ook als het publieke adres verhuist of de provider ergens anders uitkomt.
De klokregels staan in het script vóór de regels die certificaten maken. Dat helpt, maar het is geen garantie: NTP is niet klaar op het moment dat de volgende regel wordt uitgevoerd. Plak je een script op een apparaat dat net is aangezet, kijk dan na afloop met /system clock print of de tijd klopt, en maak het certificaat desnoods opnieuw.
In Beheertoegang staat onder IP Cloud de schakelaar Tijd via IP Cloud bijwerken. Dat is een tweede weg naar een kloppende klok, los van jouw NTP-servers. Handig op een apparaat waar je de tijd niet vertrouwt, en hij staat standaard uit.
Wat de tool niet doet: hij controleert niet of de klok van het apparaat klopt op het moment dat je plakt. Dat kan hij ook niet weten, want de browser praat niet met je router.

Alles wat daarna op tijd leunt, komt uit dezelfde hoek. De wekelijkse backup uit Diensten & tools draait om 03:30, de automatische update uit Systeem op zondag om 04:00, en eigen scripts op de starttijd die je invult. Een router die denkt dat het 1970 is, draait die niet of draait ze allemaal tegelijk bij de eerste synchronisatie.

Als het niet aan je router ligt

De provider. Sommige netwerken sturen NTP naar hun eigen server en die kan ernaast zitten. Vul dan expliciet een publieke pool in.
Je eigen tijdserver. Draai je NTP op een server in het LAN, controleer dan eerst of die zelf gesynchroniseerd is; een niet-gesynchroniseerde server verdeelt zijn eigen fout.
Het apparaat dat klaagt. Staat de klok van de router goed en die van de laptop een dag fout, dan geeft dat hetzelfde certificaatverhaal. Controleer beide kanten.

Verder lezen: Systeem en tijd, Certificaten en Logging.