Jumbo-кадри не роблять шлях VPN здатним нести пакети по 9000 байт

Ви ввімкнули кадри по 9000 байт у локальній мережі й чекали, що VPN стане швидшим. Він став повільнішим або взагалі перестав пропускати великі передачі. Jumbo-кадри — це локальна домовленість про канал; вони не розширюють шлях, який перетинає тунель.

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

Що насправді змінюють jumbo-кадри

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

Локальна домовленість, глобальні наслідки. У цьому вся плутанина.

Податок на інкапсуляцію

Тунель загортає ваш пакет усередину іншого. WireGuard поверх IPv4 UDP додає приблизно 60 байт накладних витрат; режим UDP у OpenVPN перебуває в тому самому діапазоні, а IPsec залежить від режиму й алгоритмів. Ці байти беруться з бюджету зовнішнього шляху, а не з повітря.

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

Арифметику варто зробити один раз. На шляху на 1500 байт інтерфейсу WireGuard потрібен MTU близько 1420, щоб інкапсульований пакет умістився. Поставте внутрішній інтерфейс на 9000, і кожному великому пакету знадобиться фрагментація, яку тунель виконати не може, або його буде відкинуто.

Знайдіть найменшу ланку на шляху

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

Відфільтрований ICMP — класична причина того, що велика передача зависає, а малі запити працюють добре.

Перевірте залежність від розміру, не розширюючи зміну

Візьміть показову передачу й збережіть початкові значення, щоб повернути їх назад. ping -M do -s 1472 перевіряє пакет на 1500 байт з установленим бітом DF; зменшуйте розмір, доки він не пройде. Якщо не проходять лише великі пакети, у вас проблема розміру, а не маршрутизації.

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

Коли великий MTU — правильний проєкт

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

Для звичайного публічного виходу припускайте 1500 або менше й дозвольте тунелю вибрати безпечний внутрішній MTU. RFC 8201 описує виявлення MTU шляху для випадку IPv6 і є корисною довідкою про те, як має працювати зворотний зв'язок.