WireGuard échoue après l’inactivité : testez d’abord la direction

Quatre questions précèdent tout changement de réglage : la même ressource fonctionne-t-elle pendant que le client est actif, combien de temps a duré la période d’inactivité, l’appareil s’est-il endormi ou a-t-il changé de réseau, et la panne n’apparaît-elle que sur le trafic lancé par la partie distante. Les réponses séparent un mappage NAT expiré d’une radio endormie et d’une application obsolète. Elles indiquent aussi si un keepalive est même pertinent. Commencez par la direction, car elle coûte une commande et élimine la moitié des causes possibles.

Quelle direction échoue ?

Une nouvelle requête sortante du client et le trafic qui arrive vers lui après une période calme sollicitent différemment un équipement à état. Les paquets sortants reconstruisent un mappage en partant, tandis que les paquets entrants ont besoin que l’ancien mappage ait survécu. Cette asymétrie est tout le test. Si le client peut sortir mais que rien n’entre, le mappage a probablement expiré, et si aucun des deux ne fonctionne, le tunnel ou l’accès réseau du client a disparu.

Notez combien de temps la période calme a duré, et si l’appareil s’est endormi ou est passé à un autre réseau entre-temps. Ces deux faits changent le diagnostic avant tout réglage.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Exécutez ces trois commandes avant et après la période calme, car chacune répond à une partie différente de la question. Un horodatage de handshake qui n’a pas bougé dit que les pairs ont cessé de se parler, tandis que un point de terminaison qui a changé dit que le mappage s’est déplacé au lieu de mourir. Les compteurs de transfert montrent si quoi que ce soit est arrivé, ce qui fait la différence entre un mappage obsolète et une application silencieuse. Notez les chiffres aux deux moments, car la comparaison est la preuve.

Sommeil, radio et état de l’application

Sur un téléphone ou un ordinateur portable, un appareil endormi peut avoir perdu tout accès au réseau, et un keepalive ne peut ni rétablir une radio éteinte ni terminer un portail captif qui n’a pas été satisfait. Les plateformes mobiles suspendent le travail en arrière-plan par politique, donc la poursuite du trafic périodique dépend de la plateforme et de ce que l’application a négocié avec elle. Une connexion en cache est le troisième cas et le plus trompeur, car le retour du tunnel n’est pas la même chose que la reconnexion de l’application à celui-ci.

Rouvrez l’application après la période d’inactivité au lieu de faire confiance à l’onglet resté ouvert. Si une nouvelle requête réussit là où l’ancienne session a échoué, le tunnel n’a jamais été le problème.

Ce qu’un keepalive fait réellement

PersistentKeepalive envoie périodiquement un paquet vide authentifié à un pair, ce qui suffit à maintenir un mappage NAT actif entre pairs et à garder le point de terminaison du pair à jour, comme le décrit le démarrage rapide de WireGuard. Il ne répare ni une radio endormie, ni une route perdue, ni une application qui ne réessaie jamais. Choisissez l’intervalle via les réglages client pris en charge et n’activez pas une valeur agressive partout simplement parce qu’un affichage d’état se tait.

La plupart des périodes d’inactivité ne sont pas des pannes. Un tunnel qui se reconnecte après cinq minutes de silence se comporte correctement, et le problème n’est que le cas où quelque chose devait arriver de la partie distante.

Attendez l’intervalle qui échouait auparavant

Faites un changement pris en charge, puis laissez s’écouler la même période d’inactivité avant de retester cette ressource. Attendre fait partie du test et non d’une formalité. Un succès immédiat après une reconnexion ne dit rien d’un symptôme de longue inactivité, car la reconnexion est précisément l’événement qui réinitialise l’état. Si le problème apparaît aussi en usage actif, revenez aux contrôles de handshake et de chemin de données plutôt que d’ajouter davantage de trafic périodique.

Gardez un seul changement par test et notez la durée d’inactivité utilisée. Sans cela, chaque comparaison ultérieure dérive et personne ne peut dire quel changement comptait. Notez les quatre faits ensemble : direction, durée, état de sommeil et comportement de l’application.