Pourquoi tcpdump n'affiche le texte en clair IPsec que dans un sens

Vous lancez tcpdump sur l'interface externe d'une passerelle IPsec Linux et vous voyez deux choses à la fois : des trames ESP entrantes et, juste après, les paquets internes déchiffrés. En sortie, seul ESP apparaît. La conclusion naturelle est que les réponses ne sont pas envoyées ou qu'IPsec chiffre un sens et oublie l'autre. Ni l'une ni l'autre n'est vraie.

Ce que vous regardez est un point de capture. Le noyau transforme les paquets sortants avant que le chemin d'émission de l'appareil ne les remette au socket de paquets, si bien que le socket ne voit jamais la forme interne qui sort. En entrée, le paquet est d'abord capturé sous forme ESP et la copie décapsulée devient visible lorsqu'elle rentre dans la pile. Même trafic, deux fenêtres d'observation différentes.

Le point de capture décide de ce que vous voyez

Sur une interface normale, un socket AF_PACKET se place près de la couche de l'appareil. Les paquets qui quittent l'hôte passent d'abord par le traitement de sortie IPsec, qui transforme un segment TCP interne en datagramme ESP ou UDP-4500, et n'atteignent cette couche qu'ensuite. Les paquets qui arrivent sont copiés vers le socket au moment où ils sortent du câble, encore chiffrés, et le résultat déchiffré devient visible plus tard lorsque la pile le remet localement ou le transfère.

Cet ordre explique entièrement l'asymétrie. Ce n'est pas une preuve sur le sens, la politique ou le comportement de l'application, et le traiter comme tel pousse à chercher une réponse qui a été envoyée correctement depuis le début. C'est l'une des rares énigmes réseau où l'instrument, et non le réseau, crée l'anomalie.

Faites correspondre le filtre à la couche visée

Une expression comme tcp port 443 sélectionne une connexion TCP interne. En sortie, cette connexion est déjà devenue ESP au moment où le socket est consulté, donc le filtre ne correspond à rien. Si vous voulez compter le trafic protégé, filtrez plutôt sur la forme externe : protocole 50 pour ESP brut, ou port UDP 4500 lorsque la traversée NAT est en jeu. Les deux filtres produisent un nombre de paquets comparable entre les deux pairs, ce qui est généralement la raison du comptage. Aucun des deux ne vous dit si la requête interne a reçu une réponse.

Ne traitez pas un comptage UDP 4500 comme un comptage de paquets ESP. IKE utilise aussi ce port pour les keepalives NAT-T et pour l'échange encapsulé, donc le nombre inclut du trafic qui n'est pas les données que vous vouliez mesurer. L'échange IKE initial sur UDP 500 a besoin de son propre filtre si c'est la question. Un nombre qui mélange trafic de contrôle et données rend aussi toute estimation de débit fausse d'une marge inconnue. Des comptages séparés répondent à des questions séparées.

Écrivez le filtre à côté de la question à laquelle il répond. « Combien d'ESP a quitté la boîte » et « la requête web a-t-elle quitté la boîte » sont des mesures différentes avec des filtres différents, et une seule capture ne peut pas trancher les deux. Sans cette note, deux personnes compareront des nombres qui ne comptaient jamais la même chose.

Observez avant la transformation, pas après

Si vous devez voir le texte en clair sortant, déplacez le point d'observation plus tôt, avant le traitement de sortie IPsec. NFLOG vous donne un point d'accroche Netfilter où une règle peut copier des paquets choisis vers un socket en espace utilisateur, que tcpdump peut lire. Le guide de vidage de trafic de strongSwan documente cette approche exactement pour cette raison.

La correspondance de politique limite la règle au trafic sur le point d'entrer dans un tunnel. -m policy --pol ipsec --dir out est ce qui rend la règle précise au lieu de journaliser chaque paquet que la boîte envoie. Lisez ensuite le groupe de journal avec une capture bornée : un petit nombre d'instantanés et une limite de taille empêchent le diagnostic de devenir une archive de trafic. Une capture bornée est aussi plus facile à remettre à un relecteur sans traîner de charge inutile. Décidez le nombre avant de commencer, pas après avoir vu combien est arrivé.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Choisissez le point d'accroche adapté au flux. OUTPUT couvre le trafic que la passerelle génère elle-même ; le transit d'un client LAN passe par la chaîne FORWARD et une règle sur OUTPUT ne le verra jamais. L'adresse et le port ci-dessus sont des valeurs de remplacement pour une destination de test approuvée.

Ce que l'observation prouve

NFLOG est une cible de journalisation, pas une décision d'acceptation. Un paquet qui y apparaît montre qu'il a atteint le point d'accroche et correspondait à la règle. Il ne montre pas qu'un filtre ultérieur l'a autorisé, que l'appareil l'a transmis ou que le pair a reçu quoi que ce soit.

Un journal vide est tout aussi ambigu. Vérifiez le compteur de paquets de la règle, confirmez le sens, confirmez que le flux correspondait bien à une politique IPsec et confirmez la destination. Seul un compteur concordant chez les deux pairs transforme une observation en conclusion. Comparez ensuite les compteurs de l'association de sécurité chez les deux pairs pour la même tentative contrôlée, car les compteurs SA sont le registre faisant foi de ce qui a été protégé et envoyé.

Un piège de plus : « texte en clair » signifie ici hors de la couche de chiffrement IPsec. Une session HTTPS interne a toujours son propre TLS. Capturer le paquet décapsulé ne déchiffre pas le TLS de l'application, et y voir du HTTP lisible signifie que l'application n'a jamais utilisé HTTPS.

Nettoyez et comparez les deux extrémités

Supprimez la règle exacte que vous avez insérée, par son propriétaire, dès que l'observation est terminée. Laisser une règle de journalisation en place coûte du CPU sur chaque paquet correspondant et crée discrètement un problème de conservation des données. Supprimez en répétant la règle avec -D plutôt qu'en vidant une chaîne qui ne vous appartient pas.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Si le déploiement utilise IPsec en espace utilisateur, une interface XFRM ou un déchargement matériel, les points d'observation se déplacent et cette recette peut ne pas s'appliquer du tout. Avec libipsec, l'endroit documenté pour observer le trafic interne est le périphérique TUN. Identifiez d'abord le chemin, puis choisissez le point qui répond à la question, et attendez-vous à ce que les deux sens ne paraissent différents que lorsque vous regardez du mauvais côté de la transformation.