Dérive temporelle Proxmox : problèmes NTP qui cassent TLS/PBS et comment les corriger

Pourquoi la dérive temporelle casse Proxmox, TLS et PBS

L’heure est une dépendance que vous n’inscrivez pas dans vos diagrammes d’architecture, mais c’en est une quand même. Les certificats TLS
ont des fenêtres « notBefore » et « notAfter ». Kerberos, les JWT et la plupart des systèmes de tickets sont liés au temps. Les clusters utilisent
le temps comme signal faible pour la vivacité et l’ordonnancement des événements. Les systèmes de sauvegarde s’appuient sur l’hypothèse que
le « maintenant » est à peu près monotone pour les politiques de rétention et le ramassage des objets obsolètes.

Proxmox VE repose sur Debian. Le nœud utilise des services système (chrony ou systemd-timesyncd, parfois l’ancien ntpd),
un RTC matériel (horloge temps réel) et la gestion du temps du noyau. PBS est strict sur TLS, à juste titre. Donc si l’horloge de votre
nœud est en retard, vous obtenez « certificate not yet valid ». Si elle est en avance, vous obtenez « certificate expired » alors qu’il ne l’est pas.

Comment cela se manifeste en pratique

• Les sauvegardes PBS échouent avec des erreurs de poignée de main TLS ou des échecs d’authentification.
• L’interface web Proxmox fonctionne sur un nœud mais pas sur un autre, ou les navigateurs affichent des avertissements de façon inattendue.
• Les nœuds du cluster se « perdent » aléatoirement, montrent un ordre de logs étrange ou ont des événements corosync déroutants.
• Les VM dérivent même si l’hôte est stable, parce que les invités sont leur propre univers avec leurs mauvaises habitudes.

Si votre instinct est « je vais régler l’heure manuellement », résistez. Les sauts temporels peuvent casser des services en cours de manière à donner
l’impression d’une corruption. Les corrections graduelles sont habituellement plus sûres ; quand vous devez faire un pas, faites-le avec intention
et en limitant la portée.

Une vérité opérationnelle qui mérite d’être imprimée :
idée paraphrasée de Werner Vogels (fiabilité/opérations) : tout échoue ; concevez pour que ça continue de fonctionner malgré tout.
La synchronisation temporelle fait partie de ce plan « continuer de fonctionner ».

Faits intéressants et un peu d’historique (parce que les horloges sont bizarres)

• Le NTP est ancien — vraiment ancien. Il précède la plupart des réflexions modernes sur le « cloud » et reste l’un des protocoles les plus déployés au monde.
• Linux gère le temps avec plusieurs horloges. Il y a l’horloge murale, le temps monotone et parfois des compteurs basés sur TSC/HPET — chacun avec des garanties différentes.
• La virtualisation a compliqué le temps. Une VM mise en pause n’expérimente pas le temps ; le monde, si. Rattraper le retard n’est pas trivial.
• Les secondes intercalaires existent et sont embêtantes. Certains systèmes effectuent un step ; d’autres appliquent un smear. Les stratégies mixtes peuvent provoquer des décalages transitoires étranges.
• La dérive du RTC est normale. Les oscillateurs bon marché varient avec la température et l’âge ; quelques secondes par jour peuvent se produire sur des cartes grand public.
• Corosync n’a pas besoin d’un temps parfait, mais déboguer le comportement du cluster sans horodatages cohérents ressemble à une chirurgie avec des lunettes embuées.
• TLS est sensible au temps par conception. Ce n’est pas une dramatisation ; « notBefore » empêche la relecture de certificats émis « dans le futur » et atténue certaines attaques.
• Le PTP existe parce que le NTP n’est pas toujours suffisant. Quand vous avez besoin d’une synchronisation sub-millisecondes (trading, télécom, mesures), PTP avec timestamping matériel est la solution.
• La stratégie de smear des secondes intercalaires de Google a popularisé l’idée que faire des steps est dangereux à grande échelle ; beaucoup d’entreprises ont copié la stratégie sans en comprendre les compromis.

Blague #1 : la synchronisation temporelle est le seul endroit où « assez proche » et « cryptographie » se rencontrent, et ils commencent immédiatement à se disputer.

Feuille de diagnostic rapide

Quand Proxmox/PBS commence à lancer des erreurs TLS, vous voulez le chemin le plus court pour répondre « est-ce que c’est l’heure ? » sans vous perdre dans une fouille
archéologique de logs qui dure une semaine.

Première étape : confirmer le décalage et si le système pense être synchronisé

1. Vérifiez l’heure locale vs la réalité (et confirmez le fuseau horaire / le mode RTC).
2. Vérifiez l’état de synchronisation NTP (chrony ou systemd-timesyncd).
3. Vérifiez si le temps fait des sauts ou s’il est rattrapé lentement (les gros écarts ont tendance à être « steppés » sauf configuration contraire).

Deuxième étape : identifier la source temporelle et si elle est joignable

1. Quel service gère le NTP ? chrony vs systemd-timesyncd vs ntpd : choisissez-en un.
2. Vos serveurs configurés sont-ils joignables ? DNS, pare-feu, routage, ACL de VLAN.
3. L’hôte est-il autorisé à régler l’heure ? les conteneurs et certaines configurations durcies peuvent le bloquer.

Troisième étape : vérifier les problèmes spécifiques à la virtualisation

1. Hôte stable, invités qui dérivent ? Alors vous corrigez la tenue du temps des invités, pas NTP sur l’hôte.
2. Après suspension/reprise ou migration live ? C’est un problème de clocksource/guest-agent/politique de step.
3. Les nœuds du cluster sont en désaccord ? Corrigez l’heure sur tous les nœuds avant de toucher aux réglages corosync.

Règle : ne déboguez pas TLS tant que vous n’avez pas prouvé que l’heure est correcte. Les erreurs TLS sont honnêtes — votre montre ment, pas vos certificats.

Tâches pratiques (commandes, sorties, décisions)

Vous avez demandé du niveau production. Voici de vraies tâches à exécuter sur les nœuds Proxmox et PBS. Chaque item inclut :
la commande, un exemple de sortie, ce que cela signifie et quelle décision prendre.

Tâche 1 : Vérification rapide de sanity : heure locale et heure noyau

cr0x@server:~$ date -Ins
2025-12-26T10:14:32,118962+00:00

Sens : C’est l’heure murale avec offset de fuseau. Si ce n’est pas visiblement « maintenant », arrêtez-vous et corrigez l’heure avant toute autre chose.

Décision : Si l’écart dépasse quelques secondes en datacenter, continuez vers les vérifications de statut NTP. Si l’écart est de minutes/heures, attendez-vous à des échecs TLS et à une correction par step probable.

Tâche 2 : Confirmer si le système se croit synchronisé

cr0x@server:~$ timedatectl status
               Local time: Fri 2025-12-26 10:14:36 UTC
           Universal time: Fri 2025-12-26 10:14:36 UTC
                 RTC time: Fri 2025-12-26 10:14:35
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : « System clock synchronized: yes » est un bon signe. « RTC in local TZ: no » est le comportement sain par défaut pour des serveurs Linux (RTC en UTC).

Décision : Si synchronized: no, n’improvisez pas. Identifiez le client NTP et la joignabilité des serveurs ensuite.

Tâche 3 : Identifier qui gère le NTP (chrony vs systemd-timesyncd vs ntpd)

cr0x@server:~$ systemctl is-active chronyd systemd-timesyncd ntp
active
inactive
inactive

Sens : chrony est actif ; les autres ne le sont pas. Bien : un seul service temporel.

Décision : Si plus d’un est actif, corrigez cela d’abord. Des clients NTP qui se battent provoquent jitter, steps et misère opérationnelle.

Tâche 4 : Vérifier le tracking de chrony (offset, fréquence, état leap)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A0A0A01 (10.10.10.1)
Stratum         : 3
Ref time (UTC)  : Fri Dec 26 10:14:44 2025
System time     : 0.000123456 seconds fast of NTP time
Last offset     : +0.000081234 seconds
RMS offset      : 0.000210987 seconds
Frequency       : 12.345 ppm fast
Residual freq   : +0.010 ppm
Skew            : 0.120 ppm
Root delay      : 0.002345678 seconds
Root dispersion : 0.001234567 seconds
Leap status     : Normal

Sens : L’offset est minime ; chrony est verrouillé sur 10.10.10.1. La fréquence est en cours d’ajustement. C’est sain.

Décision : Si le « System time » affiche des secondes ou plus d’écart, vous avez probablement une mauvaise joignabilité, une source défectueuse ou un problème de clocksource.

Tâche 5 : Vérifier les sources chrony et leur joignabilité

cr0x@server:~$ chronyc sources -v
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.10.10.1                    2   6   377    18   +0.0001[+0.0001] +/- 0.0008
^+ 10.10.10.2                    2   6   377    17   -0.0002[-0.0002] +/- 0.0012
^- 192.0.2.20                    3   6   377    19   +0.0030[+0.0030] +/- 0.0100

Sens : ^* est la source sélectionnée, Reach 377 signifie des réponses réussies. Un Reach proche de 0 signifie que vous ne parlez pas à ce serveur.

Décision : Si toutes les sources affichent ? ou un reach faible, dépannez réseau/DNS/pare-feu immédiatement.

Tâche 6 : Confirmer que le port NTP (UDP/123) n’est pas bloqué

cr0x@server:~$ nc -uvz 10.10.10.1 123
Connection to 10.10.10.1 123 port [udp/ntp] succeeded!

Sens : Cela ne prouve pas des réponses NTP correctes, mais prouve la joignabilité basique sur UDP/123.

Décision : Si cela échoue, arrêtez le tuning de chrony et corrigez la politique réseau/routage d’abord.

Tâche 7 : Détecter les événements de step et les réinitialisations temporelles dans les logs

cr0x@server:~$ journalctl -u chronyd -S -2h --no-pager | tail -n 20
Dec 26 09:12:01 server chronyd[821]: Selected source 10.10.10.1
Dec 26 09:12:01 server chronyd[821]: System clock wrong by -3.421 seconds
Dec 26 09:12:01 server chronyd[821]: System clock was stepped by 3.421 seconds
Dec 26 09:12:11 server chronyd[821]: Source 10.10.10.1 online

Sens : chrony a steppé l’horloge de 3.421 secondes. Les steps sont parfois corrects, mais des steps fréquents indiquent une instabilité.

Décision : Si vous voyez des steps répétés, investiguez pause/migration de virtualisation, RTC défectueux ou services temporels multiples.

Tâche 8 : Vérifier l’horloge matérielle et le mode RTC (UTC vs localtime)

cr0x@server:~$ hwclock --show
2025-12-26 10:14:57.123456+00:00

Sens : Le RTC est proche de l’heure système et en UTC.

Décision : Si le RTC est très différent, corrigez le RTC et assurez-vous que Linux utilise UTC. RTC défectueux + reboot = voyage temporel.

Tâche 9 : Forcer une correction ponctuelle en toute sécurité (chrony)

cr0x@server:~$ chronyc -a makestep
200 OK

Sens : chrony a steppé l’horloge si nécessaire, selon sa politique.

Décision : Utilisez ceci quand vous avez un gros décalage et que vous devez rétablir la sanity immédiatement. Ensuite, corrigez la cause sous-jacente.

Tâche 10 : Vérifier que l’erreur TLS est liée au temps (côté client PBS)

cr0x@server:~$ proxmox-backup-client status --repository pbs@pam@pbs01:datastore
Error: TLS handshake failed: certificate verify failed: certificate is not yet valid

Sens : « Not yet valid » est un panneau néon indiquant un décalage d’horloge sur le client (ce nœud Proxmox) ou parfois sur le serveur (pbs01).

Décision : Vérifiez l’heure des deux côtés. Corrigez l’heure d’abord ; ne réémettez pas les certificats comme premier réflexe.

Tâche 11 : Confirmer l’heure sur PBS lui‑même

cr0x@server:~$ ssh pbs01 'timedatectl status'
               Local time: Fri 2025-12-26 10:14:59 UTC
           Universal time: Fri 2025-12-26 10:14:59 UTC
                 RTC time: Fri 2025-12-26 10:15:00
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Sens : PBS est synchronisé. Si le client ne l’est pas, le problème vient du client.

Décision : Si PBS n’est pas non plus synchronisé, corrigez PBS d’abord — votre cible de sauvegarde doit être une « autorité temporelle », pas un participant qui dérive.

Tâche 12 : Vérifier la santé du cluster Proxmox et corréler avec les problèmes temporels

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   27
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 10:15:04 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Sens : Si la « Date » diffère sensiblement entre les nœuds quand vous lancez cette commande sur chacun, vous avez de la dérive. Le quorum peut rester « Yes », mais vous vivez sur une chance empruntée.

Décision : Normalisez l’heure sur tous les nœuds avant d’investiguer des bizarreries intermittentes du cluster.

Tâche 13 : Détecter la dérive des invités depuis l’hôte via le guest agent QEMU (si installé)

cr0x@server:~$ qm agent 104 get-time
{
  "seconds": 1766744105,
  "nanoseconds": 123000000
}

Sens : Vous avez l’heure epoch de l’invité. Comparez-la avec l’epoch de l’hôte (date +%s) pour estimer le décalage.

Décision : Si les invités sont décalés alors que l’hôte est stable, corrigez les outils NTP du guest et envisagez d’activer la stratégie de synchronisation via le guest agent (dépend du système d’exploitation).

Tâche 14 : Vérifier le clocksource du noyau et les indicateurs de stabilité temporelle

cr0x@server:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Sens : Utiliser TSC est courant et rapide. Sur les CPU modernes c’est généralement stable. Sur certaines plateformes / réglages BIOS, ça peut poser problème.

Décision : Si vous observez des sauts de temps fréquents corrélés avec les états d’alimentation CPU ou les migrations, validez les réglages BIOS et envisagez un autre clocksource uniquement avec des preuves.

Blague #2 : Si vous voulez vous sentir puissant, réglez l’horloge d’un serveur cinq minutes en avance et regardez tous les systèmes de sécurité soudainement devenir philosophes.

Causes racines : les suspects habituels dans les environnements Proxmox

1) Plusieurs clients NTP qui se battent

Debian facilite la présence simultanée de systemd-timesyncd, chrony et d’un ancien ntpd lors de mises à jour ou de migrations.
Quand deux services croient posséder l’heure, vous obtenez de l’oscillation : l’un slew, l’autre step, et vos logs ressemblent à une lettre de rançon.

Conseils tranchés : choisissez chrony pour les serveurs et hyperviseurs sauf raison spécifique contraire. Il gère bien la connectivité intermittente,
les gros offsets et les environnements virtualisés.

2) Sources temporelles mauvaises ou injoignables

« Nous utilisons pool servers » va pour les portables ; c’est bâclé pour des hyperviseurs en production. Vos nœuds Proxmox devraient utiliser :
des serveurs NTP internes (ou une paire de sources amont bien contrôlées) joignables sur chaque VLAN pertinent.

Si votre source NTP traverse un pare-feu qui bloque parfois UDP/123 (ou gère mal les timeouts stateful), chrony basculera entre sources,
augmentant le jitter. PBS le remarquera via des échecs TLS intermittents, car les certificats ne se soucient pas de vos fenêtres de changement de pare-feu.

3) RTC mal configuré (localtime) ou qui dérive fortement

RTC en localtime est une convention Windows. Les serveurs Linux veulent le RTC en UTC. Si vous avez fait du dual-boot, réutilisé une station
ou importé une image douteuse, vous pouvez hériter du mauvais mode RTC. Le problème apparaît au reboot : le système démarre sur une base erronée,
puis NTP tente de corriger. La correction peut être un step. Certains services détestent les steps.

4) Pause/migration de virtualisation et invités avec mauvaise tenue du temps

Les invités sont mis en pause pendant les snapshots, sauvegardes, migrations ou contention hôte. Certains OS invités récupèrent bien ; d’autres dérivent,
puis reviennent en arrière. Si vous sauvegardez une VM vers PBS pendant que son horloge est instable, vous pouvez obtenir des problèmes d’authentification
côté invité aussi (TLS applicatif, Kerberos, réplication de base de données).

5) Gestion d’énergie, réglages BIOS et clocksource instables

Les CPU modernes font des merveilles avec le scaling et les états d’alimentation. En général c’est OK. Parfois cela interagit mal avec le maintien du temps
sur certaines plateformes. Si vous voyez la dérive corrélée aux C-states profonds, mises à jour microcode BIOS ou messages noyau étranges,
considérez-le comme un problème matériel/firmware, pas de config NTP.

6) « Hardening » qui bloque la synchronisation temporelle

Certains environnements restreignent tellement les capacités, permissions des conteneurs ou le trafic sortant que la synchronisation temporelle ne peut fonctionner.
Les opérateurs compensent alors en réglant l’heure manuellement. Ce n’est pas du durcissement ; c’est s’infliger de la douleur en plus.

Patrons de correction qui tiennent dans le temps

Choisissez un seul client temporel et configurez‑le proprement

Sur les hôtes Proxmox et PBS, je préfère chrony. Il est robuste face au jitter, gère les gros offsets et tend à bien se comporter dans les VM aussi.
L’essentiel de la configuration est de gouvernance : un seul service, géré de façon cohérente, mêmes sources amont sur toute la flotte.

Utilisez des sources NTP internes (et rendez‑les ennuyeuses)

Une paire de serveurs NTP internes, chacun synchronisé sur un amont fiable (GPS, maître PTP, ou sources Internet validées), est le schéma d’entreprise correct et ennuyeux.
Si vous ne pouvez pas exécuter de serveurs temporels internes, au moins choisissez plusieurs sources amont et assurez une politique de pare-feu stable.

Contrôlez la politique step vs slew

Les gros offsets imposent un choix : faire un step maintenant, ou slewer lentement. Pour les hyperviseurs, faire un step est acceptable pendant une fenêtre de maintenance
ou juste après le démarrage, mais des steps fréquents en état stable indiquent un problème plus profond.

chrony supporte des steps contrôlés (exemple : autoriser le step pendant les premières mises à jour). L’objectif : démarrer vite, puis rester lisse.

Rendez le RTC sain, puis conservez‑le

Mettez le RTC en UTC et conservez ce réglage lors des rebuilds. Si votre RTC est peu fiable (certaines cartes serveur vont, d’autres non),
considérez de le discipliner plus fréquemment ou de remplacer la plateforme pour les nœuds critiques. Les hyperviseurs ne sont pas l’endroit pour des oscillateurs « suffisants ».

Gérez explicitement les invités

Pour les invités Linux : exécutez chrony ou systemd-timesyncd dans l’invité ; ne comptez pas uniquement sur les indices fournis par l’hôte.
Pour les invités Windows : assurez-vous que le service temporel est configuré correctement et évitez d’empiler des outils « aidants » qui tentent tous de régler l’heure.

Si vous utilisez le guest agent QEMU, servez-vous‑en pour la visibilité de gestion, pas comme substitut à une synchronisation temporelle correcte dans l’invité.

Stabilisez le chemin réseau vers les NTP

NTP est sensible aux pics de latence et au routage asymétrique. Il peut tolérer beaucoup, mais si votre politique réseau traite UDP/123 comme optionnel,
il se comportera comme une dépendance flaky — parce que vous l’avez rendu tel.

Trois mini-récits d’entreprise des tranchées de la dérive horaire

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise moyenne exécutait un cluster Proxmox à trois nœuds avec PBS dans une armoire séparée. Après un audit de sécurité de routine, quelqu’un a resserré
les règles d’egress. L’hypothèse : « NTP est interne, donc bloquer l’egress n’a pas d’importance. » Raisonnable en apparence. Faux à deux niveaux.

Les « serveurs NTP internes » étaient en réalité des VM dans le même cluster Proxmox. Ils étaient configurés pour se synchroniser sur des sources externes.
Avec UDP/123 sortant bloqué, les VMs NTP ont lentement dérivé. Chrony sur les nœuds Proxmox s’est verrouillé sur ces sources internes — parce qu’elles étaient
joignables et stables, juste stables dans la mauvaise direction.

Deux semaines plus tard, les sauvegardes PBS ont commencé à échouer avec des erreurs TLS « not yet valid » sur certains nœuds et « expired » sur d’autres.
La dérive n’était pas identique entre nœuds. Les opérateurs ont renouvelé des certificats parce que, bien sûr, ça ressemblait à un problème de certificats.
Ça n’a rien changé. Ça n’aurait pas pu.

La correction fut ennuyeuse : rétablir l’egress NTP pour les VMs temporelles internes ou, mieux, exécuter les sources temporelles sur de petits appliances dédiés
avec une politique réseau explicite. Puis forcer une correction contrôlée (makestep) pendant une fenêtre de maintenance. Pas d’héroïsme, juste retirer une hypothèse fausse.

Mini-récit 2 : L’optimisation qui a mal tourné

Un autre service voulait « des migrations plus rapides » et a optimisé agressivement la gestion d’énergie. Les CPU pouvaient atteindre des états de sommeil profonds,
et certains réglages BIOS ont été modifiés pour réduire la consommation. Le cluster est devenu plus silencieux et plus frais. Tout le monde s’est félicité.

Puis sont apparues les bizarreries : après des migrations live, un sous‑ensemble de VM rapportait des échecs d’authentification vers des services internes pendant quelques minutes.
Pas toujours. Pas sur tous les hôtes. Ça ressemblait à du DNS. À des bugs applicatifs. À « le réseau, quoi ».

Le vrai coupable était l’instabilité du temps liée à certains changements d’état d’alimentation sur cette génération de matériel. Les invités dérivaient pendant la migration/pause,
puis revenaient. Certains services (notamment ceux qui utilisent des tokens à courte durée de vie) rejetaient les requêtes parce que les clients étaient « dans le futur » ou « dans le passé ».

La résolution n’a pas été de désactiver globalement la gestion d’énergie pour toujours, mais d’appliquer des mises à jour BIOS/firmware sensées, valider le comportement stable du TSC,
et d’arrêter d’optimiser sans mesurer. Ils ont réintroduit une alerte stricte sur la surveillance du temps : seuils d’offset par nœud et par invité clé.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avait l’habitude, presque trop conservatrice : chaque hyperviseur et nœud PBS pointait vers la même paire de serveurs NTP internes,
et ces serveurs temporels étaient traités comme de l’infrastructure critique. Ils avaient une surveillance de la joignabilité, de l’offset et des changements de stratum. Rien de fancy.

Lors d’une panne d’un fournisseur, la connectivité externe s’est dégradée. Certains sites ont perdu l’accès aux références temporelles amont. Les serveurs internes
sont entrés en état dégradé, mais sont restés cohérents sur le site, et des alertes ont déclenché tôt : « amont perdu ; service de la dernière valeur connue avec dispersion croissante ».

Le point clé : les nœuds Proxmox sont restés cohérents entre eux. TLS a continué de fonctionner parce que les horloges n’ont pas sauté. Les sauvegardes ont continué
car PBS et PVE étaient d’accord sur ce que « maintenant » signifiait. Les opérateurs ont eu le temps (l’ironie est inévitable) de répondre avant que des fenêtres d’expiration et des durées de tokens deviennent problématiques.

Leur pratique était ennuyeuse : deux sources internes, gestion de configuration cohérente et alarmes sur l’offset et la joignabilité. Ce n’était pas glamour.
C’était vivable.

Erreurs courantes : symptôme → cause racine → correctif

1) « Certificate is not yet valid » sur un dépôt PBS

Symptôme : Le client PBS échoue avec « certificate is not yet valid ».

Cause racine : Horloge du client en retard par rapport à PBS (ou les deux mal réglées dans des directions différentes). Parfois RTC incorrect après un reboot.

Correctif : Vérifiez timedatectl sur les deux, corrigez NTP, puis lancez chronyc -a makestep pendant une fenêtre sûre.

2) « Certificate has expired » alors que vous venez de le renouveler

Symptôme : TLS indique expiré immédiatement après renouvellement.

Cause racine : L’horloge système est en avance ; le renouvellement n’a pas corrigé la timeline.

Correctif : Corrigez d’abord l’heure. Puis revérifiez les fenêtres de validité. Ne réémettez les certificats que s’ils sont vraiment incorrects après accord des horloges.

3) Chrony affiche des sources mais n’en sélectionne jamais une

Symptôme : chronyc sources montre des serveurs joignables mais aucun * sélectionné.

Cause racine : Les contrôles de qualité du serveur échouent (mauvais stratum, falseticker, jitter excessif), ou l’horloge locale est tellement fausse qu’un step est nécessaire et le step est désactivé.

Correctif : Inspectez chronyc tracking, activez une politique de step contrôlée et corrigez les serveurs temporels (ou choisissez-en de meilleurs).

4) La synchronisation temporelle fonctionne jusqu’au reboot, puis c’est à nouveau faux

Symptôme : Après reboot, l’heure a des heures d’écart avant que NTP la corrige.

Cause racine : RTC incorrect, RTC en localtime, pile CMOS morte ou horloge firmware qui ne persiste pas correctement.

Correctif : Mettez le RTC en UTC, corrigez l’horloge matérielle, remplacez la pile si nécessaire, validez les paramètres BIOS temporels.

5) Les événements de cluster semblent hors ordre entre nœuds

Symptôme : La corrélation des logs est impossible ; des événements apparaissent « avant » leurs causes.

Cause racine : Les horloges des nœuds ne concordent pas de quelques secondes/minutes ; pas forcément fatal pour le cluster mais catastrophique pour l’esprit humain.

Correctif : Faites respecter la cohérence NTP sur tous les nœuds ; alertez sur les deltas d’offset entre nœuds.

6) Les invités dérivent fortement pendant les sauvegardes ou les snapshots

Symptôme : L’heure de l’invité saute après la fenêtre de sauvegarde ; l’authentification applicative échoue dans la VM.

Cause racine : L’invité est mis en pause, tenue du temps faible, aucun NTP dans l’invité ou contention hôte.

Correctif : Exécutez une synchronisation temporelle correcte dans l’invité ; réduisez les temps de pause (performance stockage), et confirmez l’installation du guest agent pour la visibilité.

7) « On a durci le trafic sortant » et maintenant le temps est instable

Symptôme : La synchronisation temporelle échoue de façon intermittente sur la flotte.

Cause racine : UDP/123 bloqué ou pare-feu stateful incohérent ; DNS des serveurs NTP défaillant.

Correctif : Autorisez NTP vers vos serveurs approuvés ; préférez les IPs ou un DNS interne stable ; surveillez la joignabilité et l’offset.

8) Passage de chrony à timesyncd « pour simplifier »

Symptôme : Fonctionne en labo, dérive en production avec jitter et perte de paquets.

Cause racine : timesyncd convient à de nombreux cas, mais chrony est généralement plus résilient pour des réseaux de niveau serveur et la gestion des offsets.

Correctif : Utilisez chrony sur les hyperviseurs et PBS sauf raison mesurée contraire. Restez cohérent sur tous les nœuds.

Listes de contrôle / plan étape par étape (la voie ennuyeuse vers un temps stable)

Étape 0 : Décidez ce que « correct » signifie pour votre environnement

• Utilisez UTC partout sur les serveurs (fuseau horaire UTC, RTC en UTC).
• Définissez un offset acceptable : typiquement < 100 ms entre nœuds pour l’infrastructure générale ; plus strict si vous avez des applis sensibles à la latence.
• Choisissez une stratégie temporelle : serveurs NTP internes, ou accès direct à des amonts fiables si nécessaire.

Étape 1 : Standardisez le client NTP sur les nœuds Proxmox

1. Choisissez chrony ou systemd-timesyncd. Ne faites pas tourner les deux.
2. Assurez‑vous qu’un seul service est activé et actif.
3. Configurez les mêmes serveurs amont sur chaque nœud.

Étape 2 : Validez la joignabilité et la qualité des sources temporelles

1. Confirmez que UDP/123 vers vos sources temporelles est autorisé depuis chaque nœud et PBS.
2. Confirmez que la résolution DNS est stable si vous utilisez des noms.
3. Assurez‑vous d’avoir au moins 2 sources (de préférence 3) pour éviter de dépendre d’un seul serveur.

Étape 3 : Réparez la baseline (RTC et offset actuel)

1. Confirmez que le RTC est en UTC, pas en localtime.
2. Si l’offset est important, planifiez une correction par step contrôlé.
3. Après correction, surveillez les steps répétés ; c’est un symptôme, pas une fonctionnalité.

Étape 4 : Durcissez PBS et PVE pour la sanity opérationnelle

• Alignez PBS sur la même politique temporelle que le cluster.
• Surveillez l’offset et la joignabilité NTP pour PBS et PVE.
• Quand des sauvegardes échouent avec TLS, vérifiez l’heure avant de faire tourner les secrets/certificats.

Étape 5 : Traitez les invités comme des consommateurs d’heure de première classe

• Exécutez NTP dans les invités (chrony/timesyncd).
• Installez le guest agent QEMU pour la visibilité.
• Surveillez la dérive après les migrations et les fenêtres intensives de snapshots.

Étape 6 : Opérationnalisez (alertes et runbooks)

• Alertez sur l’offset (absolu), le taux de changement (dérive) et la joignabilité (reach).
• Alertez lorsque la source NTP sélectionnée change fréquemment.
• Rédigez un runbook qui commence par timedatectl et finit par une remédiation contrôlée.

FAQ

1) Pourquoi la dérive temporelle casse‑t‑elle TLS si systématiquement ?

La validation des certificats TLS dépend de la vue temporelle du client. Si le client pense qu’il est avant notBefore,
le certificat est « not yet valid ». S’il pense qu’il est après notAfter, il est « expired ». Aucun « ça marche sur mon laptop »
ne change cela — votre laptop a une synchronisation temporelle fonctionnelle.

2) Dois‑je réémettre les certificats PBS ou Proxmox quand je vois des erreurs TLS ?

Généralement non. Prouvez d’abord que les horloges sont correctes des deux côtés. Réémettre des certificats sans corriger l’heure revient à produire des certificats neufs
qui seront aussi « invalides » dans votre timeline cassée.

3) chrony ou systemd-timesyncd sur Proxmox ?

chrony pour la plupart des nœuds Proxmox et PBS. Il est robuste face au jitter et à la connectivité intermittente et fournit de meilleurs diagnostics.
timesyncd peut suffire pour des configurations simples, mais la cohérence et l’observabilité comptent plus que le minimalisme ici.

4) Quel est le seuil où la dérive est « trop importante » pour Proxmox et PBS ?

Pour TLS, même quelques secondes peuvent poser problème selon les fenêtres de validité des certificats et le comportement des clients. Opérationnellement,
visez des nœuds dans l’ordre de dizaines de millisecondes si possible. Si vous voyez > 1 seconde entre nœuds, traitez‑le comme un incident, pas une curiosité.

5) Pourquoi les VM dérivent alors que l’hôte est synchronisé ?

Les invités ont leur propre noyau et leur propre tenue du temps. Les pauses (snapshots, migrations, contention hôte) peuvent provoquer de la dérive.
Si l’invité n’a pas de client temporel fonctionnel ou a des services temporels en conflit, il se comportera mal indépendamment de la stabilité de l’hôte.

6) Une migration live peut‑elle causer des erreurs TLS à l’intérieur de la VM ?

Oui. Si la migration ou le snapshot met la VM en pause et que l’horloge invitée saute ou slew agressivement ensuite, les tokens à courte durée de vie
et les vérifications de certificats à l’intérieur de la VM peuvent échouer. La solution est une synchronisation temporelle correcte dans l’invité
et la réduction des temps de pause, pas accuser PBS.

7) L’utilisation de serveurs NTP publics est‑elle acceptable pour Proxmox ?

C’est acceptable si vous n’avez pas d’alternative, mais ce n’est pas idéal. Les entreprises préfèrent des serveurs temporels internes pour la cohérence, la performance
et le contrôle politique. Si vous devez utiliser des sources publiques, en utilisez plusieurs, assurez une DNS stable et ne changez pas les règles de pare‑feu à la légère.

8) Quelle est la façon la plus sûre de corriger un gros décalage d’horloge sur un nœud en production ?

Préférez agir pendant une fenêtre de maintenance. Utilisez chrony pour effectuer un step contrôlé (chronyc -a makestep) plutôt que date -s manuel.
Surveillez ensuite les logs pour des steps répétés, signe que la cause racine subsiste.

9) Ai‑je besoin de PTP au lieu de NTP ?

Pour la plupart des déploiements Proxmox et PBS, NTP suffit. Envisagez PTP quand vous avez besoin d’une synchronisation sub‑milliseconde et que vous pouvez la supporter bout en bout
(timestamping matériel, réseau conçu pour). Un PTP déployé à moitié est juste une manière coûteuse d’avoir tort plus rapidement.

10) Comment empêcher que ça revienne ?

Standardisez le client NTP, utilisez des sources internes stables, surveillez offset/joignabilité et traitez le temps comme une dépendance de niveau 0.
La partie technique est simple. La discipline est la plus difficile.

Étapes suivantes que vous pouvez faire aujourd’hui

1. Exécutez les vérifications de diagnostic rapide sur chaque nœud Proxmox et votre boîte PBS : timedatectl, chronyc tracking, chronyc sources -v.
2. Éliminez les services temporels en duel : assurez‑vous qu’un seul de chrony/timesyncd/ntpd est actif.
3. Standardisez les upstreams : pointez tous les nœuds et PBS vers les mêmes deux ou trois serveurs temporels de confiance.
4. Corrigez le RTC : assurez‑vous que l’horloge matérielle est en UTC et qu’elle survit au redémarrage.
5. Opérationnalisez : alertez sur l’offset et la joignabilité avant que TLS et les sauvegardes ne commencent à crier.

La dérive horaire est un de ces problèmes qui vous semblent insignifiants jusqu’à ce qu’ils ruinent votre journée. Rendez‑la ennuyeuse. Votre futur vous approuvera en silence.