Pourquoi un VPN se bloque sur les gros transferts et pas sur les petits

Une page se charge, un ping réussit et une copie de fichier se bloque toujours au même endroit. Ce schéma pointe la taille des paquets plutôt que la bande passante ou les identifiants. L'encapsulation ajoute des octets à chaque paquet, si bien qu'une charge utile qui tenait sur le chemin d'origine peut dépasser la limite une fois tunnelisée. Dans ces conversations, trois nombres différents sont appelés MTU, et les confondre mène à un réglage qui corrige une application et en casse une autre.

Trois nombres que l'on appelle MTU

La MTU d'interface est la limite configurée pour un paquet sur ce lien. La MTU de chemin est la plus petite limite le long de la route ; elle se découvre au lieu de se configurer. La MSS TCP est la taille de charge utile qu'un pair annonce pouvoir recevoir, et elle dérive des deux autres au lieu d'être une limite physique distincte.

Un tunnel a une vue intérieure et une vue extérieure. Le paquet extérieur transporte le paquet encapsulé plus les en-têtes dont le protocole a besoin, donc la taille intérieure utilisable est plus petite que ce que permet le chemin extérieur. Le chemin vers le serveur VPN diffère aussi du chemin du serveur vers la destination.

La découverte de la MTU de chemin permet à un émetteur de connaître la taille qui fonctionne, mais elle dépend de l'arrivée des retours. Quand un appareil intermédiaire filtre les messages ICMP concernés, l'émetteur continue d'envoyer des paquets qui n'aboutissent jamais, et c'est le trou noir classique. Le symptôme est caractéristique quand on le connaît : la poignée de main réussit, la première charge utile de taille pleine disparaît, et la connexion finit par se réinitialiser ou se bloquer. Rien dans le journal de l'application ne ressemble à un problème réseau.

Sondez le chemin avec une charge utile que vous contrôlez

Une sonde est une preuve sur une route et une taille, pas un réglage recommandé. Utilisez un hôte qui répond et ne faites varier que la taille de la charge utile.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

La première commande envoie une sonde Linux avec la fragmentation désactivée et une charge utile de 1372 octets, et la seconde fait de même sous Windows, où la charge utile se règle avec -l. Une réponse signifie que cette taille a survécu au chemin. Un message de fragmentation nécessaire est instructif, tandis qu'un délai d'attente est ambigu car l'hôte ou un appareil intermédiaire peut simplement jeter l'ICMP.

Descendez la taille par quelques paliers au lieu de faire une recherche binaire jusqu'à l'octet. Vous cherchez à établir s'il existe un plafond de taille, non à publier un nombre pour chaque réseau. Le nombre trouvé vaut pour ce chemin, ce protocole et cette famille d'adresses.

IPv4 et IPv6 fragmentent différemment, donc un résultat de sonde d'une famille ne dit rien de l'autre. Testez la famille que l'application utilise réellement.

Le réglage MSS n'aide que TCP

En TCP, la charge utile effective est négociée pendant la poignée de main, et un routeur du chemin peut réécrire cette valeur à la baisse pour que les deux extrémités envoient des segments plus petits. C'est ce que fait le réglage MSS, et il fonctionne sans toucher au client du tout.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

La première règle ramène la MSS annoncée à la MTU de chemin pour les poignées de main TCP transférées, et la seconde montre la MTU propre à l'interface du tunnel afin que vous la compariez à ce que le chemin permet. Le réglage est la réparation la moins invasive pour une application TCP qui se bloque après la poignée de main.

Pour UDP, il ne fait rien. Un client vocal ou de jeu qui envoie de grands datagrammes ignorera complètement un réglage MSS, car il n'y a pas de poignée de main à réécrire. Si l'application défaillante est en UDP, regardez plutôt les options de taille de paquet du client lui-même. Les deux protocoles échouent différemment et se réparent avec des outils différents, c'est pourquoi le protocole appartient à la première phrase du ticket.

OpenVPN expose des options comme tun-mtu, mssfix et des réglages liés à la fragmentation, et leur comportement dépend de la version et du fait que le canal de données soit AEAD. Lisez le manuel de la version utilisée et changez une option à la fois.

Changez un seul réglage pris en charge et répétez les deux essais

Gardez le profil d'origine, changez une seule valeur prise en charge, et répétez à la fois la petite requête qui fonctionnait et le gros transfert qui échouait. Si seule la grande change, vous poursuiviez la taille. Si les deux changent, autre chose a bougé avec elle.

Une valeur plus basse peut réduire le symptôme tout en ajoutant de la surcharge, donc le plus petit nombre possible n'est pas le but. Le but est une taille que le chemin transporte de façon fiable avec le moins de gaspillage. Notez la valeur, le chemin et la version du client dans le ticket, car le même nombre appliqué ailleurs est une supposition.

Si le même profil fonctionne depuis un autre réseau de confiance, gardez cette différence dans le diagnostic au lieu de déclarer le client réparé. La variable qui a changé est le chemin, et le chemin est ce que la sonde a mesuré.