Як покращити надійність OpenVPN через високу затримку?

Ми запускаємо VPN OpenVPN через супутникове посилання BGAN, де тривалість пінг - близько 3 секунд. Ми використовуємо його в конфігурації tun , і ми працюємо на Linux (CentOS). Це в основному електронна пошта буде надіслана через посилання, але як тільки пошта містить великі вкладення, VPN, здається, зупиняється.

«Я можу свистіти через тунель, але будь-яка реальна робота змушує його замкнути. Є чи це проблемою MTU?» Питання в OpenVPN FAQ , здається , щоб описати мою проблему точно, але з використанням mssfixі до fragmentсих пір , здається, не зробити багато , щоб поліпшити ситуацію.

Моє основне тестування - скопіювати файл 2MB через VPN за допомогою scp . Він скопіює близько 192 кбайт, а потім повідомить про стан - затримка - . Якщо я зачекаю пару секунд, воно знову почне копіювати, а потім знову зупиниться через ще пару кілобайт.

Це затримка відбувається, незалежно від того, я встановив параметри fragmentабо mssfixпараметри в моїй конфігурації OpenVPN (хоча налаштування fragment 1000, здавалося, зменшує затримку, але не усуває її). OpenVPN mtu-testповідомив про 1542 як розмір MTU.

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

Мої запитання тоді:

• Коли я використовую mssfixі fragment?
• Чи використовую я mssfixі fragmentв поєднанні?
• Якщо mssfixі fragmentце рішення, які tun-mtu, link-mtuі mtu-discпараметри?

Крім того, я використовував інструмент iperf для вимірювання пропускної здатності. Без VPN він постійно вимірює порядку 210 Кбіт / сек.

При використанні iperf через VPN ( $ iperf -c remoteserver -t60 -i5) він починається зі швидкістю 10 Кбіт / сек, потім стабільно піднімається вгору, поки не повідомить про 1,2 Мбіт / с, а потім, здається, зупиниться, де він повідомляє 0 кбіт / сек за ряд ітерацій (я думаю, що 1,2 Мбіт / сек може бути через деяку буферизацію OpenVPN тощо.

Чи найкращий спосіб вимірювання пропускної здатності є iperf ?

Будь-яка допомога в цій ситуації буде дуже вдячна.

1542 як МТУ? Ніколи про це не чули за посиланням WAN. Зазвичай MTU - це максимальна корисна навантаження, розмір ip пакета за вирахуванням заголовка для IP (20 байт) та ICMP (8 байт). Це означає MTU = 1500 для традиційної Ethernet LAN. Крім того, більшість VPN вводять накладні витрати на інкапсуляцію пакетів. Типовий VPN MTU - 1400.

У сучасних мережах важко зробити висновок про те, якою буде MTU в будь-який момент, оскільки шляхи входу та виходу можуть бути різними, а також можуть змінюватися через автоматичне перенаправлення шляху. У такій мережі може бути ефективніше встановити MTU низько на своїх хостах, які знаходяться по обидва боки посилання VPN, наприклад 576.

MSS (максимальний розмір сегмента) - MTU мінус IP + заголовки TCP (40 байт). Зазвичай це узгоджується мережевим стеком і зазвичай не має тих самих питань переговорів, що й MTU, якщо MTU не помиляється. (Узгодження MTU зазвичай порушується заблокованими ICMP або маршрутизаторами чорних дір).

Перше, що я зробив би - зробити захоплення мережевих пакетів на своєму відправляючому кінці та сортувати відображення за розміром кадру (можливо, вам потрібно буде додати цей стовпець у Wireshark). Ви повинні переконатися, що ви не надсилаєте жодних кадрів з великим розміром, якими ви б їх очікували. Сучасні мережеві картки не є незвичайними для надсилання кадрів негабаритного розміру, якщо такі параметри, як Large Send Offload або Jumbo Frames включені. Я бачив 30 000+ байтових кадрів, коли ці параметри включені.

Щойно з цікавості ви спробували знизити MTU мережевого інтерфейсу? Можливо, супутниковий зв’язок погано розкручує фрагментацію. Як протиінтуїтивна примітка, ви можете спробувати openvpn через TCP для зміни. Я знаю, що це повинно зменшити продуктивність, але якщо ви не маєте контролю над фрагментацією по лінії, це може допомогти вам.

Під час використання TCP збільште розмір вікна TCP; це допоможе з "кількістю пакетів у повітрі".

Минув час, коли мені довелося пограти з цими речами, але ось для мене знайдено один посилання Google.

Після того як я перечитав ваше запитання, я бачу, що ви працюєте з BGAN - я б добре ознайомився з цим (або просто google для: "BGAN spoofing").

Що стосується вимірювання пропускної здатності, я вважаю, що iperf є досить пристойним, якщо ви використовуєте розумні розміри пакетів.

Я думаю, ти можеш гавкати на неправильному дереві. Кожного разу, коли у мене виникли помилки з питаннями MTU, трафік припинявся до 192 КБ. Я думаю, що це більше пов'язане з деяким у вікні "в пакетах польотів", або з вікном TCP, або, можливо, з деякими буферами в самій супутниковій висхідній лінії зв'язку.

Безумовно зробити деякі довгий Packet захоплень (як «всередині» і «зовні» в VPN) і подивитися , якщо ви отримуєте все ACK«S