NTP e sincronizzazione oraria: perche' un orologio sbagliato rompe la rete

Un orologio disallineato di qualche minuto sembra un dettaglio estetico. In realta' e' una delle cause piu' sottovalutate di guasti difficili da diagnosticare: certificati TLS rifiutati, autenticazioni Kerberos e RADIUS che falliscono, log impossibili da correlare fra apparati diversi, tariffazione VoIP sbagliata, backup incrementali che ripartono da zero. NTP (Network Time Protocol) esiste per evitare tutto questo, ma va configurato con criterio.

Come funziona NTP in breve

NTP e' un protocollo UDP sulla porta 123 che stima due grandezze: l'offset (di quanto l'orologio locale e' avanti o indietro rispetto al riferimento) e il delay (il tempo di andata e ritorno del pacchetto). Con quattro timestamp — partenza dal client, arrivo al server, ripartenza dal server, arrivo al client — il client calcola la correzione da applicare, assumendo che il percorso sia simmetrico.

Quell'assunzione di simmetria e' il punto debole: se il traffico di ritorno passa da un percorso piu' congestionato di quello di andata, l'offset stimato contiene un errore pari alla meta' dell'asimmetria. Su una rete domestica o aziendale in fibra questo si traduce in errori dell'ordine dei millisecondi, del tutto irrilevanti. Su link satellitari o saturi puo' arrivare a decine di millisecondi.

Il client non applica la correzione di colpo: usa una disciplina che rallenta o accelera gradualmente il clock (slewing) invece di saltare a un altro istante (stepping). Un salto all'indietro puo' mandare in confusione database e filesystem, quindi lo stepping viene riservato agli scarti iniziali molto grandi.

Stratum: la gerarchia dei riferimenti

Gli stratum indicano la distanza dalla sorgente di tempo, non la qualita' assoluta:

• Stratum 0 — la sorgente fisica: orologio atomico, ricevitore GPS/GNSS, DCF77. Non e' raggiungibile via rete.
• Stratum 1 — un server direttamente collegato a una sorgente stratum 0.
• Stratum 2 — sincronizzato da uno o piu' stratum 1. E' il livello a cui dovrebbe attingere la maggior parte delle organizzazioni.
• Stratum 3 e oltre — a cascata, fino a stratum 15. Stratum 16 significa "non sincronizzato".

Un errore comune e' puntare direttamente ai server stratum 1 pubblici da ogni singolo dispositivo: sono risorse limitate, spesso con policy d'uso restrittive, e non offrono alcun vantaggio pratico rispetto a un buon stratum 2.

Architettura consigliata per una rete aziendale

Lo schema che funziona in quasi tutti i casi e' a due livelli:

1. Due o tre server NTP interni (router di bordo, macchine virtuali dedicate, o un appliance con ricevitore GNSS se serve precisione elevata) che si sincronizzano verso l'esterno.
2. Tutti gli altri apparati — switch, access point, PBX, telecamere IP, server, client — che puntano esclusivamente ai server interni, distribuiti via opzione DHCP 42 dove possibile.

I vantaggi sono concreti: una sola direttrice di traffico verso l'esterno da filtrare in firewall, coerenza garantita fra tutti i log interni, e possibilita' di continuare a funzionare in modo consistente anche se la connettivita' WAN cade.

Come sorgenti esterne conviene usare pool geografici (it.pool.ntp.org, europe.pool.ntp.org) oppure i server dei fornitori infrastrutturali. Sempre almeno tre sorgenti: con due, se una devia, l'algoritmo non ha modo di stabilire quale delle due mentendo; con tre o piu' puo' scartare il "falseticker" per maggioranza.

Configurazione pratica

Su Linux moderno la scelta standard e' chrony, che gestisce meglio di ntpd le connessioni intermittenti e le VM. Un /etc/chrony/chrony.conf minimale per un server interno:

# tre sorgenti esterne, con iburst per convergenza rapida all'avvio
pool it.pool.ntp.org iburst maxsources 4

# consenti l'interrogazione dalla sola LAN
allow 192.168.0.0/16

# permetti uno step iniziale se lo scarto supera 1s, solo nelle prime 3 letture
makestep 1.0 3

# mantieni la deriva stimata fra i riavvii
driftfile /var/lib/chrony/chrony.drift

Su MikroTik RouterOS il router puo' fare da client e da server contemporaneamente:

/system ntp client set enabled=yes
/system ntp client servers add address=it.pool.ntp.org
/system ntp server set enabled=yes broadcast=no
/system clock set time-zone-name=Europe/Rome

Verifica dello stato lato client:

chronyc sources -v      # elenco sorgenti, con ^* accanto a quella selezionata
chronyc tracking        # offset di sistema, deriva, stratum raggiunto

Il campo da guardare in tracking e' System time: valori sotto il millisecondo su rete locale sono normali, sopra i 100 ms indicano un problema di rete o una sorgente inaffidabile.

Errori tipici da evitare

• Firewall che blocca UDP 123 in uscita senza che nessuno se ne accorga: gli apparati restano a stratum 16 e derivano silenziosamente.
• NAT dei pacchetti NTP verso un server interno che a sua volta non e' sincronizzato: si propaga un tempo sbagliato con l'aria di essere autorevole.
• Fuso orario confuso con l'ora UTC: NTP distribuisce sempre UTC, il fuso e' una conversione locale. Impostare il fuso sbagliato su un PBX significa CDR con orari inutilizzabili.
• VM con clock hardware paravirtualizzato in conflitto con chrony: su hypervisor conviene decidere se sincronizzare via host o via NTP, non entrambi.
• Nessun monitoraggio: un check SNMP o Prometheus sull'offset di ogni apparato costa pochissimo e intercetta il problema prima che si manifesti come guasto applicativo.

Quando serve qualcosa di piu' preciso

Per la maggior parte degli scenari — server, centralini, apparati di rete, videosorveglianza — NTP con precisione al millisecondo e' abbondantemente sufficiente. Se invece si lavora con misure di latenza certificate, sincronizzazione di flussi audio/video professionali o infrastrutture finanziarie, il riferimento diventa PTP (IEEE 1588), che raggiunge il microsecondo ma richiede switch con supporto hardware al timestamping lungo tutto il percorso. E' un investimento che ha senso solo quando il requisito e' documentato: nel dubbio, NTP fatto bene risolve il novanta per cento dei problemi reali.