OpenVPN: Як пом'якшити проблеми MTU на кожному клієнті?

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

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

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

Сторінка OpenVPN пропонує ряд варіантів, пов'язаних з MTU, особливо --link-mtu, --tun-mtu, --fragment and --mssfix. Але це також говорить

--link-mtu [...] Цей параметр найкраще не встановлювати, якщо ви не знаєте, що робите.

--tun-mtu [...] Найкраще використовувати параметри --fragment та / або --mssfix для вирішення питань розміщення MTU.

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

Наступні параметри є законними у конкретному для клієнта контексті: --push, --push-reset, --iroute, --ifconfig-push та --config.

Немає згадки про варіанти MTU!

Ось ось мої конкретніші запитання:

Чому саме так link-mtuі tun-mtuвідволікати? Які потенційні проблеми з цими варіантами? Зауважте, що мені дуже зручно з низьким рівнем обміну IP-заголовком.
Який із варіантів link-mtu tun-mtu fragment mssfixнеобхідно відобразити на сервері, щоб працювати?
У якому з варіантів link-mtu tun-mtu fragment mssfixможна використовувати client-config-dir?
У випадку, якщо всі чотири варіанти мають бути відображені на дзеркальній стороні сервера, і їх не можна використовувати всередині client-config-dir: Чи є альтернативи для боротьби з низьким ступенем MTU на клієнта?

Примітки:

Запитали Частини моїх запитань вже 5 років тому тут , але вони на насправді не були , то огризались, тому я смію їх дублювати.
На даний момент сервер OpenVPN працює на 2.2.1 на Ubuntu 12.04. Ми готуємо оновлення до 2.3.2 на Ubuntu 14.04
Клієнти OpenVPN є 2.2.1 на Debian 7.6
Я радий сам визначити шлях клієнта-MTU вручну
В даний час ми не можемо тестувати багато на сервері. Але ми будуємо повний окремий тестовий шар, має бути готовим незабаром.

Я вдячний за будь-яку корисну пораду.

ip openvpn mtu ip-fragmentation

— Нілс Тедтман
джерело

576? Шановний гауд. Я не бачив такої низької MTU з часів комутації. Це переходить через давнє послідовне посилання?

— Майкл Хемптон

Чи можете ви запустити два сервери OpenVPN? Можливо, ви можете запустити обидва сервери на одній загальнодоступній IP-адресі та використовувати переадресацію портів (або політику маршрутизації) для спрямування клієнтів на інший сервер OpenVPN залежно від того, вони знаходяться у відомій проблемній мережі чи ні (як визначено списком клієнта) IP-адреси).

— kasperd

@MichaelHampton Я теж задумався. Це> 600 кбіт / с і RTT ~ 30 мс, не схоже на стародавній серійний для мене. Зважаючи на те, що вони мають інші дурні налаштування (наприклад, не відповідають на DF з "фрагментацією необхідної"), я думаю, це лише інший. Ми сказали їм, але ще не чули.

— Нільс Тодтманн

@kasperd цікава ідея. Я міг запускати кілька екземплярів сервера OpenVPN. Для різних діапазонів MTU повинно бути 3 або 4. NAT-сервер на клієнта NAT не працював (я не можу передбачити динамічні IP-адреси публічного клієнта), але мені доведеться все-таки змінити конфігурацію клієнта для налаштувань MTU (правильно?), Тому я просто налаштувати інший порт прямо в клієнта. - Але це було б кошмаром технічного обслуговування, якого я вважаю за краще уникати!

— Нілс Тодтманн

@NilsToedtmann Які критерії ви б використали, щоб визначити, на які клієнти впливають? Ще одним підходом може бути запуск сценарію на сервері після підключення клієнта. Сценарій може спробувати відімкнути IP-адресу клієнта з різними розмірами пакетів, щоб визначити, які працюють, а які - ні. Потім він може вставити iptablesправила для зменшення MSS у всіх SYN-пакетах до або з IP-адреси цього клієнта.

— kasperd

Я вирішив проблему на стороні клієнта, додавши параметр mssfix 1300у конфігураційний файл.

Із відкритої сторінки manv:

--mssfix max
    Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.

Оригінальна ідея мого рішення виникла з personalvpn.org

— Oz123
джерело

Отже, mssfixчи можна встановити лише клієнтську? Ну, це, принаймні, щось. Це не допомагає з пакетами UDP (саме тому мене зацікавили інші параметри, але принаймні рекомендовані fragmentпотрібно також встановити на стороні сервера)

— Nils Toedtmann

mssfix можна додавати як на сервер, так і на клієнт. Однак менша вартість буде використана в переговорах

— Ахмед

Зважаючи на відсутність відповідей, я розміщую зараз не дуже елегантне, але просте рішення: запустіть інший екземпляр OpenVPN на TCP для "поганих клієнтів"

proto tcp

і знизити TCP MSS на клієнті, наприклад

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ${OUT_DEV} -j TCPMSS --set-mss ${PATH-MTU-MINUS-40}

Перевагою цього рішення є те, що кожен клієнт може встановити свою індивідуальну MSS.

Це, звичайно, TCP-над-TCP, але це повинно працювати досить добре у багатьох сценаріях .

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

— Нілс Тедтман
джерело