SSH se bloque via OpenVPN ? Mesurez d'abord la MTU du chemin

SSH se connecte, l'invite apparaît et la session meurt dès qu'une commande renvoie quelque chose de volumineux. L'écho fonctionne encore un instant, puis la connexion expire tandis que le client affiche toujours le tunnel comme actif. Une session saine jusqu'à l'arrivée des données bute généralement sur une limite de taille et non sur un défaut de SSH. Les contrôles ci-dessous sont ordonnés pour écarter d'abord l'explication la moins coûteuse.

Lisez la forme de la panne avant de toucher au profil

Les petits paquets passent, les pleins non. Une invite, une bannière ou une frappe tiennent facilement ; un listing de répertoire, un téléchargement ou un bloc collé non. La taille à laquelle le comportement change est l'indice, pas le fait que SSH soit le programme concerné.

Le mécanisme est la découverte de la MTU du chemin, qui dépend du retour d'information. TCP choisit une taille de segment et, lorsqu'un routeur en chemin ne peut pas transmettre le paquet résultant, il est censé le signaler par un message ICMP. L'encapsulation rend le paquet extérieur plus grand que l'intérieur, si bien que la taille utilisable dans un tunnel reste toujours sous le lien physique. Filtrez ces messages ICMP quelque part et l'émetteur ne reçoit jamais la correction, continue d'envoyer des segments pleins, et le paquet extérieur est jeté sans avertissement.

Mesurez le plafond des deux côtés

Comparez la MTU du tunnel au lien physique avant de modifier l'un ou l'autre. Un tunnel qui a copié la valeur physique vous a déjà dit où se situe l'écart.

Sondez depuis l'intérieur du tunnel avec une requête qui interdit la fragmentation, en abaissant la charge utile jusqu'au retour des réponses. L'argument de taille ne compte que la charge utile, donc le chiffre qui fonctionne reste toujours sous la MTU de l'interface. Rajoutez les tailles d'en-tête si vous avez besoin du chiffre de l'interface.

ip link show tun0
ping -M do -s 1380 10.9.0.1

Répétez la sonde contre l'adresse publique du serveur depuis l'extérieur du tunnel. Si les grandes sondes échouent aussi là-bas, la limite se trouve sur le chemin vers le serveur et aucune option de tunnel ne la déplacera. Cette comparaison vous évite de régler un client qui n'a jamais été le problème. Notez les deux résultats avant d'ouvrir un fichier de configuration.

mssfix et fragment font des travaux différents

mssfix plafonne la taille de segment que les connexions TCP à l'intérieur du tunnel annoncent pendant leur poignée de main. C'est le bon levier pour SSH, HTTPS et les copies de fichiers, ce qui explique pourquoi le blocage disparaît souvent dès qu'il est réglé. Il ne touche pas du tout aux charges utiles UDP.

Un tunnel qui transporte aussi un service UDP peut continuer d'échouer après la correction de SSH, et ce résultat trouble quiconque suppose qu'une option couvre tout.

fragment est l'autre mécanisme et un outil différent. Il découpe les paquets trop gros avant l'encapsulation, ne s'applique qu'au transport UDP, ajoute une surcharge par datagramme et est documenté comme dernier recours en cas de découverte cassée. Les deux réglages doivent concorder chez les pairs qui terminent le tunnel. Un côté qui plafonne pendant que l'autre fragmente produit des avertissements dans le journal et un comportement que personne ne peut prévoir à partir des fichiers.

Baisser la MTU de l'interface est l'option brutale

Réduire la MTU de l'interface aux deux extrémités est l'instrument brutal. Il annonce un chiffre plus petit à chaque émetteur interne, ce qui fonctionne, et il impute ce coût à tout le trafic plutôt qu'aux flux TCP qui en ont besoin.

Choisissez-la quand le tunnel transporte du trafic que vous ne pouvez pas plafonner, ou quand le client est un équipement dont vous ne contrôlez pas le profil. Appliquez-la symétriquement et notez la valeur à côté du profil. Un changement à moitié appliqué est pire qu'aucun, car il ressemble à un correctif.

Retestez avec le transfert qui s'est bloqué

Reconnectez-vous pour que les réglages se chargent, ouvrez une connexion neuve et répétez la commande qui s'est figée. La taille de segment se négocie lors de la poignée de main, donc une session qui a survécu à la reconnexion porte encore l'ancienne valeur. Un ping est un mauvais test ici, puisque toute la panne tient au fait que les petits paquets passent. Utilisez le listing, le téléchargement ou le collage qui a échoué.

Si le blocage persiste à une taille plus petite, regardez ailleurs : un pare-feu à états qui expire le flux, une adresse en double ou une route qui bouge à la reconnexion. Notez la taille de sonde qui a échoué et le réglage que vous avez modifié, car c'est ce couple qui rend le prochain rapport utile.