OpenVPN mssfix : pourquoi un client se bloque lors de gros transferts

Un seul ordinateur portable se bloque sur les envois à travers le tunnel alors que tous les autres appareils du même serveur continuent de fonctionner. Ce schéma pointe vers un seul chemin, pas vers la configuration du serveur, et c’est l’entrée habituelle de la question mssfix. L’option peut aider, mais uniquement pour les connexions TCP qu’elle réécrit réellement. Connaître sa portée vous évite de modifier un serveur qui fonctionne pour sauver un seul client.

Ce que l’option réécrit

mssfix modifie la taille maximale de segment annoncée dans les handshakes TCP qui traversent le tunnel, afin que le côté émetteur choisisse des segments qui tiennent dans le budget encapsulé. Il agit sur le handshake, ce qui signifie qu’une connexion ouverte avant le changement conserve la valeur négociée.

Il ne réduit pas les datagrammes UDP et ne fixe pas la MTU du tunnel. Deux problèmes différents produisent le même symptôme : un émetteur TCP qui ignore la limite du chemin, et un chemin qui abandonne silencieusement les gros paquets, quelle que soit leur taille. mssfix traite le premier et ne fait rien pour le second.

Cette distinction explique les expériences décevantes. Régler une valeur plus petite sur un chemin à trou noir change la taille du segment mais pas l’abandon qui suit, donc le transfert échoue à un autre endroit.

La portée est TCP à l’intérieur du tunnel

Seul le trafic TCP est réécrit. Une session QUIC, un jeu ou une application qui envoie de gros datagrammes UDP conservera ses propres tailles de paquets, et si ce sont ces transferts qui se bloquent, le correctif relève plutôt de la MTU du tunnel ou du chemin. Lisez quel protocole utilise le transfert qui échoue avant de recourir à une option TCP, car la mauvaise couche a son propre correctif.

La direction compte aussi. Un réglage côté client affecte le trafic que ce client envoie dans le tunnel, tandis que le serveur couvre les flux qu’il achemine vers les clients. Si seuls les téléchargements entrants se bloquent, la valeur côté client n’est pas toute l’histoire.

Le nombre et le mot-clé ne sont pas portables

La version communautaire d’OpenVPN 2.6 accepte un mot-clé facultatif après la valeur. Avec mtu, le nombre décrit la taille du paquet extérieur, en-têtes IP et UDP compris ; sans lui, l’argument suit une autre convention de calcul. Une ligne copiée entre versions ne décrit donc pas le même budget de paquets. Consultez la page de manuel fournie avec la compilation que vous exécutez réellement, plutôt qu’un tutoriel pour une autre version.

La syntaxe ressemble à ceci :

mssfix 1400 mtu

Traitez 1400 comme un espace réservé, pas comme une recommandation pour votre chemin. Déduisez la valeur du chemin mesuré et de l’encapsulation réellement utilisée, et rappelez-vous que les clients sur des versions plus anciennes ou d’autres implémentations peuvent rejeter ou réinterpréter le mot-clé.

Confirmez d’abord sur le seul client

Mesurez le chemin depuis la machine qui échoue avant de changer quoi que ce soit. Une charge utile que le chemin peut transporter sans fragmentation est le nombre que vous cherchez :

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

La première sonde tient dans un paquet de 1500 octets une fois les 28 octets d’en-têtes ajoutés. Si elle échoue avec une erreur de fragmentation et que la plus petite réussit, la taille utilisable se situe quelque part entre les deux, et la surcharge du tunnel est retirée du haut.

Répétez ensuite le transfert qui s’est bloqué, sur une nouvelle connexion, et comparez. Si le client unique s’améliore tandis que les autres restent intacts, vous avez trouvé la portée du problème. Si tous les clients se bloquent, la valeur côté serveur est celle à revoir. Aucun des deux résultats ne justifie un changement sur un matériel qui n’a jamais été sur le chemin défaillant.