Compter un paquet G.729 à travers un tunnel IPsec

La voix sur IPsec s'énonce en débit de codec, et ce chiffre est faux à chaque frontière sauf celle du codec lui-même. L'audio fait 8 kbit/s, le paquet qui le transporte est plus gros, l'enveloppe ESP plus grosse encore, et la trame Ethernet ajoute une encapsulation qu'aucune capture sur le tunnel ne montre. Compter un paquet à partir d'un format annoncé est le seul moyen de savoir ce que le lien physique doit réellement transporter. Le parcours ci-dessous le fait pour un seul sens, et chaque nombre ici est de l'arithmétique, pas une mesure.

Partez d'un choix de paquétisation, pas d'un chiffre de codec

Une fiche de codec donne le débit de la charge utile et rien d'autre : G.729 émet 8 kbit/s, soit 30 octets d'audio toutes les 30 ms. Elle ne dit rien des en-têtes, de la protection ou de l'encapsulation, et ces trois éléments dominent le résultat. L'intervalle est un choix de politique que les deux extrémités doivent accepter, alors choisissez-le d'abord et énoncez-le, car chaque nombre ultérieur dépend de cette seule décision.

Cet exemple utilise 30 ms, donc le débit de paquets est de 33.3 par seconde. Il suppose un en-tête RTP de 12 octets, un en-tête UDP de 8 octets et un en-tête IPv4 interne de 20 octets sans options, sans SRTP, sans compression d'en-têtes ni remplissage de confidentialité du flux de trafic ; tout changement décale le budget avec lui, c'est pourquoi les hypothèses se placent à côté de la réponse.

Ajoutez les en-têtes internes, puis l'enveloppe ESP

L'application envoie charge utile plus RTP plus UDP plus IP, soit 70 octets à cette paquétisation. Ce flux interne ressort à 18.7 kbit/s, déjà plus du double du débit du codec, car ce sont les en-têtes et non l'audio qui occupent l'essentiel du paquet. Aucun de ces octets n'est de la voix ; ils sont le prix de l'adressage et du séquencement. Une capture prise au-dessus du tunnel montre exactement ce nombre, et c'est celui que les gens citent quand ils disent que l'appel est petit.

C'est aussi le nombre qui n'atteint jamais le câble. Le mode tunnel ESP ajoute un SPI et un numéro de séquence de 8 octets, un IV explicite de 8 octets pour AES-GCM, une queue de 2 octets et une étiquette d'authentification de 16 octets. La charge utile de 70 octets plus la queue arrive à 72, ce qui satisfait déjà l'alignement sur quatre octets, donc aucun remplissage supplémentaire n'est nécessaire ici.RFC 4106 fixe les tailles de l'IV et de l'étiquette GCM, et les deux relèvent de l'arithmétique plutôt que d'une note de bas de page :

30  payload, G.729 at 30 ms
12  RTP
 8  UDP
20  inner IPv4
--
70  inner IP packet
 8  ESP SPI and sequence
 8  explicit IV
 2  pad length and next header
16  authentication tag
--
104 ESP packet

Ajoutez les en-têtes externes qu'exige la traversée NAT

À l'extérieur de l'enveloppe ESP se trouvent un en-tête IPv4 externe de 20 octets et un en-tête UDP de 8 octets pour la traversée NAT, si bien que le paquet passe à 132 octets. L'encapsulation UDP existe parce que le paquet doit survivre à un dispositif de traduction entre les pairs, et elle change la forme externe sans toucher la charge protégée. À 33.3 paquets par seconde, 132 octets font environ 35.2 kbit/s, soit à peu près quatre fois le débit nominal du codec.

Ni l'étiquette ni l'IV ne peuvent être retirés de l'estimation pour la réduire, car les deux font partie de ce que le lien transportera réellement. Une estimation qui les omet décrit un paquet que le récepteur rejetterait. Il en va de même de la queue, qui existe pour marquer la frontière de la charge et l'en-tête suivant dans la région protégée.

Nommez la frontière avant de citer le nombre

Un chiffre d'IP externe exclut encore l'encapsulation Ethernet. Un lien d'accès étiqueté ou non étiqueté ajoute un en-tête MAC de 14 octets et une séquence de contrôle de trame de 4 octets, ce qui porte la trame à 150 octets, la taille qu'un port de commutateur compte. Au même débit de paquets, cela fait 40 kbit/s, cinq fois le débit du codec, et l'écart n'est pas du gaspillage mais le coût du transport.

Le chiffre de 40 kbit/s exclut encore le préambule, l'espace entre trames, les étiquettes VLAN, l'encapsulation de l'opérateur, RTCP, la signalisation et l'audio qui voyage dans l'autre sens. C'est une estimation par sens, non une réservation de lien, et la citer comme telle surestime ce que le lien doit réserver à un endroit tout en le sous-estimant ailleurs. Une capture sur l'hôte peut aussi manquer l'encapsulation que le lien ajoute, c'est pourquoi la frontière doit être nommée à côté du nombre, et pourquoi un tableau de frontières est plus utile qu'un seul chiffre de tête. Réservez séparément pour le sens que vous n'avez pas compté.

Vérifiez l'arithmétique contre l'interface

Avant de faire confiance à l'estimation, comparez-la à ce que l'interface rapporte pour un nombre connu de paquets. Capturez sur l'interface physique plutôt que sur le périphérique du tunnel, afin que l'encapsulation que vous cherchez à comptabiliser soit incluse, et attendez-vous à un petit écart plutôt qu'à une correspondance parfaite.

sudo tcpdump -ni eth0 -c 50 'udp port 4500'
ip -s link show eth0

La capture confirme la taille du paquet externe, tandis que les compteurs de l'interface montrent le débit encapsulation comprise. Si les deux diffèrent d'environ la tolérance Ethernet, l'arithmétique est juste et seule la frontière était mal nommée. Un écart bien plus grand qu'un en-tête de trame désigne autre chose sur le lien, comme des retransmissions ou un autre flux partageant l'interface. Écrivez l'intervalle de paquétisation, la suite de protection et la frontière à côté du nombre, car une estimation sans ces trois est citée comme une mesure par la personne suivante qui la lit.