Transporter un paquet interne fixe de 1,500 octets à travers un VPN
Un paquet interne fixe de 1,500 octets ne tient pas dans un chemin externe de 1,500 octets. Mesurez la surcharge, puis choisissez un MTU sous-jacent plus grand ou une fragmentation prise en charge.
Vous avez une exigence qui ne plie pas : le côté distant doit recevoir le même paquet IP de 1,500 octets que l’émetteur envoie, en-têtes compris. Un tunnel ne peut pas encapsuler ce paquet plus son propre cadrage dans un second paquet IP de 1,500 octets, donc quelque chose dans la conception doit céder. L’ordre ci-dessous est celui que j’utilise en fenêtre de changement : écrire le budget d’octets, prouver ce que le réseau sous-jacent peut réellement transporter, puis choisir exactement un mécanisme de transport et confirmer le paquet interne de l’autre côté.
Écrivez le budget d’octets avant de modifier un profil
L’encapsulation ajoute des octets à plusieurs couches, et le total est une propriété de votre profil, pas une constante que l’on consulte. La famille d’adresses, le choix de chiffrement, le protocole de transport et toute option de compression ou de cadrage déplacent le nombre, c’est pourquoi une soustraction copiée d’un autre déploiement ne vaut rien comme budget. Partez de l’exigence interne, ajoutez la surcharge mesurée par paquet de votre propre configuration et écrivez la taille externe obtenue sur le ticket de changement avant que quiconque modifie un fichier.
Deux nombres décident de la conception : le plus grand paquet externe que le chemin transporte sans fragmentation, et les octets supplémentaires dont votre encapsulation a besoin. Quand le premier est inférieur au second plus 1,500, l’un des deux doit changer. Le choix est alors étroit plutôt que créatif, c’est pourquoi j’écris les deux nombres avant de discuter des options. Rien à la couche tunnel ne comprime ces octets et aucun entier MTU ne supprime l’exigence qui vous a été donnée.
Sondez le réseau sous-jacent avec des pings sans fragmentation
Mesurez le chemin au lieu de faire confiance au MTU de l’interface, car le plus petit lien du chemin externe est celui qui compte. Sous Linux, -M do positionne le bit d’interdiction de fragmentation et -s prend la charge ICMP, donc une trame de 1,500 octets répond à 1,472 octets de charge une fois retirés l’en-tête IP de 20 octets et l’en-tête ICMP de 8 octets. Montez la charge jusqu’à ce que la sonde échoue, puis passez à une taille jumbo pour voir si le chemin la transporte.
ping -M do -s 1472 -c 2 198.51.100.10 ping -M do -s 8972 -c 2 198.51.100.10 tracepath -n 198.51.100.10
Un chemin qui passe 1,472 et échoue à 8,972 ne peut pas transporter un paquet interne de 1,500 octets plus la surcharge dans un seul paquet externe. C’est la réponse qu’il vous fallait avant d’ouvrir la configuration VPN. Elle décide aussi laquelle des deux sections suivantes s’applique à vous, alors gardez les deux résultats de sonde près du ticket. Deviner ici coûte une fenêtre de maintenance, car un tunnel qui se déclare actif ne dit rien du plus grand paquet que le chemin acceptera.
N’augmentez le MTU du chemin que là où chaque saut est d’accord
Les trames jumbo sont une propriété de bout en bout, pas un réglage que vous activez sur les deux extrémités que vous contrôlez. Chaque commutateur, routeur et point de remise de l’opérateur sur le chemin externe doit accepter la taille supérieure, et un seul saut de 1,500 octets écartera silencieusement le paquet que vous venez d’agrandir. Ne relever que l’interface locale est le demi-changement classique qui fait paraître le tunnel cassé pendant que le réseau sous-jacent abandonne sans bruit.
ip link set dev eth1 mtu 9000 ip link show dev eth1 ping -M do -s 8972 -c 2 198.51.100.10
Changez l’interface, puis re-sondez le même chemin avant de modifier autre chose. Si la sonde échoue encore, revenez avec ip link set dev eth1 mtu 1500 et passez à la fragmentation plutôt que de discuter avec un opérateur d’un lien qui ne vous appartient pas.
Utilisez la fragmentation du tunnel quand le réseau sous-jacent ne peut pas croître
Un mécanisme de fragmentation pris en charge sous le paquet interne permet à plusieurs paquets externes de transporter un paquet interne, et l’extrémité distante du tunnel les réassemble avant de remettre l’original à la pile. L’option de fragmentation UDP de Community OpenVPN est une implémentation de cette idée, et ce n’est pas la même chose que la fragmentation IP ordinaire du paquet externe. Les deux pairs doivent exécuter une version qui prend en charge le format, et le chemin de données doit être celui que vous croyez : les clients OpenVPN 3 et les canaux de données accélérés dans le noyau ont des limites différentes, donc un profil qui fonctionne sur un client peut échouer sur un autre.
openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4
La fragmentation externe ordinaire est l’autre option, et c’est la plus faible. Les routeurs IPv6 ne fragmentent pas du tout un paquet transféré, donc un paquet externe surdimensionné meurt simplement et l’émetteur ne l’apprend que si le message ICMPv6 concerné survit au chemin. Les fragments invitent aussi le filtrage et l’amplification des pertes, c’est pourquoi je traite cela comme un repli et non comme un plan.
Un support externe basé sur un flux contourne la question de la taille en segmentant son propre flux d’octets, et le paquet interne reconstruit peut toujours faire 1,500 octets. C’est une décision de transport avec son propre coût, y compris le comportement bien connu de TCP dans TCP, alors prenez-la délibérément et non comme effet secondaire d’une discussion sur le MTU.
Confirmez que le paquet interne arrive inchangé
La vérification n’est pas une poignée de main réussie. Capturez sur l’interface du tunnel aux deux extrémités et comparez la taille et le contenu du paquet que l’application a réellement envoyé avec celui que le côté distant a reçu.
ip link show dev tun0 ping -M do -s 1472 -c 2 10.8.0.1 tcpdump -ni tun0 -c 5 'icmp and greater 1000'
Si la capture montre le paquet interne de taille pleine à l’extrémité distante, le choix de transport fonctionne et il ne reste qu’à le consigner. Si elle ne montre rien alors que le tunnel se déclare actif, le paquet externe est abandonné quelque part entre les extrémités, ce qui vous renvoie à la sonde et non aux réglages de chiffrement.
Consignez trois choses dans le ticket avant de le clôturer : le budget externe mesuré, le mécanisme choisi et la commande qui a prouvé que le paquet interne a survécu. La prochaine personne à toucher ce tunnel aura besoin des trois, et aucun ne peut être reconstruit à partir du seul fichier de configuration.