VPN connecté, gros transferts bloqués : examiner le MTU
Les petites requêtes passent, les gros transferts bloquent : tester le MTU avec des preuves et limiter les changements au chemin concerné.
Situation critique : Le serveur répond au Ping par VPN et sa page de connexion s’ouvre, mais les téléversements ou le chargement complet de l’application bloquent. Cela peut correspondre à un problème de taille de paquet sans prouver la responsabilité du MTU. Pertes, restrictions du chemin et application restent possibles.
Choisir un test reproductible
Comparez le même fichier et la même destination avec et sans tunnel. Notez heure, type de connexion et résultat. L’objectif n’est pas de rétablir le service par hasard en changeant plusieurs réglages ensemble, mais de conserver une différence précise à retester.
Premiers contrôles sur Windows et IPv4
L’exemple utilise une adresse de documentation qui n’est pas censée répondre telle quelle. Remplacez-la par une destination autorisée et réactive sur le chemin du tunnel. L’option DF de ce test concerne IPv4.
ping /4 /n 2 /f /l 1472 192.0.2.10
ping /4 /n 2 /f /l 1400 192.0.2.10
netsh interface ipv4 show subinterfaces
En IPv4 sans options supplémentaires, convertir la taille des données Ping en taille du paquet IP ajoute normalement 28 octets d’en-têtes IP et ICMP. Une charge de 1472 octets correspond donc à un paquet de 1500 octets ; 1472 n’est pas, en soi, le MTU.
Une réponse explicite demandant la fragmentation, alors qu’une taille inférieure passe, renforce l’hypothèse. Un délai dépassé seul ne la prouve pas : ICMP peut être filtré sur le chemin ou à destination. Un petit Ping réussi ne valide pas non plus tous les transferts TCP.
Limiter la correction au même chemin
Essayez différentes tailles pour trouver la limite de réussite et relevez la valeur actuelle de l’interface. Si les preuves suffisent, testez le MTU du tunnel ou le MSS du chemin TCP selon la documentation du produit et dans ce seul périmètre. Une valeur comme 1400 n’est pas universelle ; la taille des données Ping ne doit pas être copiée sans calcul dans le MTU.
Vérifiez aussi le fonctionnement de PMTUD et les messages ICMP nécessaires. Modifier toutes les interfaces ou ouvrir tout le pare-feu ne donne ni diagnostic solide ni retour arrière clair. Si le changement ciblé échoue, restaurez la valeur précédente et passez à l’hypothèse suivante.
Le critère est le vrai transfert répété
Retestez plusieurs fois le même fichier, la même requête et le chemin aller-retour. Un Ping ou un court transfert réussi ne suffit pas. Je recommande un petit scénario de transfert pour chaque tunnel important, reproductible après changement d’opérateur ou d’équipement.
La décision utile : Mesurer la taille des paquets ; un VPN connecté ne garantit pas la santé du chemin de données.
Références techniques: Microsoft / Ping · RFC / PMTUD.
Pour poursuivre la lecture
Toutes les publications →
Accès SMB refusé : pas de contrôle total pour Everyone
Rétablir SMB après un changement de droits : distinguer partage et NTFS, corriger au plus juste et tester avec le vrai compte utilisateur.
Espace disponible, mais Linux répond No space left on device
Diagnostiquer les inodes épuisés et les fichiers supprimés mais ouverts sous Linux, sans nettoyage aveugle ni redémarrage généralisé.
SSH modifié, nouvelles connexions refusées : gardez la session
Récupérer SSH sur Ubuntu après un changement : préserver l’accès, trouver l’erreur et tester une nouvelle connexion avant de quitter.