OpenVPN mssfix: чому один клієнт зависає на великих передачах

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

Що переписує опція

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

Він не зменшує UDP-датаграми і не задає MTU тунелю. Дві різні проблеми дають однаковий симптом: TCP-відправник, що ігнорує обмеження шляху, і шлях, який мовчки відкидає великі пакети будь-якого розміру. mssfix вирішує першу і нічого не робить для другої.

Ця різниця пояснює розчарування від експериментів. Встановлення меншого значення на шляху з чорною дірою змінює розмір сегмента, але не подальше відкидання, тому передача зривається в іншому місці.

Обсяг — TCP усередині тунелю

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

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

Число й ключове слово не переносяться

Громадська версія OpenVPN 2.6 приймає необов'язкове ключове слово після значення. З mtu число описує розмір зовнішнього пакета, включно із заголовками IP і UDP; без нього аргумент дотримується іншої облікової конвенції. Тому рядок, скопійований між версіями, не описує той самий бюджет пакета. Перевірте сторінку посібника, що постачається зі збіркою, яку ви насправді запускаєте, а не підручник для іншого випуску.

Синтаксис виглядає так:

mssfix 1400 mtu

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

Спершу підтвердьте на одному клієнті

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

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

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

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