Un keepalive n’est pas une reconnexion : choisissez selon la panne que vous avez

Les keepalives et les reconnexions se configurent du même souffle et résolvent des problèmes différents, c’est pourquoi régler l’un corrige rarement l’autre. Un keepalive envoie un peu de trafic pour garder une entrée d’état en vie ou pour remarquer qu’un pair a cessé de répondre. Une reconnexion abat ce qui est cassé et reconstruit la relation, y compris les clés, les adresses et les routes. Choisissez le mécanisme qui correspond à la panne, pas celui dont vous connaissez déjà le réglage. Deux questions en décident : le chemin est-il mort, ou quelque chose entre les pairs l’oublie-t-il ?

Quand la correspondance est le problème

Un tunnel qui ne meurt qu’après des minutes de silence perd généralement une entrée de traduction et non un pair. Le PersistentKeepalive de WireGuard existe pour l’état NAT et pare-feu, et les notes du projet le présentent ainsi, non comme un contrôle de santé. Un intervalle de quelques dizaines de secondes garde une entrée chaude, tandis qu’un paquet chaque seconde est une décision de batterie et non de fiabilité. OpenVPN arrive au même endroit via ping et ping-restart , qui remarquent d’abord le silence puis agissent dessus.

Ces réglages ne sont pas interchangeables entre protocoles non plus. Une politique de pair mort IKEv2, une minuterie ping OpenVPN et un keepalive WireGuard répondent à la même question avec trois syntaxes et trois valeurs par défaut différentes, donc copier un nombre entre eux est une devinette déguisée en réglage.

Quand la relation a disparu

Si le pair change d’adresse, si l’identifiant expire ou si l’extrémité distante redémarre, les petits paquets ne sont pas la réparation. La reconnexion doit reconstruire l’état : obtenir une adresse, réinstaller les routes, renégocier les clés et, dans certains déploiements, réauthentifier un utilisateur.

Les clients qui se reconnectent sans surveillance détiennent un certificat ou un secret stocké. Un client qui interrogerait un humain échoue précisément quand personne n’est présent, et c’est le scénario où la reconnexion comptait. C’est un choix de conception fait des mois plus tôt, pas un réglage que vous pouvez changer pendant une panne.

Ce que ni l’un ni l’autre ne prouve

Un tunnel peut être reconnecté, chiffré et routé alors que le service derrière lui est hors ligne, et un keepalive peut maintenir une correspondance ouverte pour une session dont le serveur a disparu depuis des heures. Les deux mécanismes peuvent signaler un succès alors que ce qui vous importe vraiment est indisponible.

C’est pourquoi le test se termine par une vraie requête. Envoyez quelque chose dans le tunnel après l’intervalle qui vous importe, puis déclenchez séparément la panne pour laquelle vous avez conçu : une période d’inactivité pour le cas de la correspondance, un redémarrage ou un changement d’adresse pour le cas de la reconnexion.

Bloquer le trafic direct est une décision distincte

Une boucle de reconnexion peut être parfaitement saine alors qu’une application utilise discrètement la route ordinaire, et c’est une fuite, pas une panne. Si l’exigence est que rien ne sorte hors du tunnel, dites-le explicitement dans la configuration du client et prouvez-le en coupant le tunnel et en regardant ce qui se connecte encore. Aucun des deux mécanismes n’implique ce comportement, et aucune discipline de nouvelle tentative ne l’établit.

Notez quel mécanisme a tourné et si une nouvelle requête a réussi ensuite. Ces deux faits sont ce dont le prochain ingénieur a besoin, et aucun n’est visible dans une icône d’état. Une ligne de journal disant que le client s’est reconnecté n’est pas la même chose qu’une requête qui a fonctionné.

Écrivez la politique, pas seulement le nombre

Mettez la paire dans une phrase : l’intervalle d’inactivité, le seuil de vivacité, ce qui déclenche une reconstruction , et ce que fait le client pendant qu’il réessaie. Sans cette phrase, chaque incident futur rouvre le même débat : le keepalive est-il trop court ou la reconnexion trop lente.

Les notes de WireGuard sur les limitations sont un rappel utile que le keepalive est un contournement pour les middleboxes et non une conception générale de vivacité. Lisez cette limitation avant d’augmenter la fréquence en réponse à un problème qu’elle ne peut pas résoudre.