Paquet IPv6 trop gros : pourquoi les gros transferts VPN se bloquent
Les petites réponses arrivent et les gros transferts se bloquent dans le même tunnel. L’émetteur n’a jamais appris la taille du chemin, et un message de contrôle filtré l’explique.
Le ping fonctionne, le navigateur charge une petite page et le transfert de fichier se bloque, le tout en IPv6 à travers le même tunnel. Ce schéma signifie généralement que l’émetteur n’a jamais appris la taille réelle du chemin, et non que le tunnel soit lent. IPv6 attend des routeurs qu’ils signalent le problème avec un message Packet Too Big, et l’encapsulation ajoute une surcharge avant même qu’un paquet atteigne le réseau extérieur. Si ce message est filtré, l’émetteur répète une taille qui ne peut pas passer.
Petites requêtes, grands blocages
Un tunnel enveloppe chaque paquet dans un autre en-tête, si bien que la taille utilisable à l’intérieur est plus petite que la taille à l’extérieur. Un paquet dimensionné pour le lien physique avant l’encapsulation devient trop gros ensuite. Les routeurs IPv4 peuvent fragmenter en chemin, tandis que les routeurs IPv6 ne le font pas à la place de l’émetteur, donc l’émetteur doit s’ajuster lui-même. Et cet ajustement dépend entièrement de la réception du retour d’information.
Un seul message perdu suffit à produire le symptôme classique : les poignées de main et les petites réponses réussissent, et un listage de répertoire ou un envoi se bloque toujours au même point. Les utilisateurs décrivent cela comme un VPN lent, et les journaux ne montrent rien d’anormal au niveau de l’authentification. Les deux observations sont exactes, et aucune ne localise la panne.
Packet Too Big est un retour d’information, pas du trafic
Un message ICMPv6 Packet Too Big porte la taille que le prochain saut peut accepter, et l’émetteur l’utilise pour réduire son estimation. Le filtrer équivaut à retirer un panneau de signalisation puis blâmer les conducteurs. Une règle qui supprime tout ICMPv6 paraît stricte tout en cassant la découverte du chemin sur chaque lien qui en a besoin. Le message est une information de contrôle sur le chemin, pas une charge utile applicative.
Le filtrage sélectif reste raisonnable. Les demandes d’écho et la découverte de voisins jouent un rôle différent des messages d’erreur, et une politique peut les traiter différemment. Suivez les recommandations de filtrage documentées de la plateforme plutôt que d’accepter ou de supprimer tout le protocole, car RFC 8201 définit comment ce retour d’information pilote la découverte.
Testez les deux familles d’adresses séparément
Testez IPv6 séparément, car un transfert IPv4 réussi ne prouve rien sur le chemin IPv6. Capturez ensuite les messages de contrôle pendant que le gros transfert se bloque. Les deux enregistrements montrent ensemble soit que le retour d’information sort, soit qu’il n’est jamais arrivé.
ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'
La sonde envoie un paquet avec le bit do-not-fragment activé et indique la taille à laquelle il échoue, soit le nombre que le tunnel doit absorber. La requête de route nomme l’interface qui porterait la destination, vous savez donc quel MTU de lien s’applique. La capture filtre ICMPv6 type 2, le message Packet Too Big, et montre s’il atteint ce hôte. Si le message apparaît dans la capture et que le transfert se bloque encore, l’émetteur l’ignore, ce qui déplace l’enquête vers la pile plutôt que vers le réseau.
Ajustez la taille du tunnel seulement après les preuves
Baisser le MTU du tunnel peut masquer un message filtré et faire disparaître le symptôme, au prix d’une surcharge plus élevée sur chaque paquet. C’est un contournement et non un diagnostic, et il devrait suivre la capture au lieu de la remplacer. Une valeur basse arbitraire ne casse rien de visible non plus, et c’est pourquoi elle survit des années dans les configurations. Changez-la délibérément, notez la valeur et indiquez quelle mesure l’a justifiée.
Quand vous contrôlez la passerelle, examinez la règle qui supprime le message au lieu de désactiver le pare-feu. Une règle corrigée est plus étroite qu’une exception de politique et bien plus facile à défendre ensuite. Le même raisonnement vaut pour les délais : chaque blocage n’est pas un problème de taille, et c’est la capture qui sépare les deux.