OpenVPN sur PPPoE : baisser link-mtu, tun-mtu ou mssfix ?

Les pings répondent, le DNS résout, et toute page qui a besoin d’un segment de taille maximale se bloque. Sur un lien qui ajoute sa propre encapsulation, le chemin perd silencieusement quelques dizaines d’octets de budget, et un profil écrit pour un Ethernet propre continue de demander des paquets que la ligne ne peut pas transporter. La connexion n’est pas lente ; elle jette exactement les paquets qui comptent.

Trois options peuvent corriger cela, et elles agissent à des couches différentes. Choisir la mauvaise ne fait rien ou rend le tunnel fragile d’une nouvelle façon, donc le choix commence par ce que le chemin supporte réellement.

Trois réglages, trois couches différentes

link-mtu est le budget extérieur : la charge chiffrée plus l’en-tête OpenVPN, l’en-tête UDP et l’en-tête IP extérieur. Il décrit ce qui quitte la machine, et c’est pourquoi c’est le nombre que le chemin physique contraint.

tun-mtu est le budget intérieur : l’interface que voit votre trafic. Il est plus grand que ce que le chemin peut transporter, exactement de la surcharge du tunnel, et OpenVPN le déduit normalement au lieu de vous obliger à le fixer.

mssfix est un mécanisme entièrement différent. Il réécrit la taille maximale de segment annoncée pendant les poignées de main TCP, pour que les pairs TCP choisissent des segments qui tiennent après l’encapsulation. Il ne change pas le MTU de l’interface et n’a aucun effet sur UDP.

Si vous fixez link-mtu explicitement, OpenVPN soustrait sa propre surcharge pour déduire le MTU intérieur. Cette surcharge n’est pas une constante fixe ; elle dépend du chiffrement et de l’authentification, et c’est pourquoi une valeur copiée d’un forum peut être fausse sur un autre profil. Fixer à la fois link-mtu et tun-mtu donne au client deux instructions contradictoires.

Mesurez le chemin avant de choisir un nombre

Mesurez depuis l’interface physique, pas depuis l’intérieur du tunnel, et rappelez-vous que ping rapporte la charge utile, pas la taille du paquet. Ajoutez 28 octets pour les en-têtes IPv4 et ICMP avant de comparer la charge utile à une trame de 1500 octets, et gardez cette correction en tête quand un pair rapporte un nombre différent.

Sur un client Linux, ping -M do -s 1472 interdit la fragmentation et échoue si le paquet est trop gros. Baissez la charge utile jusqu’à ce qu’il passe, puis ajoutez 28 pour obtenir le MTU du chemin. PPPoE coûte 8 octets, donc 1492 est normal en DSL. DS-Lite et certains chemins mobiles coûtent 40 ou plus, et la réponse est généralement inférieure à ce que suggère le débit nominal du lien.

Si toutes les tailles de ping réussissent mais que les gros transferts bloquent encore, soupçonnez un trou noir plutôt qu’une simple limite de taille. Un message ICMP de fragmentation nécessaire est filtré quelque part sur le chemin, donc l’émetteur n’apprend jamais à réduire, et seuls les flux qui ont besoin d’un gros segment le remarquent.

Limitez d’abord TCP, rétrécissez le tunnel ensuite

Les poignées de main TCP sont la seule chose que mssfix touche, ce qui en fait généralement le contrôle le moins perturbant à essayer en premier. Réglez-le un peu sous le budget réel du chemin, poussez la même valeur depuis le serveur pour que les deux extrémités soient d’accord, et retestez un gros téléchargement. Si le blocage disparaît, le problème était la taille de segment TCP, et rien d’autre n’a besoin de changer.

Baissez le MTU intérieur quand le trafic concerné n’est pas TCP. Un service UDP, un tunnel dans le tunnel ou une application qui envoie des datagrammes de taille maximale continuera d’échouer après un plafonnement MSS, car rien ne réécrit la taille de ses paquets. Réduisez tun-mtu dans ce cas, ou fixez link-mtu et laissez le client déduire la valeur intérieure, mais jamais les deux.

N’utilisez pas l’ancienne option de fragmentation. Elle découpait les paquets dans le tunnel, ajoutait de la surcharge et a été dépréciée pour de bonnes raisons ; l’OpenVPN moderne attend une description précise du chemin.

Pourquoi les petites sondes continuent de fonctionner

Les requêtes DNS, les échos ICMP et les poignées de main TCP sont tous bien en dessous de la taille qui échoue. Le tunnel paraît donc sain à chaque test rapide, tandis que les poignées de main TLS et les réponses HTTP échouent silencieusement. Cette combinaison, un traceroute qui fonctionne et un navigateur qui bloque sur la première grande réponse, est la signature à rechercher. Recourez à une sonde de taille maximale avant de recourir à un nouveau profil.

Vérifiez avec le trafic qui a échoué. Chargez une grande page, envoyez un datagramme UDP de taille maximale si c’est le service concerné, et répétez depuis un second client sur un autre lien. Notez le MTU de chemin mesuré et la valeur que vous avez choisie, car la personne suivante qui touchera le profil considérera sinon le nombre comme arbitraire.

Ne descendez jamais le MTU intérieur sous 1280 quand IPv6 passe sur le tunnel, car c’est le minimum que tout lien IPv6 doit transporter. Un MTU plus petit est un fait sur le chemin, pas un réglage de performance à ajuster au ressenti.