La détection de pair mort d'IKEv2 ne teste pas votre application

Le contrôle de vivacité d'IKEv2 pose une question: l'autre pair répond-il encore sur la relation de contrôle protégée. Il ne mesure pas si une application interne est saine, si une route existe derrière la passerelle, ni si la navigation semble rapide. Le contrôle peut réussir alors que tout ce qui est utile derrière le tunnel échoue.

Lisez les deux types de preuves séparément avant de modifier un minuteur.

Ce que le contrôle de vivacité demande réellement

Un échange de vivacité est envoyé dans l'association de sécurité IKE établie et attend une réponse dans une fenêtre configurée. Le succès signifie que l'implémentation IKE du pair est toujours là et toujours disposée à parler. Il ne dit rien des associations de sécurité enfants qui portent le trafic, rien du routage au-delà de la passerelle et rien du service pour lequel vous avez ouvert le tunnel. Ce sont trois questions distinctes avec trois modes de défaillance distincts.

Cette distinction décide où regarder quand une session devient silencieuse. Un pair qui continue de répondre alors qu'un chemin de données est cassé pointe vers une politique, un routage ou un service en aval. Un pair qui cesse de répondre pointe vers l'accessibilité ou vers l'état propre de l'extrémité distante.

Lisez les associations de sécurité avant le navigateur

L'état de contrôle et l'état de données sont listés séparément dès que vous interrogez le démon, et les compteurs indiquent si quoi que ce soit a été tenté. Une association enfant qui n'a jamais été installée ne ressemble en rien à celle qui s'est installée puis a cessé de faire passer des paquets, même si les deux produisent la même plainte de l'utilisateur.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Notez les noms d'état mot pour mot dans le ticket, avec les compteurs au moment de la plainte. Une description comme tunnel en panne masque laquelle des deux associations s'est terminée, et c'est généralement le seul fait qui vaille la peine d'être conservé.

Une panne de route ressemble exactement à un pair mort

La passerelle peut répondre aux échanges de contrôle alors qu'un serveur privé est hors ligne, qu'une route transférée manque ou que la résolution de noms interne échoue complètement. Du côté du client, tout cela se présente comme une session active et une destination qui ne l'est pas. Vérifiez le chemin de retour aussi soigneusement que le chemin aller, car le routage asymétrique côté distant ne produit du silence que dans un sens.

Testez l'application visée directement et nommez l'adresse qu'elle a essayée, au lieu de tester si le tunnel est monté. Un ping vers la passerelle prouve que la passerelle répond; il n'a jamais prouvé que l'application le faisait. Enregistrez l'adresse exacte que l'application a essayée. Cette chaîne restreint la recherche plus tard, et c'est le seul fait que le ticket omet habituellement.

Gardez les minuteurs hors du diagnostic

Raccourcir un intervalle de détection n'est pas un changement de performance et n'ajoute pas de capacité. En cas de perte de paquets, cela change la vitesse à laquelle une panne est reconnue, ce qui peut faire paraître un symptôme différent sans rien améliorer. Enregistrez d'abord l'heure réelle de la panne, puis décidez si la tolérance est erronée pour le lien que vous avez réellement.

Les rafraîchissements de mappage NAT appartiennent à la même catégorie. Ils maintiennent un chemin traduit utilisable, et ils ne prouvent pas que l'application distante fonctionne.

Une politique de récupération complète indique ce que le client doit faire lorsqu'un pair est déclaré mort: redémarrer, fermer ou attendre, et ce que le reste du trafic peut faire pendant ce temps. Sans cela, le même incident est rediagnostiqué à zéro chaque trimestre.