Assurer la cohérence NTP : configuration, problèmes de stratum et correction de la dérive

Une heure précise est une condition fondamentale dans les infrastructures IT: les jetons d’authentification expirent, les protocoles distribués exigent des ordres, les sauvegardes et la réplication reposent sur des horodatages cohérents. Dans cet article, je décris de manière pragmatique comment assurer la cohérence NTP – de la configuration correcte aux problèmes de stratum jusqu’à l’identification et la correction du drift. Le public visé comprend les administrateurs, ingénieurs systèmes, opérateurs et prestataires techniques IT ; les sections sont organisées de façon à ce que même des administrateurs moins spécialisés puissent suivre en toute sécurité.

Pourquoi synchroniser l’heure ? Pertinence opérationnelle en bref

Sans un fondement temporel fiable, des risques opérationnels concrets apparaissent : échecs de validation de certificats, périodes d’logs incohérentes lors d’analyses forensiques, problèmes avec des bases de données distribuées et séries temporelles incorrectes dans les données de monitoring. NTP (Network Time Protocol) est le protocole standard pour la synchronisation réseau. Un « Stratum » désigne la couche logique dans la hiérarchie des sources temporelles : le Stratum 0 regroupe les horloges de référence (p.ex. GPS), le Stratum 1 les serveurs directement connectés et les strata supérieurs se synchronisent indirectement.

NTP-Konzepte, die Sie kennen müssen

Avant d’aborder la configuration et le dépannage, un rappel concis des concepts pertinents :

• NTP (Network Time Protocol) : protocole de distribution de l’heure UTC sur des réseaux IP.
• chrony / ntpd / systemd‑timesyncd : implémentations/daemons fournissant la fonctionnalité NTP ; chrony est robuste en virtualisation et face à la latence, ntpd est l’implémentation classique établie, timesyncd est un client léger pour postes/serveurs avec systemd.
• Stratum : distance logique à l’horloge de référence ; un stratum inférieur est plus proche de la référence et donc plus digne de confiance.
• Drift : dérive de la fréquence d’une horloge matérielle (RTC = Real Time Clock, sur la carte mère) par rapport à l’UTC ; il est mesuré en secondes par jour et corrigé par le démon NTP.
• Peer vs Server vs Pool : un server est une source, un peer est une relation de synchronisation entre égaux, un pool référence plusieurs serveurs publics (p.ex. pool.ntp.org) pour la redondance.

NTP-Konsistenz sicherstellen: Grundregeln und Architektur

La route vers une cohérence NTP stable est guidée par l’architecture : vous avez besoin de sources temporelles fiables, de redondance, d’un logiciel fiable et de chemins réseau sans perte de paquets. Règles de base concrètes :

• Prévoyez au minimum trois sources temporelles indépendantes par site, idéalement issues de réseaux/AS différents pour éviter les erreurs communes.
• Pour les serveurs en environnements virtualisés, préférez chrony, car il compense mieux le drift dans les VMs.
• Segmentez les serveurs temporels en une hiérarchie : Stratum‑1/2 internes pour les clients locaux ; les références externes ne doivent servir que de backstop ou pour la comparaison inter‑DC.
• Sécurisez les chemins réseau : NTP utilise UDP/port 123 ; les firewalls, NAT et load balancers doivent laisser passer ce trafic de manière régulière et fiable.

Pourquoi trois Quellen minimum?

Les algorithmes de sélection de la meilleure source temporelle (consensus) nécessitent plusieurs candidats pour détecter les valeurs aberrantes. Avec seulement deux serveurs et un équipement défaillant, il existe un risque de split‑brain dans le choix de l’heure.

Häufige Ursachen für NTP‑Inkon­sistenzen

Dans la pratique, certains motifs d’erreur se répètent. Voici les causes les plus fréquentes et leur mode d’action :

• Firewall-/ACL‑Blockage: UDP/123 est filtré ou l’inspection stateful met fin au mapping NAT, de sorte que les réponses n’arrivent pas. Conséquence : les clients ne voient que des requêtes unilatérales ou des timeouts.
• Asymmetrisches Routing: Les paquets vers un serveur empruntent un chemin différent au retour, les Load Balancers modifient l’IP source ou le port – l’authenticité et le matching des réponses échouent.
• Falsche Stratum‑Konfiguration: Un serveur a été déclaré à tort comme Stratum‑1 (p. ex. par réglage manuel) et est privilégié, alors que sa référence est peu fiable.
• Hardware‑RTC‑Drift: De vieilles cartes ou des horloges bon marché dérivent fortement ; les machines virtuelles partagent l’horloge de l’hôte ou disposent de générateurs d’horloge instables.
• Leap second / Zeitsprung‑Behandlung: Différents démons implémentent les secondes intercalaires différemment, ce qui peut entraîner de courtes incohérences.

Prüfung: Erste Diagnoseschritte (Linux und Windows)

Commencez par des vérifications simples : le service est‑il actif, quels serveurs sont utilisés, et quelle est l’ampleur de l’écart actuel ?

Linux: chrony

chrony fournit des sorties d’état claires. chrony est souvent le premier choix pour les VM et les réseaux instables.

# Status der Quellen anzeigen
chronyc sources --verbose

# Allgemeiner Status und Abweichung
chronyc tracking

Les champs importants sont Offset (écart actuel par rapport à la référence en secondes) et Stratum. Un Offset de l’ordre de millisecondes est normal, des secondes sont critiques.

Linux: ntpd

# Synchronisationsquellen anzeigen
ntpq -p

# Status (Scriptfreundlich)
ntpstat || true

Avec ntpq -p, faites attention au caractère en début de ligne : un astérisque (*) marque le serveur actuellement utilisé, un plus (+) d’autres sources acceptées. Un moins (-) indique des sources rejetées.

Windows

Windows utilise w32time ; pour des contrôles plus détaillés, PowerShell est recommandé.

# Anzeigen des NTP-Status
w32tm /query /status

# Konfigurierte Zeitquelle
w32tm /query /configuration

Windows affiche l’Offset et l’intervalle de sondage ; des écarts supérieurs à 1 seconde sont critiques dans les environnements de domaine, car Kerberos gère strictement les écarts temporels.

Firewall und Netzwerk: typische Stolperfallen und Prüfungen

En tant que catégorie « pare‑feu », cela est particulièrement pertinent : NTP utilise UDP/123. Les pare‑feu stateful et le NAT peuvent affecter le trafic. Vérifiez :

• Le trafic sortant UDP/123 est‑il autorisé et le trafic retour est‑il à nouveau accessible via le pare‑feu/les ACL ?
• Un Load Balancer modifie‑t‑il l’IP source ou le port ? NTP attend des combinaisons source/port cohérentes pour les réponses.
• Existe‑t‑il une inspection approfondie des paquets (DPI) ou des timeouts de session UDP qui ferment prématurément les sessions NTP ?

Le diagnostic réseau avec tcpdump/wireshark aide à démontrer un routage asymétrique ou des réponses rejetées :

# Auf dem Client: Pakete zu Server x.y.z.w beobachten
sudo tcpdump -n -i any host x.y.z.w and port 123 -vv

Recherchez des paquets de requête sans réponses correspondantes ou des messages ICMP « port unreachable ».

Firewall‑Praxis: Regeln, NAT, Conntrack und Timeouts

Dans les environnements de production, ce sont souvent les réglages du pare‑feu ou du NAT qui constituent le goulot d’étranglement. Voici des vérifications et règles concrètes qui aident :

• Autorisez le trafic sortant UDP/123 depuis les sous‑réseaux clients vers des serveurs de temps définis et autorisez le trafic retour sur des ports source dynamiques.
• Vérifiez le comportement NAT : un NAT/passerelle qui modifie le port source perturbe l’association des réponses aux requêtes ouvertes.
• Contrôlez les timeouts conntrack pour UDP : des timeouts trop courts (p. ex. < 30s) peuvent rejeter des réponses si les intervalles de sondage sont plus longs.

Exemple : règles nftables simples autorisant les requêtes NTP sortantes et n’autorisant le trafic de retour que pour les sessions établies :

# nftables Beispiel (IPv4)
table inet filter {
    chain output {
        type filter hook output priority 0;
        ip daddr ntp-server.example accept
        udp dport 123 accept
        # Default: REST blocken
    }

    chain input {
        type filter hook input priority 0;
        ct state established,related udp dport 123 accept
        # Weitere Regeln...
    }
}

De même avec iptables (Legacy) pour les firewalls sans support nftables :

# iptables Beispiel
iptables -A OUTPUT -p udp --dport 123 -d ntp-server.example -j ACCEPT
iptables -A INPUT -p udp --sport 123 -m conntrack --ctstate ESTABLISHED -j ACCEPT

L’inspection conntrack aide à vérifier les timeouts d’exécution :

# Conntrack Einträge filtern
sudo conntrack -L | grep udp | grep 123

# Sysctl: UDP conntrack Timeout (Beispiel lesen)
sysctl net.netfilter.nf_conntrack_udp_timeout

Si vous déployez des équilibreurs de charge, assurez la persistance de session (IP source ou 5‑tuple) ou contournez le LB pour le trafic NTP via des routes statiques ou des exceptions NAT.

Problèmes de stratum : détection et résolution

Un stratum incorrect ou un serveur dont la référence est instable entraîne de nombreux clients à adopter la même heure erronée :

• Vérifiez si les serveurs maîtres internes sont effectivement liés à une source Stratum‑0/1 (p. ex. GPS, PPS). À défaut, ils doivent être configurés en Stratum‑2.
• Évitez de diminuer manuellement la valeur de stratum : cela manipule la logique de confiance du protocole et conduit à de mauvaises décisions côté client.

Si un serveur interne est instable, vous devriez :

1. Retirer temporairement ce serveur de la liste de pool/serveurs de tous les clients.
2. Reproduisez le problème dans un environnement de test isolé afin d’exclure une erreur de configuration.
3. Remplacez ou réparez la source de référence (p. ex. antenne GPS, entrée PPS série).

Analyse de dérive : matériel vs virtualisation

La dérive provient des propriétés physiques de l’oscillateur à quartz d’une RTC ou des timers virtuels. Règles pratiques :

• Sur du bare‑metal, mesurez la dérive de la RTC et appliquez une correction dans la configuration du démon ; chrony apprend la dérive dynamiquement et stocke le taux.
• Dans les VM, les timers du système invité ne devraient pas se reposer uniquement sur la RTC virtuelle ; la synchronisation avec l’hyperviseur est souvent utile, mais sur le long terme chrony est plus résilient.

Un exemple : chrony enregistre les valeurs de dérive dans un fichier (p. ex. /var/lib/chrony/chrony.drift). Vous pouvez afficher la dérive actuelle :

# chrony zeigt Learnings und Rate an
chronyc tracking

# Drift-Datei lesen (Pfad kann variieren)
sudo cat /var/lib/chrony/chrony.drift

Des valeurs de dérive extrêmement élevées indiquent des défaillances matérielles ou une alimentation/variations de température très mauvaises.

Runbook pratique : dépannage étape par étape

Ce runbook est destiné à un site type avec des serveurs de temps internes et des clients.

1. Vérifier la ligne de base : état du service, offsets actuels, sources configurées.
   ShellCode kopieren

   # Exemples de commandes pour Linux (chrony)
   systemctl status chronyd --no-pager
   chronyc sources --verbose
   chronyc tracking

2. Vérifier le réseau: tcpdump depuis le client, logs du pare-feu, configuration NAT/LoadBalancer.
   ShellCode kopieren

   sudo tcpdump -n -i any host ntpserver.example.net and port 123 -vv
   # Vérifier sur le pare-feu : y a-t-il des refus UDP/123 pour les clients ?
   # Exemple : logs iptables ou logs du pare-feu central

3. Vérifier l’état du serveur: charge CPU, I/O, statut GPS/PPS (si disponible).
   ShellCode kopieren

   # Outils GPS/PPS (exemple pour Linux avec gpsd/ppsd)
   # Vérifier le statut
   sudo systemctl status gpsd
   # Vérifier les signaux PPS sous /dev/pps0 (selon le système)

4. Vérifier le stratum: sorties ntpq/chronyc ; retirer temporairement les serveurs des clients si le stratum est incorrect.
5. Renforcer la configuration: ACL RESTrictives, authentification (clés symétriques ou Autokey, mais attention à la complexité) et ajuster les intervalles de sondage.
6. Monitoring/Alerting: Intégrer les métriques d’offset, de stratum et de reachability dans votre monitoring.
7. Plan de rollback: avant modifications, snapshot (VM) ou sauvegarde de configuration ; si les nouvelles règles aggravent les problèmes, revenir immédiatement en arrière et poursuivre le triage.

Exemples de configuration et bonnes pratiques

Extraits de configuration concrets et éprouvés pour chrony et ntpd. Adaptez les chemins et les serveurs à votre environnement.

chrony (recommandé pour les VM et les réseaux instables)

# /etc/chrony/chrony.conf (Extrait)
# Serveurs de temps internes fiables
server ntp1.internal.example iburst
server ntp2.internal.example iburst
# Serveurs externes de secours
pool 2.pool.ntp.org iburst

# Fichier de dérive
driftfile /var/lib/chrony/chrony.drift

# Droits d'accès : n'autoriser que les clients du réseau 10.0.0.0/24
allow 10.0.0.0/24

# Fichier de log pour dépannage
log tracking measurements statistics
logdir /var/log/chrony

Explication des paramètres : iburst permet une synchronisation initiale plus rapide ; allow limite l’accès des clients ; driftfile enregistre le taux de dérive appris.

ntpd (classique)

# /etc/ntp.conf (extrait)
server ntp1.internal.example iburst
server ntp2.internal.example iburst
driftfile /var/lib/ntp/ntp.drift
RESTrict default ignore
RESTrict 127.0.0.1
RESTrict 10.0.0.0 mask 255.255.255.0 nomodify notrap
broadcast 10.0.0.255
logfile /var/log/ntp.log

Important : des lignes RESTrict RESTrictives empêchent les clients de modifier la configuration ou d’injecter des données incorrectes.

Monitoring : métriques, alertes et intégration

Un bon monitoring détecte tôt la dérive progressive et les pannes réseau. Points importants :

• Collectez l’offset, le stratum et la reachability en séries temporelles (p. ex. via chrony‑Exporter pour Prometheus ou via un script dans node_exporter textfile).
• Définissez des alertes pertinentes : avertissement pour un offset > 100 ms, critique pour > 1 s ou si la reachability vers toutes les sources internes tombe.
• Visualisez les tendances de dérive sur plusieurs jours ; des sauts soudains indiquent des événements externes (snapshots, migrations d’hôtes).

Exemple d’une Prometheus‑AlertRule (YAML) :

# règle d'alerte Prometheus : offset NTP critique
groups:
- name: ntp.rules
  rules:
  - alert: NTPOffsetHigh
    expr: ntp_offset_seconds{job="chrony"} > 1
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Offset NTP supérieur à 1s sur {{ $labels.instance }}"

Windows Domaine et Kerberos : attention particulière

Dans les environnements Active Directory, la sensibilité au temps est élevée : Kerberos n’accepte souvent qu’une tolérance de quelques minutes. Les contrôleurs de domaine (DC) devraient utiliser les mêmes serveurs de temps internes et ne pas se synchroniser de manière autonome sur des serveurs publics. Mesures immédiates recommandées en cas de dérive d’un DC :

# Auf dem DC: Zeitquelle prüfen
w32tm /query /status

# Sofortige Resynchronisation erzwingen
w32tm /resync /nowait

# Konfiguration prüfen
w32tm /query /configuration

Documentez chaque étape et appliquez les modifications d’abord sur un RODC ou un DC de test, avant d’ajuster plusieurs contrôleurs de domaine.

Automatisation : déployer les modifications de manière contrôlée

Utilisez un gestionnaire de configuration pour garantir la cohérence et permettre des retours en arrière. Exemple : tâche Ansible qui déploie la configuration de chrony et redémarre le service (idempotente) :

- name: Deploy chrony config and RESTart
  hosts: ntp_clients
  become: yes
  tasks:
    - name: Upload chrony.conf
      copy:
        src: files/chrony.conf
        dest: /etc/chrony/chrony.conf
        owner: root
        group: root
        mode: '0644'
      notify: RESTart chrony

  handlers:
    - name: RESTart chrony
      systemd:
        name: chronyd
        state: RESTarted
        enabled: yes

Testez en „check mode“ et effectuez un déploiement canari sur un petit groupe d’hôtes avant de propager les modifications globalement.

Sécurité : NTP authentifié et durcissement

Le NTP authentifié réduit le risque de manipulation du signal horaire. Les options sont NTP‑symmetric keys ou Autokey (plus complexe). À noter :

• Gestion des clés : utilisez des outils CM pour une distribution sécurisée, évitez les configurations en clair dans des dépôts non protégés.
• RESTreignez qui peut interroger votre serveur (ACLs dans chrony/ntpd) pour réduire les abus.
• Vérifiez régulièrement les journaux ; des écarts inhabituels ou de nouvelles sources peuvent indiquer une manipulation.

Mesures d’urgence avancées

Si la référence temporelle semble complètement perdue (p. ex. toutes les sources internes tombent), procédez étape par étape :

1. Basculez les clients vers des serveurs pool externes connus, si les règles réseau le permettent, mais uniquement comme mesure temporaire.
2. Isolez les serveurs concernés s’ils propagent des horaires incohérents.
3. Utilisez le stepping manuel (contrôlé uniquement) pour corriger des écarts très importants. Avec chrony :
ShellCode kopieren

# Sofortiges Steppen der Zeit (vorsichtig einsetzen)
chronyc makestep

4. Vérifiez la tolérance des applications aux divergences temporelles (p. ex. réplication de bases de données, tâches de renouvellement de certificats) et prévoyez si nécessaire des replays ou des réconciliations.

Liste de contrôle : cohérence NTP en un coup d’œil

• Le service (chrony/ntpd) fonctionne sur tous les hôtes concernés.
• Au moins trois sources temporelles indépendantes configurées par site.
• Le port UDP/123 est ouvert pour les clients ; les pare-feux autorisent le trafic de retour.
• Aucun réglage manuel du stratum ; laisser le stratum déterminé par les références.
• Surveillez les valeurs de dérive et recherchez toute augmentation anormale.
• Monitoring configuré avec alertes sur les offsets.
• Plan de rollback et sauvegardes de configuration en place.

Exemples pratiques : écueils typiques

Quelques scénarios d’erreurs réels que vous retrouverez rapidement et comment les résoudre :

• Problème : Les clients indiquent une bonne Reachability, mais l’Offset RESTe important.

Cause : Les pare‑feu autorisent les requêtes, mais bloquent les gros paquets de réponse UDP (fragmentation) ou définissent des timeouts NAT trop courts.

Mesure : Augmenter les timeouts du pare‑feu, vérifier la fragmentation UDP et tester NTP via IPv4/UDP. Alternative : ne pas utiliser NTP sur TCP par défaut ; vérifier plutôt, uniquement si nécessaire, des protocoles temporels liés à TLS (p. ex. Roughtime).

• Problème : Les hôtes VM présentent ponctuellement des sauts de plusieurs secondes.

  Cause : Les migrations d’hôte, les pauses CPU ou les snapshots provoquent des pics temporels.

  Mesure : Configurer chrony (préférer Slew plutôt que Step pour une correction plus progressive), vérifier l’horloge de l’hyperviseur et adapter la tolérance des horodatages au niveau applicatif.

Conclusion : l’infrastructure temporelle en tant que composant opérationnel stable

Assurer la cohérence NTP n’est pas une tâche ponctuelle, mais un sujet opérationnel : architecture, réseau, choix du démon, monitoring et une stratégie de rollback claire sont nécessaires. Surveillez en particulier les politiques de pare‑feu, la configuration de stratum et les métriques de dérive — ce sont les trois leviers qui permettent de résoudre durablement la plupart des problèmes. Si vous appliquez systématiquement les parcours de vérification proposés, les règles de pare‑feu, les alertes de monitoring et les workflows d’automatisation, vous réduirez les incohérences, améliorerez la stabilité de l’authentification et faciliterez nettement les analyses forensiques.

La dérive NTP est également importante dans ce contexte. Le présent article met ces aspects en perspective de manière claire et indique ce qui compte au quotidien.