Un gel de deux secondes : était-ce le VPN ou le Wi-Fi ?
Un blocage de deux secondes et une nouvelle session VPN sont deux événements différents. Placez le chemin d’accès et le tunnel sur des chronologies séparées avant de modifier un minuteur.
Un gel de deux secondes qui se résorbe se présente de la même façon, que le tunnel ait renégocié ou que la radio ait hoqueté. Il est aussi possible que rien ne soit tombé du tout, et cette possibilité mérite d’être testée en premier. Une brève rafale de pertes, une renégociation et un blocage d’application se ressentent pareil pour la personne au clavier. Un seul des trois cas se corrige en modifiant la configuration du tunnel.
Deux relevés, pas un
Notez ce qui est arrivé à la connexion en dessous, et séparément ce que le tunnel lui-même a fait. Puis placez la pause de l’application face aux deux relevés. Ce sont des séries d’événements indépendantes qui coïncident parfois, et appeler les trois une déconnexion suppose la réponse dès le départ.
Un moniteur qui sonde une fois par minute ne peut pas voir une interruption de deux secondes. Rapporter que cette journée était saine est techniquement exact et pratiquement inutile. Placez l’intervalle d’échantillonnage à côté de chaque résultat que vous citez.
Ce que le lien d’accès a fait pendant que l’application gelait
L’intervalle d’échantillonnage et le délai d’attente définissent ce que le moniteur a pu observer, alors notez les deux à côté du résultat. Une absence de coupures enregistrée signifie peu quand l’instrument échantillonne toutes les soixante secondes. Sondez ensuite trois endroits avec horodatage : le routeur local, un hôte extérieur approuvé joint par le chemin simple et une ressource derrière le tunnel.
Confirmez d’abord les routes, car une cible publique peut elle-même passer par le tunnel et mesure alors le tunnel plutôt que le chemin d’accès. Les preuves qui datent réellement la coupure se trouvent une couche plus bas : événements de lien sur le routeur, relevés de resynchronisation sur le modem et une adresse WAN qui a changé. Un compteur cumulatif d’erreurs vous dit que quelque chose a mal tourné, jamais quand. Corrélez ces relevés avec la fenêtre de l’incident au lieu de les lire isolément.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showUn compteur qui a grimpé hier n’explique rien d’un gel survenu ce matin. Limitez la corrélation à la fenêtre signalée par l’utilisateur.
Cherchez l’enregistrement de redémarrage
Un datagramme UDP perdu ne suffit pas, à lui seul, à faire démarrer à Community OpenVPN une nouvelle négociation TLS. Le comportement de redémarrage suit ping-restart, et la valeur en vigueur a pu être imposée par le serveur ; le manuel de la 2.6 définit ces minuteurs. La livraison se coupe un instant, le seuil n’est jamais franchi et le journal reste vide. Cherchez donc dans le journal autour de la pause une ligne de redémarrage, une connexion nouvelle ou un identifiant de session qui a changé. Si aucun des trois n’apparaît, le tunnel n’a probablement rien fait et le minuteur n’a jamais été le problème.
Réduire chaque keepalive fait paraître la détection plus rapide et déplace la ligne où un hoquet devient une reconnexion. Chaque reconnexion coûte un tour d’authentification et la réinstallation des routes. Étirer le minuteur n’achète rien sauf une fenêtre plus longue où un chemin mort semble encore vivant. Les deux sont des décisions de réglage avec un prix, pas des améliorations gratuites.
Un événement absent est aussi une preuve, et c’est le genre que l’on saute parce que rien dans le journal n’attire l’attention dessus. Notez la recherche que vous avez menée, pas seulement son résultat.
Laissez la comparaison décider quoi corriger
Les deux relevés côte à côte, l’attribution s’écrit généralement d’elle-même. Un événement de lien du routeur sur les deux chemins signifie que le sujet est la connexion d’accès. Un tunnel silencieux et un chemin simple utilisable signifient que c’est la négociation.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Chaque ligne est une piste, pas un verdict : les extrémités déclassent ICMP, et deux destinations ne partagent pas forcément un chemin. Gardez les horloges alignées entre client, passerelle et application pour que la comparaison soit seulement possible. Une ligne qui tient dans deux colonnes demande une observation de plus, pas une décision.
Un rapport qui survit à la relecture répond à quatre choses : combien de temps le gel a duré, quels chemins ont continué de répondre, ce que le tunnel a journalisé à cette seconde et à quelle fréquence le moniteur échantillonne. Ces quatre faits permettent au lecteur suivant de reproduire l’observation au lieu de faire confiance à un résumé. Un pourcentage de disponibilité cache exactement l’intervalle qui vous intéresse, et la phrase "le VPN est tombé" aussi.