Coupures VPN intermittentes : ce qu’il faut relever à chaque fois
Une coupure intermittente est un problème de données avant d’être un problème de configuration. Relevez cinq champs à chaque incident, puis comparez les étapes avant de changer un réglage.
Les coupures intermittentes sont un problème de collecte de données avant d’être un problème de configuration. Relevez les mêmes champs à chaque occurrence, sinon les incidents ne peuvent pas être comparés. Modifier trois réglages après chaque événement détruit la seule preuve dont vous disposiez.
La procédure ci-dessous prend environ deux minutes par incident et produit une ligne par événement. Elle suppose un accès en lecture seule sur un appareil que vous administrez.
Fixez les champs avant la première panne
Établissez la liste des champs avant que quoi que ce soit casse, car un modèle improvisé en pleine panne oublie toujours une colonne. Cinq champs suffisent pour commencer : l’heure locale avec son décalage, le déclencheur, l’étape qui a lâché, le texte exact de l’erreur et le succès ou non d’une nouvelle tentative.
Le déclencheur mérite son propre vocabulaire : inactivité, reprise après veille, changement de réseau, pic de charge, renouvellement des identifiants ou inconnu. Laissez inconnu étiqueté comme inconnu plutôt que de le compléter plus tard de mémoire. Le champ d’étape porte la plus grande valeur, car il consigne où la chaîne s’est arrêtée et non ce que l’utilisateur a ressenti. Le texte de l’erreur doit être copié mot pour mot, car une reformulation perd la distinction entre deux codes proches.
Laissez les trous comme des trous. Un modèle qui impose une réponse invite à inventer, et un contexte inventé est pire qu’une case vide.
| Field | Example | Why it earns its place |
|---|---|---|
| Time with offset | 2026-11-03T09:14+08:00 | Orders events across sources in different zones |
| Trigger | resume from sleep | Separates a cause from a coincidence |
| Stage | handshake ok, no route | Names the boundary that failed |
Relevez les mêmes cinq faits au moment de la panne
Exécutez les mêmes commandes dans le même ordre à chaque fois. Deux minutes de sortie valent mieux qu’une photo de l’icône dans la barre, et l’ordre compte lorsque les horodatages se contredisent plus tard.
date -Is journalctl -u wg-quick@wg0 --since "-2 min" --no-pager wg show wg0 latest-handshakes transfer ip route get 203.0.113.10 ping -c 3 -W 2 192.0.2.1
La première ligne estampille l’observation avec un décalage, et c’est le seul moyen de réconcilier trois sources enregistrées dans des fuseaux différents. L’extrait du journal couvre le cycle de vie du service, et la ligne de poignée de main indique si le pair a répondu. La recherche de route nomme l’interface qu’une destination précise utiliserait, ce qui n’est pas le même fait que l’existence de l’interface. Un ping vers l’adresse du tunnel montre si quelque chose traverse le lien, pas si l’autre côté est joignable.
Écrivez une ligne par incident dans un journal courant, avec ces champs et rien d’autre. Après cinq ou six entrées, triez par déclencheur puis par étape. Les motifs apparaissent sous forme de paires répétées, et une paire qui ne se répète jamais est probablement une coïncidence.
Localisez l’étape qui a lâché
La connectivité locale, l’état du pair, les routes et la résolution de noms échouent à des endroits différents, et chacun laisse sa propre trace. Si l’interface existe mais qu’aucune route ne pointe vers elle, la panne relève de la politique locale. Si l’horodatage de la poignée de main cesse d’avancer alors que l’interface reste active, la panne se situe en amont.
La résolution de noms appartient au même relevé. Un résolveur qui suivait le tunnel le lundi et le réseau local le mardi produit des pannes qui paraissent aléatoires au niveau applicatif.
Pour un accès serveur autorisé, corrélez la même tentative et non une reconnexion voisine. Conservez les horodatages d’origine et notez tout décalage à part, car les convertir sur place efface la preuve de la conversion. Une tentative, un jeu d’horodatages, une conclusion.
Comparez une condition à la fois
Une comparaison contrôlée change une condition significative et garde l’exécution ratée à côté de celle qui réussit. Déplacez l’appareil vers un autre réseau, ou désactivez une exclusion, et ne changez rien d’autre dans la même étape.
Gardez l’exécution ratée dans le relevé. L’effacer au profit de celle qui fonctionne jette la seule preuve de la frontière que vous cherchez à localiser.
Partagez un extrait, pas le profil
Avant d’envoyer quoi que ce soit, retirez mots de passe, jetons, clés privées, identités sans rapport et charges utiles. Un profil complet est un secret de configuration et non un résumé de connexion, et il n’a pas sa place dans un ticket.
Envoyez l’extrait avec les cinq champs et dites quelle étape a échoué selon vous. Cela permet à un administrateur d’examiner la frontière que vous avez nommée au lieu de faire défiler des captures d’une icône déconnectée. Si la frontière reste floue, l’étape suivante est un relevé contrôlé de plus, pas un nouveau changement de réglages.