Le VPN se déconnecte au même intervalle ? Faites correspondre le minuteur

Un tunnel qui meurt toutes les quinze minutes, ou toutes les heures à la même minute, vous dit qu'un minuteur a expiré, et non que le réseau est instable. Le geste utile est de noter l'intervalle et de le comparer aux quatre minuteurs qui produisent ce schéma. Changer les délais avant cette comparaison déplace généralement la panne sans l'expliquer, ce qui rend l'occurrence suivante plus difficile à lire que la première. La mesure coûte dix minutes et remplace une semaine de conjectures.

Transformez l'intervalle en nombre

Recueillez cinq ou six occurrences et calculez l'écart entre elles, pas l'écart depuis le début de la journée. Une coupure à 09:12, 10:12 et 11:12 est une frontière horaire ; une coupure à 09:12, 09:27 et 09:42 est de quinze minutes depuis la dernière connexion réussie. Arrondissez le résultat au minuteur le plus plausible, pas à la minute la plus proche.

Notez deux instants par événement : quand le trafic a bougé pour la dernière fois et quand le client a signalé la déconnexion. Ils diffèrent quand un tunnel meurt en silence et que le client ne le remarque qu'à l'envoi suivant, et c'est cette différence qui sépare un délai d'inactivité d'une panne franche. Un client qui remarque tard gonfle la fenêtre d'inactivité que vous mesurez.

Vérifiez si la reconnexion est automatique. Un client qui se reconnecte en quelques secondes garde l'intervalle visible dans le journal et hors du rapport utilisateur, ce qui explique pourquoi ces pannes sont souvent décrites comme occasionnelles plutôt que périodiques. Il cache aussi l'événement à la personne qui utilise l'ordinateur portable.

Quatre minuteurs qui se ressemblent

Presque toutes les chutes répétées du tunnel viennent de l'un de ces éléments : un renouvellement de clés du protocole, une expiration de mappage inactif, un événement DHCP ou d'interface, ou une politique de compte. Ils diffèrent selon que du trafic circulait et selon ce que le journal dit à la frontière.

Les signatures ci-dessous valent la peine d'être apprises, car elles permettent d'écarter trois explications à partir d'une seule ligne de journal :

La première ligne est un mécanisme de sécurité qui fait son travail, et la seconde est un équipement intermédiaire qui oublie son état. Les confondre conduit soit à affaiblir le renouvellement, soit à courir après une règle de pare-feu qui n'a jamais été impliquée.

Occupé contre inactif vous dit quelle moitié

Faites une comparaison contrôlée avec du trafic continu, comme un long flux vers un hôte à l'intérieur du tunnel, et observez si l'intervalle change. Si la coupure disparaît pendant que les données circulent, le minuteur repose sur l'inactivité.

S'il survit au trafic continu, le déclencheur relève du renouvellement, du bail ou de la politique. Ce seul test élimine la moitié des candidats en une heure d'observation environ, et il ne coûte rien d'autre que de l'attention.

Gardez le réseau d'accès inchangé pendant le test. Passer du Wi-Fi à l'Ethernet au milieu de la comparaison introduit exactement l'événement d'interface que vous cherchez à distinguer d'un minuteur.

Faites correspondre la ligne de journal à la frontière

Lisez les journaux du client et du serveur autour de l'instant noté, pas le fichier entier. Un renouvellement montre une négociation ; une expiration d'inactivité ne montre rien jusqu'au paquet suivant ; un changement de bail montre du travail d'adresse ; une limite de politique montre généralement une déconnexion administrative propre.

Ces commandes extraient la fenêtre pertinente de chaque source :

grep -iE "reneg|TLS Error|Inactivity" /var/log/openvpn.log | tail -20
journalctl -u NetworkManager --since "-90 min" | grep -iE "dhcp|link"
wg show

Si les trois sources s'accordent sur l'horodatage, vous tenez le propriétaire du minuteur. Si seul le journal du client contient quelque chose, le serveur n'est probablement pas celui qui termine la session.

Réparez l'étape, pas l'icône

Chaque propriétaire a une réparation prise en charge. Une panne de renouvellement exige des propositions compatibles aux deux extrémités. Une expiration d'inactivité exige un keepalive ou une attente d'inactivité plus courte, dans les limites permises par le chemin. Un événement de bail exige de corriger l'interface ou les réglages d'alimentation. Une limite de compte est une décision de politique, pas un bug.

Désactiver le renouvellement ou l'authentification pour garder l'icône verte échange une coupure visible contre une faiblesse invisible, et vous laisse incapable de dire quand le tunnel a négocié de nouvelles clés pour la dernière fois. Retestez ensuite la durée d'origine et conservez les horodatages, afin que l'événement suivant puisse être comparé à celui-ci au lieu de repartir de zéro.