OpenVPN через PPPoE: зменшувати link-mtu, tun-mtu чи mssfix?

Ping відповідає, DNS розв'язує, а кожна сторінка, якій потрібен повнорозмірний сегмент, зависає. На каналі, що додає власну інкапсуляцію, шлях тихо втрачає кілька десятків байтів бюджету, і профіль, написаний для чистого Ethernet, продовжує запитувати пакети, які лінія не може провести. З'єднання не повільне; воно відкидає саме ті пакети, які важливі.

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

Три параметри, три різних рівні

link-mtu — це зовнішній бюджет: зашифроване навантаження плюс заголовок OpenVPN, заголовок UDP і зовнішній заголовок IP. Він описує те, що залишає машину, і тому саме це число обмежує фізичний шлях.

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

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

Якщо задати link-mtu явно, OpenVPN віднімає власні накладні витрати, щоб вивести внутрішній MTU. Ці витрати не є фіксованою константою; вони залежать від шифру та автентифікації, тому значення, скопійоване з форуму, може бути неправильним на іншому профілі. Якщо задати і link-mtu, і tun-mtu, клієнт отримає дві суперечливі інструкції.

Виміряйте шлях, перш ніж вибирати число

Вимірюйте з фізичного інтерфейсу, а не зсередини тунелю, і пам'ятайте, що ping повідомляє корисне навантаження, а не розмір пакета. Додайте 28 байтів для заголовків IPv4 і ICMP, перш ніж порівнювати навантаження з кадром у 1500 байтів, і тримайте цю поправку на думці, коли партнер повідомляє інше число.

У клієнті Linux ping -M do -s 1472 забороняє фрагментацію і завершується невдачею, якщо пакет завеликий. Зменшуйте навантаження, доки воно не пройде, потім додайте 28, щоб отримати MTU шляху. PPPoE коштує 8 байтів, тому 1492 нормально для DSL. DS-Lite і деякі мобільні шляхи коштують 40 або більше, і відповідь зазвичай нижча, ніж припускає номінальна швидкість лінії.

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

Спершу обмежте TCP, потім зменште тунель

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

Зменшуйте внутрішній MTU, коли постраждалий трафік не є TCP. Служба UDP, тунель у тунелі або застосунок, що надсилає датаграми повного розміру, продовжать збоїти після обмеження MSS, бо ніщо не переписує розмір їхніх пакетів. У цьому випадку зменште tun-mtu або задайте link-mtu і дозвольте клієнту вивести внутрішнє значення, але ніколи обидва.

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

Чому малі проби продовжують працювати

Запити DNS, відлуння ICMP і рукостискання TCP усі значно нижчі за розмір, на якому стається збій. Тому тунель виглядає здоровим у кожній швидкій перевірці, тоді як рукостискання TLS і відповіді HTTP тихо збоять. Саме це поєднання, робочий traceroute і браузер, що зависає на першій великій відповіді, і є ознакою, яку треба шукати. Перш ніж братися за новий профіль, візьміться за пробу повного розміру.

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

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