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 и служит полезной справкой о том, как должна работать обратная связь.