Proxmox VE et NTP

La synchronisation NTP (Network Time Protocol) sur un hyperviseur Proxmox VE n'est pas un réglage cosmétique : c'est un prérequis de stabilité et de sécurité. Un hôte dont l'horloge dérive de quelques dizaines de millisecondes suffit à dégrader un cluster Ceph ; quelques minutes de décalage suffisent à casser une authentification Kerberos ou à invalider un certificat TLS. Cette fiche détaille la configuration, les spécificités des machines virtuelles et le dépannage sur un cluster multi-nœuds.

Pourquoi le temps synchronisé est critique

Trois domaines rendent la dérive d'horloge immédiatement visible :

• Kerberos et Active Directory : le protocole tolère par défaut un décalage de 5 minutes (clock skew) entre client, serveur et KDC. Au-delà, l'émission de ticket échoue avec KRB5KRB_AP_ERR_SKEW. Une VM hébergeant un contrôleur de domaine sur un hôte désynchronisé rend l'ensemble du domaine inutilisable.
• Certificats et TLS : les champs notBefore / notAfter sont évalués contre l'horloge locale. Un hôte en avance rejette un certificat pourtant valide ; un hôte en retard accepte un certificat révoqué. Proxmox VE génère lui-même ses certificats de cluster et son API refuse les connexions dont la validation temporelle échoue.
• Réplication Ceph : les moniteurs Ceph appliquent un seuil mon_clock_drift_allowed fixé à 50 ms par défaut. Au-delà, le cluster passe en HEALTH_WARN avec le message clock skew detected on mon.X, et le quorum peut devenir instable. Sur un cluster hyperconvergé Proxmox + Ceph, NTP n'est donc pas optionnel.

S'y ajoutent les enjeux de conformité : une corrélation d'événements dans un SIEM, une investigation forensique ou une preuve d'audit ISO 27001 perdent toute valeur si les horodatages des journaux ne sont pas cohérents entre équipements.

chrony ou systemd-timesyncd

Depuis Proxmox VE 7, le démon installé par défaut est chrony, qui a remplacé systemd-timesyncd utilisé jusqu'en PVE 6. Cette bascule est justifiée :

• systemd-timesyncd est un simple client SNTP : il interroge un serveur à la fois, ne fait aucune discipline fine de l'horloge et ne peut pas servir de serveur NTP.
• chrony implémente NTPv4 complet, sélectionne le meilleur serveur parmi plusieurs sources, corrige la dérive du quartz local (fichier driftfile), converge très rapidement après un redémarrage et supporte NTS (Network Time Security, chiffrement de la synchronisation).

Les deux services sont mutuellement exclusifs. Si vous installez chrony manuellement, désactivez explicitement l'autre :

• apt install chrony
• systemctl disable --now systemd-timesyncd

La configuration se trouve dans /etc/chrony/chrony.conf. Une base saine consiste à remplacer les pools publics par vos serveurs internes, en conservant au moins trois sources pour permettre l'élimination d'un serveur défaillant :

• server ntp1.interne.lan iburst
• server ntp2.interne.lan iburst
• pool 2.debian.pool.ntp.org iburst (secours)
• makestep 1.0 3 — autorise un saut d'horloge brutal lors des 3 premières mises à jour, puis passe en correction progressive.

L'option iburst envoie une rafale de paquets au démarrage et réduit le temps de convergence de plusieurs minutes à quelques secondes. Le trafic NTP utilise UDP/123 : vérifiez que le pare-feu Proxmox et les équipements réseau l'autorisent en sortie.

NTP dans les VMs et les conteneurs

La règle diffère selon le type de charge :

• Conteneurs LXC : ils partagent le noyau de l'hôte et n'ont donc aucune horloge propre. Toute tentative d'exécuter un démon NTP dans un conteneur échoue (capacité CAP_SYS_TIME refusée). Il ne faut pas en installer : synchroniser l'hôte suffit.
• VMs KVM : elles disposent d'une horloge indépendante. Proxmox expose par défaut la source paravirtualisée kvm-clock, qui suit l'hôte et absorbe correctement les suspensions et migrations à chaud. Malgré cela, installez un client NTP dans chaque VM Linux — il corrige les dérives résiduelles et garantit l'indépendance vis-à-vis d'un hôte mal configuré. Vérifiez la source active avec cat /sys/devices/system/clocksource/clocksource0/current_clocksource.
• VMs Windows : contrôlez l'option Use local time for RTC dans les options de la VM. Windows attend par défaut une horloge matérielle en heure locale, Linux en UTC ; une incohérence provoque un décalage systématique correspondant au fuseau. Le service w32time doit ensuite pointer vers votre serveur interne (ou vers le PDC émulateur dans un domaine AD).

Cluster multi-nœuds

Sur un cluster Proxmox, tous les nœuds doivent interroger les mêmes sources NTP. Utiliser des pools géographiques différents par nœud introduit des écarts de plusieurs dizaines de millisecondes — exactement le seuil critique pour Ceph. La configuration chrony.conf doit donc être identique partout, idéalement déployée par Ansible ou par un script poussé via pvesh. Corosync tolère mieux la dérive que Ceph (il repose sur des jetons et non sur des horodatages absolus), mais des journaux incohérents entre nœuds rendent tout diagnostic de split-brain impossible.

Dépannage

Les commandes essentielles :

• timedatectl status — vérifie le fuseau, l'état System clock synchronized: yes et le service NTP actif.
• chronyc tracking — affiche la source de référence, le stratum atteint, l'écart système (System time) et la dérive résiduelle.
• chronyc sources -v — liste les serveurs ; le caractère ^* désigne la source sélectionnée, ^+ une source acceptable, ^? une source injoignable.
• chronyc sourcestats — qualité statistique de chaque source (utile pour identifier un serveur instable).
• journalctl -u chrony -b — journal du démon depuis le dernier démarrage ; on y lit les System clock wrong by X seconds et les corrections appliquées.
• chronyc makestep — force une correction immédiate après un écart important (à éviter sur une base de données en production).
• hwclock --systohc — recopie l'heure système dans l'horloge matérielle.

Symptôme fréquent : System clock synchronized: no alors que chrony tourne. La cause est presque toujours un blocage UDP/123 en sortie ou un serveur interne inaccessible — chronyc sources affichera alors uniquement des ^?.

Serveur NTP Stratum interne

En environnement cloisonné (OT, DMZ, réseau sans accès Internet), déployez un ou deux serveurs NTP internes. Deux approches :

• Stratum 2 : un serveur chrony synchronisé sur des pools publics et redistribuant l'heure au réseau interne. Il suffit d'ajouter allow 10.0.0.0/8 dans chrony.conf et d'ouvrir UDP/123 en entrée.
• Stratum 1 : un serveur équipé d'un récepteur GPS ou DCF77 (via gpsd et le driver SHM de chrony). C'est la solution des environnements industriels ou réglementés qui doivent prouver une traçabilité horaire sans dépendance externe.

Prévoyez toujours deux serveurs internes : une source NTP unique est un point de défaillance qui, lorsqu'il tombe ou dérive, entraîne l'ensemble du parc avec lui. Ajoutez enfin la surveillance de l'écart d'horloge (chronyc tracking) à votre supervision, au même titre que l'espace disque ou l'état du quorum.