IPsec ESP : ce qu’il transporte et comment prouver qu’il circule

ESP transporte le trafic d’un VPN IPsec, et son runbook commence par une règle : lisez l’association de sécurité avant de modifier une politique. La plupart des comportements inexpliqués d’ESP remontent à un sélecteur qui ne correspondait pas, à un mode supposé plutôt que lu, ou à un compteur que personne n’a vérifié pendant qu’un seul flux était envoyé. Les trois étapes ci-dessous établissent ce qui transporte quoi, prouvent qu’un flux l’utilise et laissent un retour arrière qui ne dépend pas de la mémoire. Chaque étape produit une observation qui mérite d’être notée.

Connaissez les champs avant de les lire

ESP place un en-tête devant les données protégées et une queue derrière. L’en-tête porte un index de paramètres de sécurité qui identifie l’association que le récepteur doit utiliser, un numéro de séquence pour la détection de rejeu et, dans la queue, un remplissage qui maintient la charge utile alignée pour le chiffrement. Le champ d’en-tête suivant de la queue indique quel est le contenu protégé, et c’est ainsi que le récepteur sait ce qu’il a décapsulé.

Le mode change ce qui se trouve à l’intérieur de cette protection. En mode tunnel, le matériel protégé est un paquet IP interne complet, et un nouvel en-tête externe le transporte entre les extrémités. En mode transport, la protection enveloppe la charge utile de la couche supérieure d’un paquet existant, il n’y a donc pas de second en-tête IP à défaire. Le mode utilisé est un fait de configuration, pas une question d’interprétation. Lisez-le dans l’entrée d’état au lieu de le déduire d’un schéma.

Aucun des deux modes ne cache l’adressage externe qui doit acheminer le paquet. C’est une propriété de la conception et non une lacune, et c’est pourquoi un observateur intermédiaire voit encore quelles deux adresses se parlent même lorsque la charge utile est opaque.

Première étape : lisez l’état, puis la politique

Les entrées d’état contiennent les clés et les compteurs ; les entrées de politique contiennent les sélecteurs qui décident ce qui peut les utiliser. Sous Linux, les deux sont visibles sans capture de paquets, et les lire dans cet ordre garde les deux questions séparées.

ip xfrm state
ip xfrm policy

Dans la sortie d’état, vérifiez la source et la destination de l’association, le mode, et si l’encapsulation montre des ports UDP. Ces ports signifient que la traversée de NAT est utilisée, ce qui change ce qu’un pare-feu intermédiaire doit autoriser, mais pas quels sélecteurs ou clés s’appliquent aux extrémités.

Lisez ensuite les sélecteurs de la politique. Un sélecteur qui nomme un préfixe plus étroit que le trafic que vous testez est la raison la plus fréquente pour laquelle un tunnel qui fonctionne semble ignorer un flux, et un sélecteur pour le mauvais protocole produit le même silence.

Les outils des constructeurs affichent les mêmes informations sous une forme plus commode. ipsec statusall sur strongSwan, il liste les associations enfants, leurs sélecteurs et leurs compteurs d’octets, ce qui est souvent plus rapide que de lire la sortie xfrm brute lorsque vous savez déjà quel enfant regarder.

Deuxième étape : prouvez qu’un flux fait bouger les compteurs

Les compteurs n’ont de sens que si vous savez ce qui aurait dû les faire bouger, alors choisissez une source et une destination que le sélecteur couvre à coup sûr et envoyez une requête inoffensive. Relisez ensuite la même entrée et comparez.

ip -s xfrm state
tcpdump -ni any esp

Deux lectures racontent des histoires différentes. Les paquets qui augmentent côté sortie mais jamais côté entrée indiquent un problème de transfert ou de chemin de retour plutôt qu’un problème de clé, car le paquet a été encapsulé et est parti. Si aucun compteur ne bouge, le trafic n’a jamais correspondu à la politique, et le sélecteur est l’endroit où regarder.

La capture de la même étape confirme l’encapsulation sur le fil, y compris si les paquets externes sont de l’ESP ou de l’ESP encapsulé en UDP. Elle vous montre aussi les adresses qui ont réellement transporté le flux, et celles-ci diffèrent parfois de celles de la configuration que vous lisiez.

Troisième étape : changez une seule chose et gardez un retour arrière

Notez la source, la destination, le mode, les sélecteurs et les compteurs de l’association avant de modifier quoi que ce soit. Si un changement aggrave les choses, cette note est ce qui vous permet de restaurer l’état précédent au lieu de reconstruire une configuration qui fonctionne à partir d’une supposition. La note prend une minute à écrire et en fait gagner une plus tard. C’est aussi le seul artefact qui survit à la personne qui a fait le changement.

Changez un sélecteur ou un paramètre, rechargez-le et répétez la deuxième étape sur le même flux. Supprimer une association détruit tous les flux qui l’utilisent, aussi une modification ciblée et un rechargement de l’enfant sont presque toujours préférables à un vidage de l’état pour voir ce qui se passe.

Le retour arrière d’une modification de sélecteur consiste à restaurer la politique précédente et à la recharger, avec la réserve que le pair peut avoir besoin d’un changement correspondant si le sélecteur est négocié plutôt que local. Notez cette dépendance pendant qu’elle est fraîche, car une paire à moitié restaurée est plus difficile à raisonner que l’un ou l’autre des deux états finaux.

Enfin, gardez le périmètre honnête. Une association ESP qui circule prouve que les deux passerelles protègent et livrent le segment, et elle ne dit rien sur le fait que l’application au-dessus authentifie ses utilisateurs ou chiffre ce qu’elle stocke. Ce sont des contrôles distincts avec des preuves distinctes, et le runbook n’est terminé que lorsque la personne suivante peut le répéter à partir des notes.