Réglage du MSS TCP sur une passerelle Linux IPsec : ce qu'il corrige

Le ping fonctionne, SSH fonctionne, une petite page se charge, puis chaque grande réponse reste bloquée jusqu'au délai d'expiration. Le schéma classique pointe vers la taille des paquets plutôt que vers l'accessibilité : le chemin transporte le handshake et les premiers kilo-octets, puis un segment de taille pleine disparaît. Sur une passerelle Linux IPsec, une règle TCP MSS est souvent la solution, mais seulement si vous comprenez ce qu'elle change et où se trouve réellement le paquet qu'elle touche. L'ordre ci-dessous suit le paquet du symptôme au placement de la règle, afin que vous puissiez vous arrêter dès que l'explication cesse de convenir.

Le symptôme qui suggère MSS

TCP négocie une taille maximale de segment lors du handshake. Si cette valeur est supérieure à ce que le chemin peut transporter après encapsulation, l'émetteur continue de produire des segments qui n'arrivent jamais, et la connexion bloque après le premier aller-retour. Les petites réponses passent ; les grandes non.

Le retour ICMP peut sauver la connexion grâce à la découverte du MTU du chemin, et un pare-feu qui supprime ces messages transforme le blocage en trou noir silencieux. C'est pourquoi le même tunnel fonctionne pour une application et échoue pour une autre sans différence visible dans la configuration.

Ce qu'une règle TCPMSS fait et ne fait pas

La règle réécrit l'option MSS dans les paquets de handshake TCP à leur passage. Elle ne fixe pas le MTU de l'interface du tunnel, elle ne change pas la politique IPsec, et sur les noyaux actuels elle ne fait que baisser une valeur annoncée au lieu d'en relever une déjà plus petite. Elle ne touche aussi que TCP ; les charges UDP, le comportement de DNS et les sélecteurs de trafic négociés sont hors de sa portée.

Comme le changement se produit pendant le handshake, une connexion existante établie avant la règle conserve son ancienne valeur. Testez avec une nouvelle connexion, et attendez-vous à ce que la première tentative après le changement soit celle qui vous apprend quelque chose. Rien dans la règle n'atteint une connexion déjà ouverte. C'est pourquoi une correction appliquée au milieu d'un incident peut sembler n'avoir absolument rien fait.

Placez la règle sur le chemin TCP interne

Sur une passerelle Linux basée sur des politiques, le paquet transféré ressemble encore à du TCP ordinaire lorsque le pare-feu le voit. La politique IPsec décide que le paquet sera protégé ; le pare-feu ne voit pas d'en-tête ESP pour le flux interne, donc faire correspondre ESP ici décrit un paquet entièrement différent. Ce décalage explique pourquoi certaines règles semblent correctes et ne correspondent jamais.

En termes d'iptables, la règle appartient à la table mangle sur le chemin de transfert, limitée aux paquets de handshake : iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. Le nombre est un exemple, pas une constante universelle ; déduisez-le de la surcharge d'encapsulation et du MTU réel du chemin. Un équivalent nftables définit la taille maximale de segment dans une chaîne forward ou postrouting.

Gardez les règles d'écoute externes pour IKE et ESP séparées des règles de transfert internes. Une seule règle qui tente d'autoriser à la fois le flux de l'application et le protocole externe finit par ne correspondre de manière fiable à aucun des deux.

Respectez le propriétaire du pare-feu et l'ordre du NAT

Si UFW gère le pare-feu de l'hôte, ajoutez les changements mangle et de transfert via sa configuration persistante prise en charge plutôt qu'en tapant une commande qui disparaît au prochain rechargement. Une règle insérée dans la mauvaise table ou après une règle terminale n'a aucun effet, et la table active vous le cache.

La traduction de source est une décision distincte qui interagit souvent avec celle-ci. Une exception placée avant une règle générale de masquerade empêche le trafic protégé de perdre la source que sa politique exige ; elle ne répare pas un problème de taille, et une règle de taille ne répare pas un problème de traduction.

Vérifiez étroitement, puis arrêtez

Ouvrez une nouvelle connexion vers le service défaillant et surveillez à la fois l'application et les compteurs de la règle. Si le blocage disparaît, vous avez des preuves concernant ce chemin TCP avec cette encapsulation. Vous n'avez pas la preuve que chaque protocole VPN convient, que chaque application UDP est corrigée ou qu'un service amont précis était la cause d'origine.

Laissez le retour de taille ICMP fonctionner là où la politique le permet, et traitez avec prudence l'ajustement automatique basé sur le MTU de la route lorsque le chemin IPsec externe n'est pas représenté par la route interne. Plus la conclusion est étroite, plus le prochain incident est facile à diagnostiquer.