Trois horloges dans un seul journal VPN : client, passerelle, collecteur

La chronologie d’un incident VPN commence généralement par deux horodatages qui diffèrent de quelques minutes et par un affichage qui montre une autre heure. La tentation est d’en choisir un comme correct et de réécrire l’autre. Les deux peuvent être justes, car des horloges différentes les ont écrits à propos d’événements différents. Le mythe est qu’un VPN n’a qu’une horloge ; le travail consiste à déterminer quel composant a écrit chaque champ.

Le mythe : le VPN n’a qu’une horloge

Un client écrit un événement lorsqu’il tente une connexion. Une passerelle écrit un événement lorsqu’elle reçoit ou accepte cette tentative. Un collecteur écrit une heure d’arrivée lorsqu’il reçoit le message de la passerelle. Ce sont trois événements, et chacun est estampillé par l’horloge à laquelle le composant qui écrit a fait confiance. Les réduire à une seule chronologie est une commodité qui masque le désaccord que vous cherchez à expliquer.

Les nombres diffèrent généralement de quelques secondes à quelques minutes, et c’est normal. Ce qui compte, c’est de savoir si l’écart est un délai de livraison, un décalage d’horloge ou un événement réellement différent. Pour décider ce que vous regardez, il faut l’origine de chaque champ, pas une opinion plus ferme sur la machine qui a raison.

Lisez l’origine avant la valeur

Avant de comparer des valeurs, identifiez qui a produit chacune et de quel champ il s’agit. Un message syslog porte un horodatage de l’origine, comme le décrit RFC 5424, et le format peut aussi porter des informations de qualité du temps décrivant la synchronisation et la précision. Le même format permet à l’origine de n’envoyer aucun horodatage lorsqu’elle ne peut pas lire l’heure système, ce qui est en soi un signal utile.

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

Un client peut aussi envoyer une valeur de temps comme métadonnée d’application, et un service qui la stocke devrait l’étiqueter comme déclarée par le client plutôt que la traiter comme vérifiée indépendamment. Cette étiquette fait la différence entre une preuve et une affirmation. Lorsque vous exportez des journaux pour une affaire, gardez ensemble le nom du champ, l’origine et le décalage. Les réduire à une heure locale commode détruit précisément l’information dont vous avez besoin.

Arrêtez-vous si vous ne pouvez pas dire quel composant a écrit un champ. Le comparer à autre chose est une supposition.

L’affichage du fuseau horaire n’est pas un autre instant

Le même instant affiché comme 10:00Z et comme 18:00+08:00 n’est pas une divergence, et le traiter comme telle fait perdre une demi-journée. Convertissez les deux en UTC avant de comparer, et gardez le texte d’origine à côté de la conversion. Une fraction décimale d’un côté et des secondes entières de l’autre ne sont pas non plus un conflit. La précision n’est pas l’exactitude : une valeur avec des millisecondes peut quand même venir d’une horloge fausse de plusieurs minutes.

date -u +%FT%TZ
timedatectl

Le délai de livraison est l’autre explication ordinaire. La passerelle enregistre le moment où elle a accepté la connexion, et le collecteur enregistre le moment où le message lui est parvenu, donc l’écart entre les deux est un temps de transport. Cet écart dit quelque chose du pipeline de journaux, pas de la session VPN. Étiquetez-le comme heure d’arrivée et il cesse de concurrencer l’heure de l’événement.

Corrélez sans réécrire les preuves

Conservez les horodatages d’origine et ajoutez une colonne dérivée si vous avez besoin d’une vue commune. Expliquez la conversion dans les notes plutôt que de modifier les enregistrements source, car la source est ce qu’un relecteur ultérieur vérifiera. Préservez l’heure d’arrivée du collecteur séparément partout où elle existe.

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

Changer l’horloge d’un appareil n’est pas un contrôle de confidentialité et ne réécrit pas les enregistrements qu’un autre système détient déjà. Cela rend aussi les preuves de support plus difficiles à comparer, et cela peut casser les contrôles de certificats et de code qui dépendent du temps. Gardez les horloges synchronisées pour le fonctionnement ordinaire, et traitez tout décalage délibéré comme une panne à examiner. Si les deux enregistrements semblent hors séquence, examinez la synchronisation des horloges et la livraison avant de construire une nouvelle histoire.

Le mythe à abandonner est qu’il existe un seul temps du VPN. Demandez ce que chaque champ a écrit et ce qui s’est passé quand il l’a fait, et la chronologie devient un ensemble d’observations étiquetées plutôt qu’une contradiction.