Le ping VPN passe, mais les transferts se bloquent
Le passage de petits paquets ne garantit pas que des paquets plus grands puissent traverser le chemin VPN. Illustration conceptuelle.
Lors d’une intervention de télémaintenance, le routeur industriel indique que le VPN est connecté. Le ping répond et la connexion à l’automate s’établit. Pourtant, un transfert de fichier se bloque, l’interface web de l’équipement ne se charge qu’en partie ou une requête plus volumineuse n’aboutit jamais.
Commencez par vérifier si la panne dépend de la taille des paquets sur le chemin réellement emprunté par l’application. Un petit ping réussi ne prouve pas que des paquets plus grands peuvent traverser le tunnel. La surcharge du VPN et l’absence de retour sur la MTU du chemin sont des causes possibles, mais l’échec du transfert d’un gros fichier ne suffit pas à diagnostiquer un problème de MTU. La RFC 2923 décrit le cas caractéristique : le ping et les connexions interactives fonctionnent, tandis que les transferts de données volumineux se bloquent dès l’envoi de paquets plus grands.
POINTS ESSENTIELS
Testez le même tunnel, la même destination et le même chemin WAN que l’application en échec. Répétez les essais avec plusieurs tailles de paquets et dans les deux sens.
Distinguez le paquet IP interne du paquet externe encapsulé. Le chemin externe doit pouvoir transporter la surcharge du VPN.
Choisissez les réglages à partir des observations sur la MTU et des retours ICMP. Le plafonnement du MSS TCP peut aider le trafic TCP, mais ne réduit pas directement les datagrammes UDP.
Ne modifiez qu’un réglage à la fois, ouvrez de nouvelles connexions et répétez le transfert initialement en échec avant de valider la correction.
POURQUOI LES GRANDS PAQUETS ÉCHOUENT
La MTU désigne ici la taille maximale d’un paquet IP qu’une liaison peut transporter. La MTU du chemin, ou PMTU, est la plus petite MTU des liaisons du trajet. Un paquet qui tient sur le LAN de l’usine peut devenir trop grand après encapsulation VPN sur le chemin vers la passerelle distante.
L’encapsulation ajoute des octets. Par exemple, la traversée de NAT avec IPsec peut transporter ESP dans UDP. La version IP externe, le protocole VPN et d’éventuels tunnels supplémentaires modifient la surcharge. Une MTU WAN de 1500 ne permet donc pas de conclure que la MTU interne du tunnel est également de 1500.
Avec la découverte classique de MTU en IPv4, un routeur qui ne peut pas transmettre un paquet trop grand portant le drapeau Don’t Fragment (DF) le rejette et renvoie un message ICMP « fragmentation needed ». L’émetteur utilise ce retour pour réduire la taille des paquets suivants. La PMTUD en IPv6 utilise plutôt les messages ICMPv6 Packet Too Big ; les routeurs intermédiaires ne fragmentent pas les paquets IPv6.
Si le retour nécessaire est filtré ou mal traité, l’émetteur peut continuer à envoyer des paquets incapables de passer. Dans un VPN, vérifiez à la fois si le retour du chemin externe atteint l’extrémité du tunnel et comment celle-ci traite le trafic interne. Chercher uniquement les messages ICMP sur le LAN de l’automate ne montre qu’une partie du mécanisme.
« Gros » désigne ici la taille d’un paquet individuel, et non la taille totale du fichier. Si les échecs dépendent d’un type de fichier, d’une action applicative ou d’une durée précise, sans seuil de taille de paquet reproductible, il faut aussi rechercher d’autres causes.
TESTER LE CHEMIN VPN
Diagnostiquez le chemin réel de l’application industrielle, puis répétez le transfert initialement en échec. Scène industrielle illustrative.
Utilisez si possible des postes de test dont vous contrôlez la configuration aux deux extrémités du VPN. Leurs résultats aident à isoler le chemin, mais la validation finale doit revenir à l’automate programmable industriel (API/PLC), à l’interface homme-machine (IHM/HMI) ou au terminal applicatif d’origine.
1. Consigner le chemin
Notez le modèle du routeur, le firmware, le protocole VPN, les versions IP interne et externe, la connexion WAN, les adresses source et destination ainsi que les réglages MTU/MSS actuels. Confirmez que le trafic de test entre effectivement dans le tunnel prévu. Envoyer un ping à l’adresse publique du routeur, à son adresse de tunnel et à un poste situé derrière lui teste des chemins différents.
Reproduisez la panne initiale et notez le sens, l’heure et l’erreur avant toute modification.
2. Tester les tailles de paquets
Commencez par un petit paquet qui passe de façon fiable, augmentez sa taille, puis resserrez l’intervalle où les échecs commencent. Répétez chaque taille : un délai d’attente dépassé peut simplement correspondre à une perte occasionnelle.
Sur un poste de test Linux utilisant iputils ping, remplacez <remote-host-ip> par l’adresse d’un poste IPv4 sous votre contrôle, accessible à travers le VPN :
ping -4 -M do -s 1200 -c 4 <remote-host-ip>
ping -4 -M do -s 1372 -c 4 <remote-host-ip>Il s’agit de sondes d’exemple, pas de réglages MTU recommandés. Selon le manuel d’iputils ping, -s définit la longueur des données et -M do active DF tout en respectant les contrôles PMTU du noyau. Avec un en-tête IPv4 de 20 octets et un en-tête ICMP de 8 octets, 1372 octets de données produisent un paquet IP interne de 1400 octets, avant la surcharge VPN. Des options IP supplémentaires modifient ce calcul.
Une erreur locale « message too long » peut signifier que le noyau a rejeté la sonde avant son émission. Un dépassement de délai ne permet pas, à lui seul, de localiser la perte. Notez la commande, la longueur des données et le résultat observé ; ICMP et le trafic applicatif peuvent également être soumis à des règles différentes. Ces commandes Linux ne sont ni des instructions pour la CLI d’un routeur ni des tests IPv6.
3. Examiner les retours ICMP
Lorsque les accès le permettent, capturez le trafic sur les interfaces internes et externes pertinentes aux deux extrémités du VPN. Cherchez à partir de quel point les paquets plus grands n’apparaissent plus, si des messages IPv4 « fragmentation needed » ou IPv6 « Packet Too Big » sont présents et si ces retours atteignent la bonne extrémité.
Pour TCP, comparez l’établissement de la connexion avec les données et retransmissions suivantes. La retransmission répétée de grands segments est un indice décrit dans la RFC 2923, mais les retransmissions seules ne prouvent pas un trou noir de MTU, c’est-à-dire une perte des paquets trop grands sans retour exploitable.
Observation | Vérification suivante |
|---|---|
Des erreurs ICMP pertinentes arrivent à une extrémité, mais les paquets restent trop grands. | Vérifier le traitement par l’extrémité et la MTU effective du tunnel. |
Les échecs commencent régulièrement autour d’une taille donnée, sans retour visible. | Ajouter des observations sur d’autres interfaces et examiner le filtrage ou le traitement du chemin retour. |
Les échecs n’ont pas de relation stable avec la taille des paquets. | Examiner le comportement applicatif, les ressources des équipements et l’état de la liaison, en parallèle de l’hypothèse MTU. |
L’absence de message ICMP à un point de capture ne prouve pas qu’aucun équipement n’en a généré.
4. Tester dans les deux sens
Testez séparément les transferts du site industriel vers le poste de télémaintenance et ceux dans le sens inverse. Associez à chaque résultat la source, la destination et le chemin WAN. Une comparaison contrôlée sans VPN peut aider, mais elle concerne un autre chemin et doit être consignée séparément.
Ne changez pas simultanément la MTU, le MSS, le keepalive et le protocole VPN. Même si le transfert reprend, il devient difficile d’identifier la modification réellement efficace.
AJUSTER LA MTU OU LE MSS ?
Si le paquet encapsulé dépasse la capacité du chemin externe, consultez la documentation de l’implémentation VPN pour définir une MTU de tunnel adaptée. Si les retours ICMP nécessaires sont bloqués ou mal traités, corrigez leur traitement. Réduire la taille des paquets peut rétablir le service sans résoudre le défaut de retour sous-jacent : notez cette distinction.
Le MSS limite les données TCP
Le MSS TCP indique la longueur des données TCP, sans les en-têtes IP et TCP. Le plafonnement du MSS, ou MSS clamping, réduit la valeur annoncée dans les paquets d’établissement de connexion TCP lorsqu’ils traversent un point où cette règle s’applique. Il influence la taille des segments TCP que le correspondant enverra ensuite. Il diffère d’un changement de MTU d’interface et ne réduit pas directement les datagrammes UDP.
Pour une MTU IP interne effective préalablement déterminée à 1400 octets, la soustraction des seuls en-têtes fixes donne :
Version IP interne | En-têtes IP + TCP fixes | MSS illustratif |
|---|---|---|
IPv4 | 20 + 20 octets | 1360 octets |
IPv6 | 40 + 20 octets | 1340 octets |
La MTU de 1400 octets est une hypothèse de calcul, pas un réglage universel. La RFC 6691 impose aussi à l’émetteur de réduire la longueur réelle des données TCP pour tenir compte des options IP ou TCP qu’il ajoute. Ne remplacez pas cette MTU interne par celle du chemin externe dans le calcul.
La valeur du MSS est annoncée dans les paquets SYN, y compris SYN-ACK, et chaque annonce limite ce que l’autre extrémité doit envoyer, conformément à la RFC 9293. Après modification d’une règle de plafonnement, établissez de nouvelles connexions TCP et inspectez les deux sens. Une session existante ne suffit pas à démontrer que la nouvelle règle est active.
Distinguer les réglages des protocoles
Le manuel OpenVPN 2.6 décrit mssfix pour le trafic TCP à l’intérieur du tunnel et précise que cette option a un sens lorsque les pairs OpenVPN communiquent en UDP. Son argument mtu modifie le calcul de taille pour inclure les en-têtes IP et UDP externes. Ne considérez pas tun-mtu, mssfix et fragment comme interchangeables et ne transposez pas des réglages OpenVPN à WireGuard ou IPsec.
Pour du trafic UDP en échec, étudiez séparément la taille des datagrammes applicatifs, l’encapsulation et les mécanismes de sondage de l’implémentation. La DPLPMTUD utilise des sondes et des confirmations de réception pour découvrir les tailles utilisables sans dépendre de retours ICMP Packet Too Big. Sa disponibilité dépend de l’application ou de l’implémentation du protocole.
VÉRIFIER LA CORRECTION
Répétez le transfert d’origine sur le même chemin. Vérifiez qu’il se termine, contrôlez la taille et le contenu du fichier lorsque c’est pertinent, puis testez les deux sens avec de nouvelles connexions. Dans une installation multi-WAN, testez séparément chaque chemin WAN concerné : la PMTU peut changer lorsque le chemin change.
Conservez une fiche d’intervention succincte : symptôme initial, chemin testé, tailles réussies et échouées, retours observés, réglages avant et après modification, résultats des transferts et procédure de retour arrière. Si des paquets plus petits rétablissent le service sans que le goulot d’étranglement soit identifié, écrivez : « Service rétabli après ajustement de la taille des paquets ; goulot d’étranglement non encore localisé. »
Pour un équipement Wavetel, transmettez le modèle, le firmware, le type de VPN, la topologie et le relevé des tests au support technique. Confirmez les réglages MTU/MSS et les possibilités de capture réellement disponibles dans la documentation du firmware. La présence d’un protocole VPN dans une liste de fonctions ne prouve pas ces détails de configuration.
QUESTIONS FRÉQUENTES
Un ping réussi exclut-il un problème de MTU ?
Non. Il confirme seulement que cette sonde, de cette taille, a effectué l’aller-retour. Testez des paquets plus grands et le chemin réel de l’application, puis vérifiez si les échecs dépendent régulièrement de la taille des paquets.
Faut-il toujours utiliser une MTU de 1420 ?
Non. La taille utilisable dépend du chemin et de l’encapsulation. Une valeur adaptée à une connexion peut rester trop grande sur une autre, ou être inutilement basse. Appuyez-vous sur des observations reproductibles et sur la documentation de l’implémentation.
Pourquoi le changement de MSS ne suffit-il pas ?
Vérifiez qu’une nouvelle connexion TCP a été créée, que la règle s’applique dans le sens concerné et que les valeurs observées dans SYN/SYN-ACK ont changé. Le trafic UDP et les pannes sans rapport avec la taille des paquets demandent une investigation distincte.
Le keepalive WireGuard aide-t-il les grands paquets ?
PersistentKeepalive maintient les associations NAT ou les états de connexion du pare-feu pendant les périodes d’inactivité. Il ne change pas la capacité du chemin. Il peut être pertinent pour un tunnel devenu inaccessible au repos, mais pas pour une limite de taille reproductible pendant des transferts actifs.
Commentaires