Surveiller une interface de tunnel IPsec : ce qu’il faut lire

Une conception IPsec basée sur les routes installe une interface virtuelle, et cette interface donne à la surveillance un objet concret : quelque chose avec un nom, des compteurs et une route qui lui est attachée. Ce n’est pas à soi seul un signal de santé. L’interface peut exister alors qu’aucune association utilisable n’est installée, et une association peut être saine alors qu’aucune route n’achemine vers elle le trafic intéressant. C’est en lisant quatre états ensemble qu’un compteur de paquets devient un diagnostic.

Parcourez-les dans l’ordre et arrêtez-vous au premier qui échoue.

Ce que l’interface ajoute au tableau

Avec une conception basée sur des politiques, la sélection réside dans la table de politiques IPsec et le noyau décide de ce qui est protégé à partir des sélecteurs de trafic. Une conception basée sur les routes ajoute une interface et une route, si bien que tcpdump et les compteurs d’interface voient une seule frontière au lieu d’un ensemble de sélecteurs. C’est un vrai gain pour le diagnostic et pour les protocoles de routage qui ont besoin d’une interface pour établir un peering.

Le gain est administratif, non cryptographique. L’interface rapporte le trafic qu’elle transporte et ne dit rien de la disponibilité actuelle de la protection du pair.

Lire les quatre états avant d’accuser le tunnel

Commencez par l’interface et la route, puis l’association, puis l’application. Chacune a sa propre commande et sa propre signature de défaillance. Un résultat propre à un niveau n’est pas un résultat propre au suivant. Exécutez les quatre avant de conclure. Une ligne verte suffit rarement à trancher.

ip -s link show xfrm0
ip route get 10.20.30.40
ip xfrm state
ip xfrm policy
swanctl --list-sas
tcpdump -ni xfrm0 -c 20 host 10.20.30.40

Une interface dont le compteur monte sans entrée d’état correspondante décrit un trafic qui entre dans un chemin que rien ne protège, ce qui est pire qu’un tunnel simplement hors service. Une entrée d’état sans route sélectionnant l’interface signifie que la cryptographie est prête et inutilisée.

Le test applicatif vient en dernier, à dessein : un ping réussi vers l’autre extrémité du tunnel ne prouve pas que le service derrière accepte les connexions.

Comparer les compteurs internes aux compteurs externes

Les compteurs de l’interface de tunnel mesurent le trafic interne ; les compteurs et les captures de l’interface physique montrent l’échange encapsulé. Les deux ne coïncideront pas un pour un, car l’encapsulation ajoute des en-têtes, les retransmissions dupliquent certains paquets et la comptabilité de l’implémentation suit ses propres règles. Attendez-vous à un ratio, pas à une égalité.

L’emplacement de la capture détermine aussi les données privées que vous collectez : utilisez donc des filtres étroits et une adresse de test inoffensive plutôt qu’une capture complète du trafic de production.

Si les compteurs internes montent et que les externes ne bougent pas, l’étape manquante est généralement la route ou la politique qui envoie les paquets dans le tunnel, et non le tunnel lui-même.

L’observer pendant un rekey et un basculement

Observez un rekey, un événement de détection de pair mort et un basculement de lien en surveillant les mêmes quatre états. Une interface peut rester présente pendant un rekey qui ne se termine jamais, et un basculement peut laisser une entrée d’état pointer vers une adresse de pair qui n’est plus joignable.

Alertez sur le chemin de service dont vous dépendez réellement, avec l’état de l’association comme contexte, plutôt que sur un simple indicateur haut ou bas. Conservez le nom de l’interface, l’adresse du pair et la route dans la charge utile de l’alerte, afin que l’intervenant n’ait pas à les reconstituer.

strongSwan documente son propre modèle d’interface XFRM, et d’autres plateformes nomment et implémentent l’objet équivalent différemment. Lisez la comparaison basée sur les routes pour l’appareil qui se trouve devant vous avant de transférer des hypothèses d’une autre implémentation. Un modèle de supervision adapté aux compteurs d’un fournisseur induira silencieusement en erreur sur un autre.