La session SSH via OpenVPN se coupe / se verrouille après quelques lignes

J'ai un grand nombre de PC sans ventilateur identiques exécutant debian 6 (ARM). La plupart d'entre eux sont connectés via comcast et fonctionnent correctement. Certains sont connectés aux modems «WiMax» et ont des problèmes de communication.

Plus précisément: si je passe à l'un d'eux et que j'essaie une commande comme «ps -ax», je récupère environ 3 lignes et la session est verrouillée. Si je le laisse reposer, il finira par une «session fermée par des pairs».

Ce que j'ai essayé:

• ssh -vvv → aucun message d'erreur
• ssh <user@host> 'command'→ cela retournera parfois la sortie complète de la commande. Parfois, il ne se connecte pas du tout.

Des suggestions sur d'autres choses à essayer?

J'ai trouvé que je peux exécuter certaines commandes avec succès: par exemple, appuyer sur retour une douzaine de fois ou plus est correct. cd ~puis lffonctionne comme le fait df -h. Je peux exécuter dfplusieurs fois avec succès, mais dès que j'essaie quelque chose avec plus de sortie (par exemple ls /etc), il se bloque.

Cela fait-il une différence que j'essaie de communiquer entre ces deux hôtes à l'aide d'OpenVPN?

Vous avez les symptômes d'un problème MTU : certaines connexions TCP se bloquent, de manière plus ou moins reproductible pour une commande ou une URL donnée, mais sans schéma global facilement discernable. Un symptôme révélateur est que les sessions ssh interactives fonctionnent bien tant que vous n'exécutez pas de commandes avec une sortie volumineuse. Voir Impossible d'accéder à certains sites https sous Linux sur PPPoE pour une explication.

OpenVPN a plusieurs options liées à MTU - recherchez «mtu» dans le manuel. Je n'ai pas assez d'expérience pour être sûr de l'option à changer. (Il est même possible que vous puissiez changer quelque chose dans la configuration du modem Wimax.) L'option la plus probable pour changer est mssfix: essayez de réduire la valeur jusqu'à ce qu'il corrige le problème. La valeur par défaut est 1450; quelque chose comme environ 1400 pourrait résoudre votre problème. Essayez openvpn --fragment 1200 -mssfix; si cela aide, augmentez la valeur jusqu'à ce qu'elle commence à se casser.

La réponse de Gilles est tout à fait correcte, mais il y a aussi une autre cause potentielle à cela.

Il y avait un bogue dans la version 2.3.0 d'OpenVPN qui déconnectait les clients lors de l'envoi de gros morceaux de données: https://community.openvpn.net/openvpn/ticket/263

Ce problème ne s'est produit que lors de l'utilisation de TCP. UDP n'était pas du tout affecté.

Nous avons eu le même problème, et c'était effectivement un problème de MTU. Cependant pour nous le problème n'était pas dans la configuration openVPN mais sur l'interface tun0.

Comment nous l'avons résolu: trouvez d'abord la taille maximale de paquet qui a traversé, avec

ping <host> -s 1500 -M do

et réduire la valeur de 1500 jusqu'à ce qu'une valeur passe (pour nous, 1350).

Une fois la bonne valeur trouvée, changez l'interface tun0 avec

sudo ip link set dev tun0 mtu 1350

comme cela a été proposé par Sebastian ici . Après cela, le VPN allait bien.