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'erreurssh <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?
la source
ping -c 1 -s $((5000-28)) -M do machine-iplequel est retourné 1500 - identique à la machinetracepath -n <ip>le confirme: 1500 est autorisé tout au long du trajet.-Taide dans ce cas?Réponses:
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. Essayezopenvpn --fragment 1200 -mssfix; si cela aide, augmentez la valeur jusqu'à ce qu'elle commence à se casser.la source
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.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é.
la source
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
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
comme cela a été proposé par Sebastian ici . Après cela, le VPN allait bien.
la source