L'âge du handshake WireGuard n'est pas un délai de session

Un pair qui cesse de faire passer du trafic ne perd pas sa clé pour autant, et un nouveau handshake ne prouve pas que quelqu'un a renouvelé l'autorisation de l'utiliser. Les minuteries de WireGuard gardent les clés fraîches et les paquets en circulation ; elles ne modélisent pas un utilisateur qui se déconnecte après un nombre fixé de minutes. Trois questions se confondent ici, et chacune a des preuves différentes. La distinction décide de l'outil vers lequel on se tourne.

Trois questions, une sortie de commande

Les opérateurs demandent si un pair est joignable, s'il a été actif et s'il est encore autorisé. La première est l'état du protocole, la deuxième les compteurs de trafic et la troisième l'autorisation. Seules les deux premières se lisent sur une interface WireGuard, et elles servent couramment à répondre aux trois.

Lisez les lignes comme trois enquêtes distinctes. Les deux premières sont peu coûteuses et se règlent avec les compteurs de l'interface elle-même. La troisième exige la configuration qui accorde l'accès, laquelle vit dans un autre fichier ou un autre système. Choisir la mauvaise ligne, c'est demander à une minuterie de protocole de faire le travail d'une politique.

Ce que les minuteries régissent vraiment

Le protocole définit des constantes pour la répétition du handshake, la rotation des clés de transport et le rejet des paquets protégés par une ancienne clé. Elles répondent au trafic et à l'état, pas à un calendrier ni à une politique qui dirait qu'une personne peut se connecter jusqu'à 17:00. C'est pourquoi un pair inactif peut sembler sans activité pendant des heures et rester autorisé.

PersistentKeepalive est souvent pris pour le délai manquant. Il envoie des paquets vides authentifiés pour maintenir une correspondance NAT en vie, et le mettre à zéro arrête ces paquets sans révoquer quoi que ce soit.

Lisez l'état d'exécution par pair, en utilisant la clé publique plutôt que le commentaire :

wg show wg0 latest-handshakes
wg show wg0 transfer

Un handshake récent dit qu'un handshake a abouti. Il ne dit pas que le service privé derrière le tunnel est joignable, et un horodatage ancien peut appartenir à un pair simplement silencieux.

Pourquoi un pair inactif n'est pas un pair déconnecté

WireGuard n'a pas d'objet session avec un début et une fin. Un pair est une clé publique avec des adresses autorisées, et le handshake qui protège son trafic est remplacé au besoin sans connexion visible pour l'utilisateur. Traiter l'absence de trafic récent comme une déconnexion inverse le modèle.

Si la vraie plainte est qu'une connexion échoue après être restée inactive, la cause est généralement ailleurs : une correspondance NAT expirée, un appareil qui a dormi ou un pare-feu qui a oublié l'état. Testez en envoyant du trafic depuis l'autre côté et en démarrant un nouveau flux, puis comparez ce qui change.

Placez l'échéance là où vit l'autorisation

Si l'accès doit se terminer à une heure précise, l'échéance appartient à ce qui accorde l'accès. Un contrôleur qui émet des configurations de pairs peut exiger une nouvelle approbation avant d'en délivrer une, et c'est une propriété du contrôleur et non un paramètre caché sur l'interface.

Pour les pairs gérés à la main, la suppression doit atteindre les deux endroits : l'interface en cours d'exécution et la configuration enregistrée. Supprimer le pair seulement à l'exécution est annulé par un redémarrage ou une boucle de réconciliation, qui rétablit l'identité que vous croyiez expirée :

sudo wg set wg0 peer <public-key> remove
sudo wg-quick save wg0

Testez ensuite la limite plutôt que l'étiquette. Confirmez que le pair est rejeté après l'échéance, confirmez que le chemin de renouvellement fonctionne et confirmez que l'état survit à un rechargement du gestionnaire. L'âge d'un handshake est un signal opérationnel utile, et ce n'est pas un registre d'accès.