Pourquoi votre VPN met plus de temps à se rétablir que la panne

Le Wi-Fi est revenu il y a trente secondes et le VPN est toujours hors service, alors le client semble cassé. Souvent, il suit simplement son propre calendrier de nouvelles tentatives, et ce calendrier ne sait pas que le réseau vient de revenir. Cet écart, c’est toute l’histoire : le temps de rétablissement est la panne plus l’attente que le client a déjà acceptée. Réduire chaque délai est une réponse, comprendre quel délai compte est l’autre.

Trois conditions décident si le réglage aide : quelle étape est lente, si l’échec est seulement réessayable, et comment le client apprend que le réseau est revenu.

Trois attentes qui n’en font qu’une

La résolution du point de terminaison, la négociation IKE ou TLS, la retransmission des paquets et le démarrage d’une nouvelle tentative sont des événements distincts avec des délais distincts. strongSwan documente le délai de retransmission progressif pour IKE, et OpenVPN dispose de ses propres contrôles de nouvelle tentative avec une sémantique différente. Copier un nombre de l’un à l’autre suppose que les mécanismes correspondent, et ils ne correspondent pas. Lisez la séquence du journal avant de décider quel intervalle vous regardez.

Une minute de silence dans le journal n’est pas forcément un processus figé. Ce peut être un délai exponentiel qui fait exactement ce pour quoi il a été configuré.

Quelle étape est réellement lente ?

Si le journal montre des tentatives qui échouent sur une erreur d’authentification, aucun changement de délai n’aide, car les informations d’identification sont fausses. Si aucune tentative n’est faite du tout, le client est dans sa fenêtre d’attente et le calendrier est la solution. Si des tentatives sont faites et expirent, le problème est l’accessibilité ou un écouteur absent, et réessayer plus vite ne fait que remplir le journal. Chacun de ces trois états a un propriétaire différent, et un seul d’entre eux est un problème de calage.

Classez la panne avant de toucher à un nombre.

Quand réduire un délai aide, et quand cela n’aide pas

Abaissez le plafond des nouvelles tentatives lorsque le coût dominant est l’attente après une panne courte et fréquente, comme un ordinateur portable qui passe d’un point d’accès à l’autre. Laissez-le tranquille lorsque les échecs sont longs ou rares, car réessayer agressivement ajoute de la charge au moment précis où le concentrateur est le moins capable de répondre. Dans les deux cas, changez un paramètre, notez-le et mesurez le rétablissement suivant au lieu de supposer qu’il s’est amélioré.

Un délai très bas copié dans chaque profil est l’état final habituel d’un réglage sans mesure.

Vérifiez la disponibilité avant de blâmer le client

Le client ne peut souvent pas voir que le réseau est utilisable tant que quelque chose n’essaie pas. Un portail captif, un renouvellement DHCP ou un changement de route peuvent le laisser attendre un calendrier fixé avant tout cela. Observez le changement d’état du réseau du système d’exploitation et la tentative suivante du client sur la même horloge, et vous verrez de qui est l’attente. La version rapide consiste à noter l’horodatage de l’événement réseau prêt et l’horodatage de la première tentative qui suit.

Confirmez aussi que le trafic direct reste bloqué pendant l’attente, car une reconnexion plus rapide qui fuit du trafic n’est pas une amélioration.

Ce qu’il faut consigner

Notez quel délai a changé, de quelle valeur à quelle valeur, et à quoi ressemblait le rétablissement ensuite. Notez aussi la version du client, car les valeurs par défaut évoluent d’une version à l’autre et un délai très bas non documenté déroutera la personne suivante qui lira le profil.

Cette consignation transforme la prochaine mise à jour logicielle en comparaison plutôt qu’en expérience.