Сеанс SSH через OpenVPN відключається / блокується через кілька рядків


12

У мене є велика кількість однакових вентиляторних ПК, на яких працює debian 6 (ARM). Більшість з них підключені через comcast і працюють добре. Є деякі, які підключені до модемів "WiMax" і мають проблеми з спілкуванням.

Зокрема: якщо я сшу на один із них і спробую команду на зразок 'ps -ax', я отримаю приблизно 3 рядки назад, і тоді сеанс буде закритий. Якщо я дозволю йому посидіти, врешті-решт він закриється "сеансом, закритим однолітком".

Що я спробував:

  • ssh -vvv → відсутні повідомлення про помилки
  • ssh <user@host> 'command'→ це іноді поверне повний результат команди. Іноді він взагалі не зв’яжеться.

Пропозиції щодо інших спробу?

Я виявив, що я можу успішно виконувати деякі команди: наприклад, натиснути повернення десяток разів і більше - це нормально. cd ~а потім lfпрацює так, як робить df -h. Я можу запустити dfбагато разів успішно, але як тільки я спробую щось із більшою кількістю результатів (наприклад ls /etc), він закривається.

Чи має значення, що я намагаюся спілкуватися між цими двома хостами за допомогою OpenVPN?


Переконайтеся, що ваш MTU шлях не нижче, ніж налаштований інтерфейс MTU. SSH не фрагментується, тому з набором бітів DF замість них скидаються пакети. Прочитайте це для набагато більш детального пояснення.
Аарон Коплі

1
Спробували встановити MTU на всіх інтерфейсах до 1400 без видимого ефекту. Випробуваний, з ping -c 1 -s $((5000-28)) -M do machine-ipякого повернулося 1500 - те саме, що і машина
ethrbunny

1
tracepath -n <ip>підтверджує це: 1500 дозволено цілим шляхом.
ethrbunny

1
Пробачте за моє незнання, але як це -Tдопомагає в цьому випадку?
Аарон Коплі

2
<Читає другий абзац> Це проблема MTU. <Читає далі> Так, проблема з MTU. Дивіться цю нитку для пояснення. Я не голосую за те, щоб закрити як дублікат, тому що є один пункт, який інший потік не обговорює: що потрібно змінити у вашій конфігурації VPN, щоб виправити проблему.
Жиль "ТАК - перестань бути злим"

Відповіді:


11

У вас є симптоми проблеми MTU : деякі TCP-з'єднання замерзають, більш-менш відтворювані для даної команди чи URL-адреси, але без загальновизнаного загального шаблону. Показовим симптомом є те, що інтерактивні сеанси ssh працюють добре, доки ви не запускаєте команди з великим результатом. Див. Розділ Неможливо отримати доступ до вибраних https-сайтів у Linux через PPPoE для пояснення.

OpenVPN має кілька варіантів, пов'язаних з MTU - шукайте "mtu" в посібнику. У мене немає достатнього досвіду, щоб бути впевненим, який варіант потрібно змінити. (Можливо навіть, що ви можете щось змінити в конфігурації модему Wimax.) Найбільш вірогідний варіант зміни mssfix: спробуйте зменшити значення, поки воно не усуне проблему. За замовчуванням - 1450; щось на зразок близько 1400 може вирішити вашу проблему. Спробуйте openvpn --fragment 1200 -mssfix; якщо це допомагає, збільшуйте значення, поки воно не почне ламатись.


Починаю з установки mssfix 1200на сервері та перезавантаження. Все йде нормально. Якщо це спрацює, я підніму його до 1300 або 1400 і побачу, що станеться. Забагато клієнтів, щоб змінити всі віддалені конфігурації, хоча для цього доведеться робити сторону сервера.
ethrbunny

Я знав, що це MTU!
Аарон Коплі

3

Відповідь Жиля є абсолютно правильною, але для цього є й інша потенційна причина.

Була помилка у версії 2.3.0 OpenVPN, яка відключала клієнтів при надсиланні великих фрагментів даних: https://community.openvpn.net/openvpn/ticket/263

Ця проблема виникла лише під час використання TCP. UDP повністю не вплинув.


3

У нас була така ж проблема, і це справді була проблема МТУ. Однак для нас проблема була не в конфігурації openVPN, а в інтерфейсі tun0.

Як ми це вирішили: спочатку знайдіть максимальний розмір пакета, який пройшов, за допомогою

ping <host> -s 1500 -M do

і зменшуючи значення 1500, поки значення не пережило (для нас 1350).

Як тільки знайдено потрібне значення, змініть інтерфейс tun0 на

sudo ip link set dev tun0 mtu 1350

як запропонував Себастьян тут . Після цього VPN проходив гладко.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.