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

Прочитайте форму збою, перш ніж торкатися профілю

Дрібні пакети проходять, повні ні. Запрошення, банер або одне натискання клавіші вміщуються легко; список каталогу, завантаження або вставлений блок ні. Розмір, за якого поведінка змінюється, і є підказкою, а не факт участі SSH.

Механізм такий: виявлення MTU шляху, яке залежить від зворотного зв'язку. TCP обирає розмір сегмента, і коли маршрутизатор на шляху не може переслати утворений пакет, він має повідомити про це повідомленням ICMP. Інкапсуляція робить зовнішній пакет більшим за внутрішній, тому корисний розмір усередині тунелю завжди нижчий за фізичний канал. Відфільтруйте ці повідомлення ICMP будь-де, і відправник ніколи не отримає виправлення, надсилатиме повні сегменти, а зовнішній пакет буде відкинуто без попередження.

Виміряйте стелю з обох боків

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

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

ip link show tun0
ping -M do -s 1380 10.9.0.1

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

mssfix і fragment роблять різну роботу

mssfix обмежує розмір сегмента, який TCP-з'єднання всередині тунелю оголошують під час рукостискання. Це правильний важіль для SSH, HTTPS і копіювання файлів, тому зависання часто зникає щойно його встановлено. Він зовсім не торкається навантажень UDP.

Тунель, що несе й службу UDP, може й далі давати збої після виправлення SSH, і цей результат бентежить кожного, хто вважає, що один параметр покриває все.

fragment — інший механізм і інший інструмент. Він ділить завеликі пакети до інкапсуляції, діє лише для транспорту UDP, додає витрати на кожну дейтаграму і задокументований як останній засіб при зламаному виявленні. Обидва налаштування мають збігатися в партнерів, які завершують тунель. Коли один кінець обмежує, а другий фрагментує, виникають попередження в журналі й поведінка, яку ніхто не передбачить із файлів.

Зниження MTU інтерфейсу — грубий варіант

Зменшення MTU інтерфейсу на обох кінцях — грубий інструмент. Він каже кожному внутрішньому відправнику менше число, що працює, і перекладає цю ціну на весь трафік, а не на TCP-потоки, яким вона потрібна.

Виберіть його, коли тунель несе трафік, який ви не можете обмежити, або коли клієнт — пристрій, профілем якого ви не керуєте. Застосовуйте симетрично і записуйте значення поруч із профілем. Наполовину застосована зміна гірша за жодну, бо вона виглядає як виправлення.

Перевірте знову тим передаванням, що зависло

Перепідключіться, щоб налаштування завантажилися, відкрийте нове з'єднання і повторіть команду, що завмерла. Розмір сегмента узгоджується під час рукостискання, тому сеанс, який пережив перепідключення, досі несе старе значення. Ping тут погана перевірка, бо весь збій у тому, що дрібні пакети проходять. Використайте той список, завантаження або вставлення, що зламалися.

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

Схожі статті