Les gros paquets disparaissent sur IPsec alors que les petits pings fonctionnent toujours

Les shells distants restent réactifs, les petites sondes répondent, puis une copie de fichier rampe et se bloque sans aucune erreur que l’on puisse désigner. Un ping avec une charge plus grande le reproduit instantanément, et le même transfert fonctionne depuis le réseau local. Rien dans le chiffrement n’est lent ; certains paquets n’arrivent jamais. Deux découpes différentes peuvent produire cette signature, et elles laissent des preuves différentes.

Deux endroits où un paquet peut être divisé

Avant le chiffrement, le routeur peut découper un paquet interne trop gros et protéger chaque morceau séparément. Après le chiffrement, c’est le paquet externe terminé qui est divisé, et l’extrémité distante doit le réassembler avant de pouvoir déchiffrer quoi que ce soit. Même symptôme, travail différent pour le récepteur et réglages différents pour vous.

La distinction compte, car un correctif visant le mauvais côté change un nombre sans déplacer la panne. Un paquet refusé au niveau de l’interface ne devient jamais un paquet externe, donc aucun réglage côté externe ne peut le sauver.

Où la décision de taille est réellement prise

Une interface de tunnel porte une IP MTU, et cette valeur peut refuser un paquet interne trop gros bien avant que l’étape IPsec ne le voie. Poser un bit sur l’en-tête externe ne révise pas cette décision antérieure, car le paquet a déjà été refusé. C’est pourquoi augmenter la MTU interne aggrave parfois les choses au lieu de les améliorer. Lisez la valeur de l’interface et le comportement externe avant de changer l’un ou l’autre, car la modification la moins coûteuse est généralement celle qui explique le symptôme.

Vérifiez d’abord la valeur de l’interface, puis le comportement externe. Deux nombres, deux étapes, et un seul des deux est généralement responsable.

Le budget externe n’est pas le budget interne

Chaque encapsulation dépense des octets en en-têtes, et la quantité dépend du transport, de la famille d’adresses et de la présence ou non du NAT traversal. Un paquet interne qui tient sur la liaison locale peut encore produire un paquet externe qui ne tient pas sur le chemin au-delà. Mesurez la surcharge au lieu de la supposer, car chaque en-tête optionnel s’ajoute à la facture. Un tunnel avec NAT traversal paie plus qu’un tunnel nu, et la différence suffit à casser un transfert qui fonctionnait hier.

Lorsque le paquet externe porte le bit ne pas fragmenter, un saut qui ne peut pas le transmettre le jette et devrait renvoyer un message ICMP. Si ce message est filtré quelque part, l’émetteur réessaie sans fin et l’utilisateur voit un blocage sans explication. Ce rejet silencieux est la raison habituelle pour laquelle un problème de taille est signalé comme un problème de vitesse.

IPv6 supprime l’une des options

Les routeurs IPv6 ne fragmentent pas en transit, donc le paquet externe passe ou disparaît avec un message Packet Too Big. Ce message devient le seul canal de retour, et le bloquer casse la découverte de chemin pour chaque gros transfert qui suit. Les routeurs IPv4 peuvent fragmenter un gros paquet lorsque le bit est absent, ce qui masque la panne jusqu’à ce que quelque chose d’autre pose ce bit.

Sur une pile mixte, le même tunnel peut se comporter différemment pour les deux familles, c’est pourquoi un test sur IPv4 ne règle pas une plainte concernant IPv6. Une vérification qui n’exerce qu’une famille laisse la moitié de la réponse non mesurée.

La politique de segments TCP n’est pas une réponse générale

Limiter la taille maximale de segment aide les flux TCP, et c’est un réglage légitime lorsque le problème se limite à eux. Il n’a aucun effet sur UDP, qui transporte DNS, certains protocoles vocaux et une part croissante du trafic web.

Appliquez-le, puis testez la charge qui a échoué. Si le cas UDP échoue encore, la politique de segments n’a jamais été la réponse et le budget de l’interface demande encore de l’attention. Identifiez d’abord le protocole de la charge défaillante, puis choisissez le réglage qui lui correspond.

L’ordre de travail

Notez la plus grande charge qui survit, puis la MTU de l’interface, puis si le paquet externe porte le bit ne pas fragmenter, et enfin si le retour ICMP atteint l’émetteur. Cette séquence resserre la panne sans deviner. Conservez chaque observation avec un horodatage et une extrémité, car les quatre nombres bougent quand le chemin change.

Changez une valeur, retestez le transfert d’origine et gardez le résultat. Un tunnel qui passe une grosse sonde mais se bloque encore sur l’application est passé à un autre problème, et c’est un progrès qui mérite d’être noté. La personne suivante préférera les nombres à la conclusion.