Pourquoi bloquer tout l'ICMP casse un chemin VPN qui fonctionne
Les messages de retour sur la taille ne sont pas des réponses ping. Quand ils n'arrivent jamais, les petits paquets passent, les gros disparaissent et le tunnel semble clignoter.
Un tunnel qui s'authentifie, transporte un ping puis se bloque sur le premier transfert volumineux est la signature classique d'un message ICMP manquant plutôt que d'un VPN défaillant. L'émetteur n'apprend jamais qu'un paquet était trop gros, réessaie à la même taille et l'application attend. Corriger cela relève d'une décision de politique de pare-feu, pas d'une réinstallation du client. L'ordre compte : mesurez où se situe la limite de taille, puis resserrez la règle qui a avalé le rapport.
Ce que l'ICMP transporte réellement sur ce chemin
Découverte du MTU de chemin IPv4 repose sur un routeur qui signale qu'un paquet avec le bit don't-fragment positionné n'a pas pu être transmis. Ce rapport est un message ICMP Fragmentation Needed, et sans lui l'émetteur n'a aucune raison de réduire la taille de son segment. IPv6 est plus strict : les routeurs ne fragmentent pas en transit, donc un message ICMPv6 Packet Too Big est le seul signal qui fait rétrécir l'émetteur.
Les deux messages sont des retours du plan de contrôle, et aucun n'est un écho de diagnostic. Une politique qui bloque le ping et une politique qui bloque tout l'ICMP se ressemblent dans une liste de règles mais se comportent très différemment sur le réseau. La seconde peut transformer un tunnel correctement dimensionné en chemin à sens unique pour tout ce qui dépasse le plus petit maillon de la chaîne.
Certains transports implémentent leur propre découverte avec des paquets de sonde, comme le décrit la RFC 4821, et dépendent moins de ce retour. C'est un argument pour vérifier quel transport vous exploitez, pas pour supposer que tout tunnel est immunisé.
| Message | Rôle sur le chemin | Si bloqué |
|---|---|---|
| ICMPv4 type 3 code 4 | Le paquet était trop gros pour le maillon suivant | L'émetteur réessaie et se bloque |
| ICMPv6 type 2 | Packet Too Big, l'équivalent IPv6 | Le même blocage, sans repli de fragmentation |
| ICMP type 11 | Temps dépassé, utilisé par traceroute | Le diagnostic perd des sauts, le trafic continue de circuler |
| Demande et réponse d'écho ICMP | Test d'accessibilité | Le ping échoue, le chemin peut être correct |
La panne dépend de la taille
Demandez si la panne est corrélée à la taille des paquets. Une page de connexion, une requête DNS et un court appel d'API passent, tandis qu'un envoi de fichier, une réponse volumineuse ou un téléchargement d'image se bloquent. Ce schéma pointe vers une limite de taille quelque part entre les deux extrémités, pas vers l'authentification ou le routage. Un petit ping réussi ne dit presque rien de l'endroit où se trouve cette frontière.
À l'intérieur d'un tunnel, deux couches sont à considérer : le paquet de charge utile et le paquet externe encapsulé. L'émetteur interne peut se comporter correctement alors que le chemin externe est plus petit que ce que le tunnel suppose, et c'est pourquoi le réglage MTU du tunnel comme la liaison physique en dessous comptent tous les deux.
Mesurez avant de modifier les règles
Sondez avec le bit don't-fragment et une taille de charge utile que vous choisissez, depuis le client en panne vers une adresse protégée :
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7Une charge utile de 1472 octets plus 28 octets d'en-têtes forme un paquet de 1500 octets. Si la grande sonde échoue avec une erreur de fragmentation et que la plus petite passe, vous avez trouvé la frontière ; ajustez pour la surcharge du tunnel et répétez jusqu'à ce que la taille fonctionnelle soit stable.
Confirmez ensuite que l'écart est le rapport lui-même. Si la sonde échoue en silence, sans erreur ni réponse, le message est probablement rejeté plutôt que délivré, et la règle est le suspect.
Resserrez la règle, puis retestez la tâche
La correction doit autoriser les messages de contrôle précis, pas tout le protocole. Sur un hôte iptables, la forme est une autorisation par type ; adaptez la syntaxe à ce qui gère le pare-feu sur votre plateforme :
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTLaissez les réponses d'écho bloquées si c'est la politique locale, car le chemin n'en a pas besoin. Retestez ensuite le transfert qui avait échoué, depuis une nouvelle connexion, et confirmez que les compteurs de la règle montrent les messages qui arrivent.
Si le transfert volumineux se bloque encore après l'autorisation des messages, la limite restante est ailleurs : un MTU de tunnel trop élevé, un proxy qui réécrit les paquets ou un boîtier intermédiaire qui rejette au lieu de signaler. La règle ICMP était nécessaire, pas suffisante.