Raccourcir le minuteur DPD n’accélère pas le basculement VPN

Les tunnels tombent, la récupération prend quatre-vingt-dix secondes et le minuteur de pair mort est réglé sur dix, alors on accuse le minuteur. Ce raisonnement saute trois étapes qui se produisent après la détection et qui consomment généralement l’essentiel du temps. La détection de vivacité remarque le silence ; ensuite, la sélection de pair, l’authentification, l’installation de route et la reconnexion de l’application prennent chacune leur tour. Raccourcir la première étape ne peut pas raccourcir les autres, et cela peut ajouter de l’agitation à un système déjà en difficulté.

Quatre étapes, dont une que vous pouvez chronométrer

Écrivez la récupération comme quatre événements horodatés. La défaillance devient observable : le dernier trafic protégé utile et la première requête échouée. Le mécanisme responsable réagit : détection de vivacité, un moniteur de route ou un autre déclencheur documenté. L’alternative devient utilisable : sélection de pair, authentification, une nouvelle association et une route qui transporte réellement le trafic prévu. L’application récupère : une nouvelle opération réussit et ce qui était en cours a un résultat défini.

Les règles de vivacité d’IKEv2 décrivent des preuves concernant le pair et ses échanges, et ne disent rien d’une base de données ou d’un service de fichiers derrière ce pair. Lire un délai d’attente de vivacité comme un contrôle de santé de tout le chemin est l’erreur qui déclenche la chasse au minuteur.

Pourquoi le minuteur est le nombre le moins intéressant

Les valeurs configurées ne sont pas des unités interchangeables. Certaines sont des intervalles de nouvelle tentative, d’autres des bornes supérieures d’une tentative, et d’autres s’exécutent en parallèle. Les additionner produit un nombre qui ressemble à une prédiction et se comporte comme une rumeur. Lisez la documentation du champ que vous êtes sur le point de toucher, et notez laquelle des trois sortes il s’agit.

D’autres étapes ne sont pas du tout des minuteurs. Un temps de repli de reconnexion, une invite d’authentification interactive ou un client qui ne réévalue sa configuration qu’au redémarrage peuvent chacun dominer la panne alors que tous les minuteurs du protocole restent confortablement bas.

Mesurez l’étape qui est réellement lente

Capturez la défaillance une fois, avec des horodatages des deux côtés, puis comparez les quatre événements plutôt que les propres compteurs du protocole. Une fenêtre d’observation bien faite vaut mieux qu’un mois de réglages.

ip -4 route get 203.0.113.10
tcpdump -ni any -c 20 "esp or icmp"

Si le point de terminaison alternatif ne répond jamais, aucun changement de minuteur n’aide, car l’inaccessibilité n’est pas un problème de détection. Si le nouvel état de sécurité se forme rapidement mais que la route pointe encore vers le chemin mort, le problème est l’installation de la route et un autre ajustement de vivacité n’ajoute que de l’agitation.

L’alternative doit déjà être utilisable

Une sauvegarde définie dans une configuration n’est pas une sauvegarde qui fonctionne. Elle doit être joignable depuis le réseau actuel du client, capable d’authentifier la même identité et autorisée à transporter le même trafic sous la même politique. Découvrez l’une de ces trois lacunes pendant une panne et la discussion sur le minuteur devient sans objet. Testez l’alternative pendant que la primaire est saine, car c’est le seul moment où vous pouvez lire les deux journaux côte à côte.

Prévoyez l’alternative à l’avance, testez-la délibérément pendant que la primaire est saine et notez laquelle des quatre étapes consomme le temps. C’est cet enregistrement qui fait du changement suivant une mesure plutôt qu’une conjecture.

Agitation de retour et le chemin de gestion

Restaurer la primaire est une décision distincte. Un retour agressif peut interrompre un travail qui avait déjà récupéré sur la sauvegarde, et un chemin instable peut ressembler à un tunnel instable quand la véritable panne est une route qui oscille entre deux options égales.

Deux chemins de coût égal sans préférence sont la source habituelle de l’oscillation visible, car chaque moniteur réagit au choix de l’autre. Décidez quel chemin est préféré dans des conditions normales et rendez cette préférence explicite dans la configuration au lieu de la laisser à l’ordre des routes. Définissez à l’avance le comportement de retour souhaité et son responsable. Conservez les réglages précédents et un chemin de gestion indépendant, car un changement qui supprime votre propre accès pendant une panne transforme un incident réseau en visite sur site.

Répétez ensuite la même charge de travail et comparez les mêmes quatre horodatages. Une récupération plus courte qui laisse encore l’application attendre la même route ou connexion manquante n’est pas un progrès, c’est un autre nombre sur le même graphique.