Mam dużą liczbę identycznych bez wentylatorów komputerów z systemem Debian 6 (ARM). Większość z nich jest połączona za pośrednictwem Comcast i działa dobrze. Niektóre są podłączone do modemów „WiMax” i mają problemy z komunikacją.
W szczególności: jeśli ssh do jednego z nich i wypróbuję polecenie takie jak „ps -ax”, dostanę około 3 wierszy z powrotem, a następnie sesja zostanie zablokowana. Jeśli pozwolę temu usiąść, ostatecznie zakończy się „sesją zamkniętą przez peera”.
Co próbowałem:
ssh -vvv→ brak komunikatów o błędachssh <user@host> 'command'→ czasami zwróci to pełny wynik polecenia. Czasami w ogóle się nie łączy.
Sugestie dotyczące innych rzeczy do wypróbowania?
Przekonałem się, że mogę z powodzeniem wykonywać niektóre polecenia: np. Kilkakrotne naciśnięcie klawisza return jest w porządku. cd ~a następnie lfdziała tak jak działa df -h. Mogę uruchomić dfwiele razy z powodzeniem, ale gdy tylko spróbuję czegoś z większą mocą wyjściową (np. ls /etc), Blokuje się.
Czy to ma znaczenie, że próbuję komunikować się między tymi dwoma hostami za pomocą OpenVPN?
źródło
ping -c 1 -s $((5000-28)) -M do machine-ipktórym zwróciło 1500 - tak samo jak maszynatracepath -n <ip>potwierdza to: 1500 jest dozwolone przez całą drogę.-Tpomaga w tym przypadku?Odpowiedzi:
Masz objawy MTU problemu: niektóre połączenia TCP zamrażać, mniej lub bardziej powtarzalny dla danej komendy lub URL, ale bez łatwo dostrzegalnego ogólnego wzoru. Charakterystycznym objawem jest to, że interaktywne sesje ssh działają dobrze, o ile nie uruchamiasz poleceń o dużej wydajności. Aby uzyskać wyjaśnienie, zobacz Nie mogę uzyskać dostępu do wybranych witryn https w systemie Linux za pośrednictwem PPPoE .
OpenVPN ma kilka opcji związanych z MTU - wyszukaj „mtu” w instrukcji. Nie mam wystarczającego doświadczenia, aby mieć pewność, którą opcję należy zmienić. (Możliwe jest nawet, że możesz coś zmienić w konfiguracji modemu Wimax.) Najbardziej prawdopodobną opcją jest
mssfix: spróbuj obniżyć wartość, aż problem zostanie rozwiązany. Domyślna wartość to 1450; coś w rodzaju około 1400 może rozwiązać twój problem. Spróbujopenvpn --fragment 1200 -mssfix; jeśli to pomaga, zwiększaj wartość, aż zacznie się łamać.źródło
mssfix 1200na serwerze i restartowania. Na razie w porządku. Jeśli to zadziała, zwiększę go do 1300 lub 1400 i zobaczę, co się stanie. Jednak zbyt wielu klientów zmienia wszystkie zdalne konfiguracje, więc strona serwera będzie musiała to zrobić.Odpowiedź Gillesa jest całkowicie poprawna, ale jest też inna potencjalna przyczyna.
W wersji 2.3.0 OpenVPN wystąpił błąd, który odłączał klientów podczas wysyłania dużych porcji danych: https://community.openvpn.net/openvpn/ticket/263
Ten problem występował tylko podczas korzystania z protokołu TCP. UDP pozostało całkowicie nienaruszone.
źródło
Mieliśmy ten sam problem i rzeczywiście był to problem MTU. Jednak dla nas problem nie polegał na konfiguracji openVPN, ale na interfejsie tun0.
Jak to rozwiązaliśmy: najpierw znajdź maksymalny rozmiar pakietu, przez który przeszedł
i zmniejszanie wartości 1500, aż wartość przechodziła (dla nas 1350).
Po znalezieniu właściwej wartości zmień interfejs tun0 za pomocą
jak zaproponował tutaj Sebastian . Po tym VPN działał płynnie.
źródło