Clamping MSS sur une passerelle VPN : ce qu'il corrige et ce qu'il ne corrige pas

Les petites requêtes fonctionnent, les gros téléchargements se bloquent, et quelqu'un suggère le clamping MSS. Cette suggestion est assez souvent juste pour valoir un essai dans le bon ordre, et assez souvent fausse pour faire perdre un après-midi si on l'applique à l'aveugle. Les trois vérifications ci-dessous séparent un vrai problème de taille TCP d'un problème UDP, d'une découverte path-MTU cassée et d'un clamp qui ne voit jamais le handshake qu'il est censé réécrire.

Commencez par la forme de la panne

Une panne de taille a une signature : la connexion s'établit, l'authentification et les petites réponses réussissent, puis un transfert se fige indéfiniment dès qu'il a besoin d'un segment de taille pleine. Les pages qui chargent le texte mais ne finissent jamais une image sont la même panne à plus petite échelle. Si rien ne se connecte du tout, le problème est plus tôt sur le chemin et le clamping n'aidera pas. Un clamp ne peut pas réparer un handshake qui n'est jamais arrivé.

La signature existe parce que le handshake est l'endroit où la taille du segment est négociée. Chaque côté annonce une taille maximale de segment comme option TCP, et les émetteurs respectent l'annonce du pair. Si le chemin ne peut pas porter un segment aussi grand, la panne apparaît plus tard, quand l'émetteur en essaie enfin un.

Gardez le transport en vue pendant la lecture de ce symptôme. Le clamping est une réécriture d'option TCP, donc un appel voix ou vidéo qui se fige sous le même tunnel n'est pas un problème de MSS et n'en sera pas amélioré. Notez le transport avant de toucher à une option TCP.

Chiffrez le chemin, puis comparez-le au tunnel

Deux nombres comptent et ils sont souvent confondus. La path-MTU est le plus gros paquet que le chemin transporte sans fragmentation, et le MSS annoncé pour IPv4 est cette valeur moins les 40 octets d'en-têtes IP et TCP, ou moins 60 pour IPv6. L'encapsulation du tunnel consomme une partie du budget avant même que le paquet interne ne commence.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

Le ping avec le bit do-not-fragment vous dit si un paquet de cette taille de charge utile survit ; ajustez la taille jusqu'à l'échec et vous avez trouvé la limite du chemin empiriquement. La sortie de tracepath indique l'MTU découvert le long de la route, ce qui est plus rapide quand cela fonctionne et moins fiable quand un saut intermédiaire filtre les sondes.

Soustrayez maintenant la surcharge du tunnel. Un en-tête IP externe, un en-tête UDP et un en-tête propre au tunnel sortent tous des mêmes 1500 octets, donc l'MTU interne utilisable sur une base Ethernet typique est plus bas que ne le suggère le lien physique. Si l'MTU interne calculé est inférieur à ce qu'annoncent vos pairs, vous avez trouvé un vrai candidat au clamp et non une supposition. Si la valeur calculée est déjà au-dessus de l'annonce des pairs, arrêtez-vous ici et cherchez ailleurs.

Placez le clamp là où passe le handshake

Un clamp fonctionne en réécrivant l'option MSS dans les paquets SYN et SYN-ACK lorsqu'ils traversent la passerelle. Si la règle se trouve sur une interface qu'aucune des deux directions ne traverse jamais, la négociation se termine inchangée et le symptôme persiste, c'est pourquoi le placement décide du résultat plus que la valeur.

La direction est l'autre moitié. Clamper une seule direction corrige la moitié des flux et laisse le reste échouer d'une manière qui semble intermittente, alors appliquez-le aux deux directions du trafic transféré. La forme classique sous Linux pour une interface de tunnel est une règle mangle qui correspond aux paquets SYN :

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

Notez ce que fait réellement --clamp-mss-to-pmtu : il dérive la valeur de l'MTU de la route, ce qui n'est pas toujours le budget réel de charge utile du tunnel. Sur un tunnel basé sur une route où la route interne et le chemin externe diffèrent, une valeur explicite calculée lors de la vérification précédente est plus prévisible qu'une valeur automatique.

Vérifiez avec une nouvelle connexion et gardez le retour d'information vivant

Une connexion établie conserve le MSS qu'elle a négocié, donc tester sur la même session ne prouve rien. Ouvrez une nouvelle connexion après le changement et lisez la valeur négociée directement au lieu de la déduire d'un transfert qui se termine par hasard.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

La première commande indique le MSS de la socket avec son état de congestion, ce qui est la confirmation la plus rapide que le clamp a pris effet. La seconde confirme que la règle que vous croyez avoir ajoutée est la règle qui existe, dans la table où elle a été placée.

Protégez ensuite le mécanisme que vous n'avez pas corrigé. La découverte path-MTU dépend de l'arrivée des messages ICMP fragmentation-needed jusqu'à l'émetteur, donc un pare-feu qui les jette continuera de casser les gros transferts même avec un clamp correct. Autorisez ces messages pour le chemin du tunnel, ou acceptez que le clamping compense une politique que vous avez choisie.

Enfin, résistez à la tentation de traiter le clamp comme un bouton de réglage. Il contraint la taille du segment, ce qui coûte du débit sur des chemins qui n'en ont jamais eu besoin. Appliqué après les trois vérifications, c'est une réparation ciblée ; appliqué en premier, c'est un changement qui masque la panne d'origine et ajoute une seconde variable à chaque test ultérieur. Ce compromis mérite d'être fait délibérément, pas par défaut.

Notez la path-MTU mesurée, la surcharge du tunnel soustraite, la règle ajoutée et le MSS observé ensuite. Quatre nombres font du prochain incident une consultation plutôt qu'une enquête.