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


12

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?


Assurez-vous que votre chemin MTU n'est pas inférieur à votre interface configurée MTU. SSH ne se fragmente pas, donc avec le jeu de bits DF, les paquets sont supprimés à la place. Lisez ceci pour une explication beaucoup plus détaillée.
Aaron Copley

1
J'ai essayé de définir MTU sur toutes les interfaces à 1400 sans effet apparent. Testé avec ping -c 1 -s $((5000-28)) -M do machine-iplequel est retourné 1500 - identique à la machine
ethrbunny

1
tracepath -n <ip>le confirme: 1500 est autorisé tout au long du trajet.
ethrbunny

1
Pardonnez mon ignorance, mais comment -Taide dans ce cas?
Aaron Copley

2
<Lit le deuxième paragraphe> C'est un problème MTU. <Pour en savoir plus> Oui, problème de MTU. Voir ce fil pour une explication. Je ne vote pas pour fermer en double car il y a un point que l'autre thread ne discute pas: ce que vous devez changer dans votre configuration VPN pour résoudre le problème.
Gilles 'SO- arrête d'être méchant'

Réponses:


11

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.


Commence par mettre mssfix 1200sur le serveur et redémarrer. Jusqu'ici tout va bien. Si cela fonctionne, je vais monter à 1300 ou 1400 et voir ce qui se passe. Trop de clients pour changer toutes les configurations distantes, donc le côté serveur devra le faire.
ethrbunny

Je savais que c'était MTU!
Aaron Copley

3

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é.


3

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.