IPIP dans WireGuard : les 20 octets de plus que personne n'avait budgétés

De petits pings traversent le tunnel toute la journée, la bannière SSH arrive, puis la session se fige à l'instant où un transfert de fichier commence. Ce schéma désigne un budget d'octets compté à la mauvaise couche, où le tunnel extérieur a été dimensionné pour son propre surcoût et où personne n'a soustrait l'intérieur. Un paquet IPIP imbriqué n'est qu'un paquet IP de plus pour WireGuard, et c'est précisément pourquoi il consomme des octets que vous n'avez jamais réservés. La correction est arithmétique, et elle tient en trois commandes et un tableau.

Le symptôme qui le trahit

Les problèmes de fragmentation s'annoncent par la taille, jamais par les adresses. Votre pair répond à un ping de 56 octets pendant une heure, puis se tait à 1400 octets alors que le tunnel reste debout et qu'aucune route n'a changé. La poignée de main passe, la première fenêtre TCP complète non, et le transfert cale quelques secondes après avoir paru sain.

Mesurez le plafond avant de modifier quoi que ce soit, car un plafond non mesuré est celui que vous poursuivrez deux fois. Envoyez une sonde sous la taille suspectée avec le bit do-not-fragment activé, ping -M do -s 1000 10.9.0.2, puis répétez-la à une taille dont vous savez déjà qu'elle est trop grande. Quand le basculement suit la taille de la charge utile tandis que la destination reste inchangée, le routage fait son travail et il manque un en-tête au budget.

Comptez chaque en-tête une fois, à la bonne couche

Partez du plus petit MTU du chemin plutôt que de l'interface du tunnel, car le mur se situe en amont des deux extrémités. WireGuard dépense 60 octets pour un transport extérieur IPv4 : 20 pour IP, 8 pour UDP et 32 pour son propre en-tête, et 80 octets quand ce transport est IPv6. Un wg0 de 1420 octets garde 20 octets de marge sous les 1440 qu'un chemin de 1500 octets peut réellement livrer, et c'est pourquoi le chiffre copié d'un wiki tient encore ici. Dessinez toute la pile sur le schéma, car celui qui changera le MTU ensuite choisira sinon un nouveau chiffre rond et héritera de votre bug.

La cinquième ligne est là où les budgets dérapent, car les 1400 octets portés par une interface imbriquée incluent déjà les 40 octets d'en-têtes du paquet d'origine. Seuls 1360 de ces octets atteignent le processus qui lit le fichier. Traitez 1400 comme charge utile applicative, comme tout schéma dépourvu de cette colonne vous y invite, et le périphérique intérieur finit 40 octets trop généreux face à un mur qui n'a pas bougé.

Réglez les deux MTU séparément

Le porteur et le périphérique imbriqué sont des objets distincts, chacun a donc besoin de sa propre valeur. Appliquez-les dans cet ordre, car le périphérique imbriqué n'hérite rien du porteur :

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

La règle à retenir : MTU intérieur = MTU extérieur - 20 lorsque le paquet porté par le tunnel IPIP est IPv4, et - 40 dès qu'un côté du paquet intérieur est IPv6, car l'en-tête imbriqué passe de 20 à 40 octets. Rien d'autre n'appartient à cette soustraction. Le surcoût de WireGuard a déjà été dépensé quand vous avez choisi 1420, et le facturer deux fois produit un tunnel qui fonctionne parfaitement et reste lent tant que personne ne le mesure. Un déploiement où les deux appareils portent un 1400 rond est l'empreinte exacte de cette erreur.

IPv6 d'un côté ou de l'autre du paquet imbriqué invalide chaque chiffre ci-dessus, alors recalculez au lieu de copier un nombre depuis un site similaire. Les en-têtes soustraits font 40 octets chacun dès qu'IPv6 apparaît dans le chemin extérieur ou dans le datagramme d'origine, et le chiffre de charge utile baisse exactement d'autant.

La règle de pare-feu dont vous n'avez probablement pas besoin

Entre deux pairs WireGuard, la seule chose sur le fil est UDP, donc une règle entrante pour le protocole 4, le numéro que la RFC 2003 attribue à l'encapsulation IPv4-dans-IPv4, ne crée pas le chemin imbriqué et ne le maintient pas en vie. L'en-tête IPIP vit à l'intérieur de la charge utile chiffrée, où aucun pare-feu de bord ne le voit. Ouvrir le protocole 4 quand même n'achète rien de plus qu'une voie autorisée supplémentaire vers l'hôte.

La politique qui mentionne les sources et destinations du paquet d'origine appartient à l'après-décapsulation, sur les interfaces du tunnel et dans la table de routage. Mettez-la là et la règle de bord peut rester fermée.

Ce que WireGuard valide réellement

AllowedIPs juge la source du paquet que WireGuard transporte, et ce qu'il transporte est le paquet encapsulé en IPIP. Une source IPIP autorisée est acceptée même lorsque l'en-tête intérieur nomme un hôte que vous préféreriez ne pas router. La source d'origine n'est donc pas ce que le pair a vérifié pour vous, et cette paire d'adresses intérieure a besoin de sa propre application après la décapsulation.

L'enveloppe fournit une structure de routage, pas une seconde couche de cryptographie. Qualifier IPIP de protection supplémentaire à l'intérieur de WireGuard décrit une autre conception.

Vérifiez avec une échelle, pas avec un seul ping

Sondez des tailles qui encadrent la frontière que vous avez calculée, puis confirmez ce que le noyau croit des deux appareils. Avec 1360 octets de charge utile plus 40 octets d'en-têtes faisant 1400, la première écho ci-dessous passe et la seconde se place un octet au-delà du plafond :

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

Un passage net sous le plafond et un échec à la première taille au-dessus signifient que l'arithmétique tient de bout en bout. Relancez ensuite le transfert qui avait calé à l'origine, car une sonde synthétique prouve le budget et ne dit rien des tailles d'écriture de l'expéditeur. Si le chemin imbriqué casse encore à une taille dont vous avez prouvé qu'elle passe, inspectez la décapsulation et les routes de l'extrémité distante avant de retirer dix octets de plus au MTU.