ESP déchiffre correctement et le paquet interne n'arrive toujours nulle part

Le compteur de réception ESP augmente, le tunnel reste actif et l'application ne voit jamais le paquet. Le déchiffrement s'est exécuté, la vérification d'intégrité a réussi, puis le récepteur a dû décider ce qu'est réellement la charge utile protégée. C'est à cette dernière étape qu'apparaît une incohérence de format, et vue de l'extérieur elle ne ressemble en rien à un problème de pare-feu.

Ce que vous voyez quand l'étiquette ment

Rien dans le journal du client ne distingue cela d'un trou noir de routage. Les deux produisent un délai d'attente de l'application à côté d'un tunnel sain, et c'est pourquoi les compteurs sont blâmés en premier.

Un compteur de réception qui monte est une vraie bonne nouvelle : les paquets arrivent et s'authentifient. Ce n'est pas la preuve que le paquet interne avait un sens pour quoi que ce soit au-dessus de la couche cryptographique.

Le type habite dans la queue

En mode tunnel IPsec ordinaire, la charge utile protégée par ESP contient un paquet IP interne complet. Le champ d'en-tête suivant de la queue identifie ce qu'est cette charge, et ce n'est pas un port TCP, ni un numéro de protocole dans l'en-tête externe, ni une partie du champ initial SPI et numéro de séquence. RFC 4303 section 2.6 le définit comme le champ de type de charge, ce qui est un nom précis pour une tâche précise.

Les valeurs que vous rencontrerez sont petites et valent la peine d'être retenues : IPv4 vaut 4 (0x04) et IPv6 vaut 41 (0x29).

Ces nombres viennent des attributions de numéros de protocole de l'IANA et non d'une convention locale. Un émetteur qui déclare IPv4 tout en encapsulant un paquet IPv6 a produit une incohérence de format, et aucune règle de pare-feu ne répare des octets qui contredisent leur propre étiquette.

Comment le distinguer des suspects habituels

La plupart des paquets manquants ne sont pas des défauts d'encodage. Vérifiez d'abord les sélecteurs, car un sélecteur de trafic qui exclut le préfixe IPv6 écarte le trafic avant que quoi que ce soit soit encapsulé. Vérifiez ensuite le routage, puis le filtrage local sur l'hôte récepteur. Ce n'est qu'une fois cela écarté qu'une incohérence de format de charge devient une explication plausible.

Une capture chiffrée ne tranchera pas, car l'en-tête suivant protégé se trouve à l'intérieur de la charge chiffrée. Il vous faut des diagnostics d'implémentation ou un point d'observation déchiffré pris en charge, et les deux exigent une autorisation avant usage.

Si personne ne peut produire cette preuve, vous n'avez pas de bogue de format. Vous avez une théorie, et les sélecteurs restent le meilleur pari.

Ce que la réparation n'est pas

Ne désactivez pas les contrôles d'intégrité pour faire passer le trafic. Ne réécrivez pas les paquets chiffrés sur un routeur intermédiaire, car cela ne peut pas fonctionner et corrompra le flux tout en paraissant utile dans une capture. N'ouvrez pas une règle de pare-feu applicatif plus large en partant de l'idée qu'un port est bloqué. Rien de tout cela ne touche l'incohérence d'étiquette.

Si une incohérence confirmée vient d'une implémentation homologue, conservez une reproduction minimale assainie et portez-la au canal pris en charge de cette implémentation.

Vérifiez le flux, pas le compteur

Après la correction, testez le flux IPv6 réel de bout en bout : une requête applicative à travers le tunnel, sa réponse et la paire d'adresses que chaque côté observe. Un compteur ESP qui monte prouve seulement que des paquets sont reçus et authentifiés. Il ne dit rien sur le fait que le paquet interne était utilisable.

Consignez les deux résultats dans le ticket. Le mouvement du compteur plus un flux qui fonctionne, c'est une correction ; le mouvement du compteur seul, c'est exactement ce que vous aviez avant de commencer.