La surcharge IPsec : le mode, le NAT-T et les algorithmes la changent
Un seul chiffre publié de surcharge décrit une encapsulation sur un chemin. Additionnez les en-têtes que votre tunnel négocie réellement, puis mesurez le chemin.
Quelque part dans un guide figure un nombre, généralement entre soixante et quatre-vingts octets, que quelqu’un a soustrait de 1500 pour obtenir une MTU d’interface. Ce nombre décrit une encapsulation précise sur un chemin précis. Changez le mode, la famille d’adresses extérieure, le chiffrement ou la présence de NAT, et l’arithmétique ne s’applique plus à votre tunnel.
Le nombre vient d’un autre tunnel
La surcharge n’est pas une propriété d’IPsec dans l’absolu. C’est une propriété du paquet qui est réellement construit : un mode négocié, un en-tête extérieur, un en-tête de protection, du remplissage, un champ d’intégrité et éventuellement une enveloppe UDP supplémentaire.
Un chiffre cité pour le mode transport avec IPv4 et sans NAT décrit un paquet plus petit que le mode tunnel avec IPv6 sous traversée de NAT. Les deux sont justes pour leur propre cas. Copier l’un ou l’autre dans un déploiement différent, c’est ainsi que les gens finissent avec une MTU qui casse les transferts volumineux. La panne est silencieuse parce que les petites requêtes continuent de fonctionner.
Additionnez les couches réellement présentes
Partez de l’en-tête IP extérieur et progressez vers l’intérieur. En mode tunnel, le paquet d’origine est à l’intérieur, donc l’en-tête extérieur est un ajout et non un remplacement. RFC 4303 décrit l’en-tête ESP, le remplissage et les données d’intégrité qui le suivent.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
Aucune de ces lignes n’est constante d’un déploiement à l’autre, et la ligne du remplissage n’est même pas constante au sein d’un seul déploiement. C’est toute la raison pour laquelle un seul chiffre publié de surcharge déçoit.
Deux sites peuvent ne pas être d’accord sur le même tunnel
Le paquet protégé doit toujours traverser le chemin extérieur, et le chemin extérieur n’est pas le même partout. Une liaison d’accès PPPoE transporte moins qu’un segment Ethernet propre. Un réseau mobile peut se réduire encore, et un fournisseur qui tunnelise son propre trafic ajoute une encapsulation que personne n’a mentionnée. Un tunnel qui fonctionne sur une liaison et échoue sur une autre décrit la seconde liaison, pas le protocole.
Les deux directions peuvent aussi différer. Une route asymétrique peut vous donner un envoi qui fonctionne et un téléchargement bloqué, ce qui se lit comme un problème applicatif jusqu’à ce que vous regardiez les tailles de paquets plutôt que l’accessibilité. Un petit ping qui réussit ne prouve presque rien sur une réponse de taille complète.
Mesurez au lieu de soustraire
Trouvez le plus grand datagramme qui survit au chemin. Comparez-le ensuite à la valeur que l’interface annonce :
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
Descendez la taille du ping jusqu’à ce que des réponses arrivent, et traitez la plus grande valeur qui fonctionne comme le budget de ce chemin. La sortie de xfrm vous dit quel mode et quels algorithmes ont été négociés, ce qui est l’entrée de tout calcul honnête. La capture confirme si c’est de l’ESP ou de l’ESP encapsulé en UDP qui circule sur le fil, ce qui règle la question du NAT sans deviner.
Réservez aussi une valeur pour le plan de contrôle. Les paquets de poignée de main IKE ont une structure différente de celle des paquets de données, donc une taille déduite d’une capture de poignée de main n’est pas une MTU du plan de données.
Placez le nombre là où il doit être
Pour TCP à travers un tunnel, un verrouillage MSS est souvent le contrôle le moins invasif, parce qu’il réduit ce que les extrémités envoient sans changer le tunnel lui-même. Pour un tunnel basé sur des routes, fixez délibérément la MTU de l’interface du tunnel et documentez pourquoi. Faire les deux à la fois puis mesurer ne vous apprend rien sur ce qui a aidé.
Gardez ensemble dans le ticket le mode négocié, la famille extérieure, la condition NAT et le symptôme reproductible. Un ensemble consigné de quatre faits vaut mieux qu’une constante mémorisée, et c’est la seule version de cela qui survive à la prochaine mise à jour du client.