MTU без боли: почему размер пакета ломает VPN и как это чинить быстро

Введение: что такое MTU и почему это вообще важно

MTU простыми словами

MTU — это максимальный размер IP-пакета, который интерфейс может передать без фрагментации. Если грубо, это потолок в дверном проеме сети: выше — не пролезет. Ширина двери фиксирована, а коробка с данными должна влезть целиком. Разумеется, когда мы говорим о VPN, коробка становится пухлее из-за дополнительной обертки туннеля, и вот тут начинаются танцы с бубном.

Стандартная MTU для Ethernet — 1500 байт. Для IPv6 — минимальный гарантированный по пути размер 1280 байт. В дата-центрах встречаются jumbo frames — 9000 байт, но это локальная роскошь. В реальном интернете, особенно через 4G/5G, CGNAT и Wi‑Fi, доступный по пути MTU часто «выпуклый»: где-то 1500, где-то 1472, а где-то и 1400. Мы же с вами хотим, чтобы VPN работал без сюрпризов, верно?

Зачем MTU важен для VPN

Любой VPN добавляет overhead. Туннель накладывает свои заголовки поверх исходного пакета. Допустим, у вас WireGuard поверх UDP в IPv4. Заголовки IP и UDP плюс заголовок WireGuard — суммарно около 60 байт. Было 1500, стало 1440 максимально возможных полезных данных внутри туннеля. Если вы этого не учли, пакеты начинают фрагментироваться или, хуже, пропадать, потому что по пути кто-то режет ICMP и ваш Path MTU Discovery ослепнет. Результат — «страшные тормоза», подвисания сайтов, неоткрывающиеся страницы с картинками и таймауты в RDP. Неприятно? Еще как.

MTU против MSS: не путайте теплое с мягким

MTU — про IP-уровень. MSS — про TCP. MSS (Maximum Segment Size) — это максимальный размер полезной нагрузки TCP без заголовков IP и TCP. Когда говорят «сделайте MSS clamping», имеют в виду принудительное уменьшение MSS на границе, чтобы TCP-потоки сразу сегментировались правильно и не упирались в потолок MTU. Это костыль? Скорее, страховка на скользкой дороге: вы не чините асфальт, но снижаете риск аварии.

Как неправильный MTU ломает VPN-подключения

Симптомы: распознаем беду по звуку

Картинка не грузится полностью. Сайт открывается, но половина запросов висит. Почта отправляется со второй попытки. Видео рывками. RDP отваливается при копировании файла. Пинг идет, но браузер «думает» слишком долго. Это классика «blackhole MTU»: пакеты с DF-битом слишком большие, где-то по пути их сбрасывают, ICMP «Fragmentation needed» не приходит, TCP делает ретрансмит и уменьшает окно. Все медленно, но «почти работает». От этого бесит еще сильнее.

Реальные кейсы: WireGuard, OpenVPN, IPsec

WireGuard: часто рекомендуют MTU 1420. Но если провайдер режет MTU до 1472, а вы поверх запускаете еще и VLAN или PPPoE, у вас внезапно остается 1380-1400. Решение — пересчитать и явно задать MTU интерфейса wg: например, 1380 или 1360. Компромисс, зато стабильно.

OpenVPN UDP: у него overhead более «тяжелый», особенно при использовании TLS-шифрования и дополнительных опций. Практический шаблон — tun-mtu 1500 и mssfix 1360, но на мобильных сетях часто лучше сразу 1400 для MTU туннеля и mssfix 1360 или даже 1320. Не стыдно начать с меньшего и постепенно поднимать.

IPsec с NAT-T: ESP в UDP с добавочными заголовками. Если есть PPPoE, откусит еще 8 байт. Плюс возможные заголовки для маркировки и контейнеров. Хорошая рабочая точка — 1400-1440 в зависимости от трассы и оборудования. На границе включаем MSS clamping до 1360-1380, чтобы TCP не фрагментировался.

Где тонко: мобильные сети, CGNAT, Wi‑Fi

4G/5G и CGNAT любят «подрезать» MTU, а ICMP по пути часто фильтруют. Итог — PMTUD ломается, толкаем данные «вслепую». В Wi‑Fi-шлюзах SOHO производители порой включают «защиту» от ICMP. Хороших намерений много, результата ноль. В 2026 году операторы активнее внедряют IPv6-only и транспорт поверх QUIC/HTTP3, что добавляет дополнительные слои инкапсуляции. Снова приходится считать байты, теперь и для UDP/QUIC поверх TLS.

Фрагментация, PMTUD и DF-бит: дружим с механикой сети

Как работает фрагментация в IPv4 и IPv6

IPv4 может фрагментировать пакеты по пути: если пакет крупный и стоит DF=0, роутер режет его на части, получатель собирает. Красиво на бумаге, плохо в жизни: фрагменты легче теряются, фаерволы их режут, производительность падает. IPv6 строго: фрагментация на отправителе, а не посредине, и минимальный MTU по пути — 1280. Поэтому в IPv6 ошибки MTU вылезают четче и больнее.

Path MTU Discovery: почему он ломается

PMTUD рассчитывает минимальную MTU по пути, опираясь на ICMP «Fragmentation needed» или «Packet too big». Если ICMP блокируют, PMTUD становится слепым, пакеты упираются в «потолок» и исчезают. Так рождается blackhole MTU. В 2026 многие включают PLPMTUD (Packetization Layer PMTUD) на уровне TCP: он тестирует разные размеры сегментов без опоры на ICMP. Но старые устройства и стек приложений не всегда дружат с этим в полях.

DF, ICMP и политика фильтрации

DF-бит запрещает фрагментацию по пути. Его ставят повсюду: в том числе при работе VPN, где фрагментация «снаружи» туннеля опасна. Если при этом ICMP режут, получаем тупик: фрагментировать нельзя, подсказать «сделай поменьше» тоже нельзя. Итог — зависшие TCP-сессии. Поэтому золотое правило: ICMP «Fragmentation needed» и IPv6 «Packet too big» должны проходить. Всегда. Даже если очень хочется «закрутить гайки» ради мнимой безопасности.

MSS clamping: когда и как это спасает

MSS против MTU: коротко и по делу

MSS clamping — это когда на границе мы «подкручиваем» MSS в TCP SYN, чтобы отправители не пытались отправлять слишком большие сегменты. Это не заменяет корректной настройки MTU, но страхует TCP-трафик приложений. UDP это не лечит, но 80% проблем с вебом снимает мгновенно.

Где настраивать MSS clamping

На Linux используем правила фаервола. На системах с nftables или iptables добавляем действие, которое переписывает MSS в SYN-пакетах. На MikroTik есть модули mangle для TCP. На Cisco и Juniper — политики firewall/zone-policies с tcp-mss. Критически важно делать это на границе туннеля, где трафик входит или выходит, чтобы подгонка MSS соответствовала реальному MTU инкапсуляции.

Подводные камни

Слишком маленький MSS снижает эффективность TCP, слишком большой — снова упираемся в потолок. Если вы меняете MTU туннеля, не забудьте пересчитать MSS. Классический расчет: MSS = MTU - 40 для IPv4 (IP+TCP=20+20), и MSS = MTU - 40 для IPv6 (там тоже 40, но структура другая). А затем вычитаем VPN-overhead, если clamping делаем не на конечном участке, а до инкапсуляции.

Диагностика проблем MTU: пошаговый подход

Быстрый алгоритм

1. Проверяем, есть ли симптомы blackhole: сайты частично грузятся, длинные запросы висят, RDP рвется.
2. Пингуем крупные размеры с DF. Для IPv4: «ping -M do -s SIZE адрес». Для IPv6: «ping -s SIZE -M do» может различаться по ОС. Задача — найти максимальный без фрагментации.
3. Запускаем tracepath или «traceroute --mtu», смотрим где уменьшается MTU.
4. Проверяем, проходит ли ICMP «Fragmentation needed» и IPv6 «Packet too big». Если нет — конфигурируем политику, разрешаем эти типы ICMP.
5. Снижаем MTU туннеля и включаем MSS clamping. Начинаем с безопасного значения (например, 1360-1380), поднимаем постепенно.

Инструменты: на практике

ping с DF/size: ищем максимальный «-s», который проходит без потерь. Для Ethernet и WireGuard часто верхняя планка 1380-1420, но проверяйте в вашей трассе. tracepath покажет оценку PMTU по пути. Wireshark поможет увидеть ICMP «Packet too big», если они все-таки приходят, и оценить, какой именно размер нужен. На Linux «ip link show dev wg0» и «ip route get» подскажут текущие настройки и PMTU по маршруту.

Тонкости разных протоколов

GRE и L2TP добавляют свой overhead и часто конфликтуют с PPPoE. IPsec ESP с NAT-T добавляет UDP и ESP-заголовки — легко потерять 60-80 байт. WireGuard аккуратен, но чувствителен к блокировке ICMP и нестабильному MTU в мобильных сетях. OpenVPN на UDP чаще страдает от фрагментации из-за склонности приложений к крупным отправкам и TLS-накладных.

Определяем минимальный MTU по пути

Методика проста: бинарный поиск с ping DF на 1400-1500, затем точная подстройка с шагом 10, потом 2. Полученную цифру минус 20-40 байт оставляем запасом на колебания пути. Да, путь меняется динамически: днем один оператор, ночью другой. Поэтому разумный запас спасает от сюрпризов.

Решения и тюнинг MTU для VPN в 2026 году

Рекомендованные значения по протоколам

• WireGuard поверх IPv4/UDP: начинайте с MTU 1380-1420. Для 5G и CGNAT чаще 1380-1400. Для IPv6 — не меньше 1280 внутри туннеля, но из-за инкапсуляции ставьте 1280-1360.
• OpenVPN UDP: tun-mtu 1400-1500, но mssfix 1360 как стартовая точка. На мобильных и Wi‑Fi лучше 1400/1360 или ниже.
• IPsec ESP NAT-T: MTU туннеля 1400-1440, MSS 1360-1380. Если PPPoE — ухдите еще на 8-12 байт вниз.
• GRE/L2TP: тестируйте трассу, часто 1400-1460, но с PPPoE готовьтесь к 1380 и ниже.

Автоматизация и управление

Скрипты, которые периодически проверяют PMTU и пересобирают MTU интерфейса, стали модой в 2026. Для WireGuard удобно использовать pre-up hooks в wg-quick и systemd-networkd с netlink, чтобы в момент поднятия туннеля запускать короткий тест, вычислять безопасное MTU и применять значение. Небольшой запас — 20 байт к результату теста вниз — экономит часы поддержки.

Политики на границе

Разрешайте ICMP типы «Fragmentation needed» и IPv6 «Packet too big». Это не дыра, это воздух для PMTUD. В ACL и security groups обязательно исключения для этих типов. Плюс, если у вас есть DPI или WAF, убедитесь, что они не режут ICMP по умолчанию. Это привычка из старых учебников, которая в 2026 выглядит архаично.

Тренды 2026: QUIC, MASQUE, BBRv3, 5G SA

QUIC и MASQUE приводят к тому, что VPN поверх HTTP/3 — не экзотика, а рабочая реальность. Overhead сложнее, а PMTUD для UDP тракта важнее вдвойне. BBRv3 в ядрах новых дистрибутивов улучшает поведение при потере пакетов, но не спасает от тупой фрагментации. В 5G SA и сетевом slicing операторы активно применяют оптимизации, которые могут менять доступный MTU на лету. Мы учитываем это динамикой: регулярный автотюнинг и мониторинг — must-have.

Безопасность и производительность: не навреди

Риски фрагментации

Атаки с перекрывающимися фрагментами, старые добрые teardrop-подобные истории, до сих пор встречаются в неправильных конфигурациях. Когда вы позволяете фрагментации, увеличивается поверхность атаки. VPN усиливает это, ведь у вас уже дополнительная инкапсуляция и сложный путь. Лучше не допускать фрагментации вообще: снижайте MTU и используйте MSS clamping.

QoS, ECN и TFO

MTU влияет на качество QoS: неправильные размеры ломают классификацию и очереди. ECN и TCP Fast Open могут дать прирост отзывчивости, но при blackhole MTU не спасут, а иногда усугубят из-за ложных ретрансмиссий. Начните с MTU, потом уже играйтесь в тонкости.

Мониторинг SLO

Ключевые метрики — SRT (server response time), RTT, packet loss, доля ретрансмиссий TCP, количество ICMP «Packet too big». Если растет доля RST и FIN с короткими сессиями — смотрите на MSS. Если увеличился time-wait шторм — пересмотрите MTU и clamping. Простой дешборд с корреляцией «MTU изменения — жалобы пользователей» зачастую раскрывает картину моментально.

Чек-листы и готовые шаблоны

Быстрый чек-лист MTU для VPN

1. Определите реальную планку PMTU по пути, не верьте «1500 по умолчанию».
2. Задайте MTU туннеля ниже безопасного значения с запасом 20-40 байт.
3. Включите MSS clamping на границе для TCP (1360 старт, затем подстройка).
4. Разрешите ICMP типов «Fragmentation needed» и «Packet too big».
5. Проведите A/B-тест на части трафика, посмотрите жалобы и метрики.
6. Автоматизируйте проверку PMTU при поднятии интерфейсов.

Шаблоны настроек: что и где подкрутить

• WireGuard: задайте MTU в конфиге интерфейса. Начинайте с 1380-1420. Тестируйте ping DF. Если есть PPPoE, снижайте дополнительно.
• OpenVPN: используйте параметры tun-mtu и mssfix. Если много мобильных клиентов, стартуйте с 1400/1360.
• IPsec: снизьте MTU на внутреннем интерфейсе туннеля и настройте MSS clamping. Учитывайте NAT-T и PPPoE.

Облака и провайдеры: нюансы

В 2026 многие облака поддерживают Jumbo внутри VPC, но на границе в интернет — суровая реальность 1500 (а то и меньше). Либо вы держите end-to-end контроль и ICMP, либо готовьтесь к «случайным» регрессиям производительности. Отдельная история — межрегиональные туннели через 5G-сети резервов: там MTU плавает в течение суток. Автотюнинг или статическое 1360 и забыли про боль.

SOHO и мобильные роутеры

Домашние и полу‑проф роутеры часто имеют скрытые опции «Block ICMP». Отключайте. Включайте MSS clamping в разделе «Firewall» или «Mangle». Для OpenVPN клиентских устройств не стесняйтесь «садить» mtu на 1400, если поддержка жалуется на «висит на 90% загрузки».

Распространенные мифы про MTU

«Меньше MTU — всегда лучше»

Нет. Слишком маленький MTU снижает эффективность: больше заголовков на ту же полезную нагрузку, больше пакетов, больше прерываний. Баланс важнее. Начните с консервативного значения и постепенно повышайте, если трасса стабильно выдерживает.

«1500 — закон природы»

Это удобная традиция Ethernet, а не догма. Через PPPoE, туннели, мобильные сети — реально меньше. Примите это и работайте с фактами трассы, а не с мифами из учебников.

«IPv6 всегда лучше MTU»

IPv6 строже с фрагментацией, поэтому ошибки MTU видны быстрее. Это хорошо, потому что боль ощущается сразу, а не размазано по ретрансмитам. Но «лучше» не значит «без настроек». Включайте PMTUD для IPv6, следите за ICMPv6 и не режьте «Packet too big».

Заключение: короткая выжимка и следующий шаг

Итог в одном абзаце

MTU — это про физику сети и здравый смысл. VPN добавляет байты, мир — шум и фильтрацию. Мы либо уважаем PMTUD и разрешаем ICMP, либо играем в угадайку и теряем часы в поддержке. Выбираем первое и спим спокойно.

Ошибки, которых стоит избегать

• Блокировка ICMP «Fragmentation needed» и «Packet too big».
• Надежда на «и так сойдет 1500», без теста трассы.
• Отсутствие MSS clamping для TCP.
• Игнорирование PPPoE и NAT-T overhead в расчетах.

Что делать дальше

1. Протестировать трассы ключевых направлений с DF и tracepath.
2. Задать MTU туннеля с запасом и включить MSS clamping.
3. Автоматизировать проверку при поднятии интерфейсов.
4. Добавить мониторинг показателей, связанных с MTU.

FAQ: короткие ответы на острые вопросы

Как быстро понять, что проблема именно в MTU?

Если «интернет как будто есть, но не грузится часть контента», особенно крупные ресурсы и загрузки обрываются — почти наверняка MTU. Проверьте ping с DF и большие «-s», сравните с tracepath. Если ICMP заблокирован, это почти стопроцентный маркер.

Какое значение MTU задать в WireGuard в 5G?

Начните с 1380. Если всё стабильно — поднимайте до 1400-1420. Если видите странные подвисания в пиковые часы — верните 1380. И не забудьте MSS clamping 1360.

Можно ли просто включить MSS clamping и не трогать MTU?

Это облегчит жизнь TCP, но не спасет UDP и не решит проблемы полностью. Корректный MTU плюс MSS clamping — лучший союз. Пропустить что-то одно — оставить «хвостик боли» пользователям.

Почему у меня локально все летает, а у удаленных сотрудников все ломается?

Разный путь — разная минимальная MTU. В офисе один провайдер и честные 1500, у сотрудника дома — CGNAT, Wi‑Fi и «умный» роутер, который режет ICMP. Итог — ваш идеальный MTU «на бумаге» не имеет ничего общего с реальной трассой.

IPv6 и VPN: какое минимальное MTU держать?

Не опускайтесь ниже 1280 внутри туннеля. Помните про накладные расходы инкапсуляции. Большинство сценариев прекрасно живут на 1280-1360. Обязательно разрешите ICMPv6 «Packet too big».

Насколько критично разрешать ICMP в проде?

Критично. Это как выключить фары и ехать по трассе. Да, есть PLPMTUD и ухищрения, но экономия на ICMP в итоге дороже — время инженеров и недовольные пользователи.

Что с QUIC/HTTP3 и MTU?

QUIC поверх UDP чувствителен к потере крупных датаграмм. Если MTU неверен, получите странные лаги и скачки скорости. Проверяйте PMTU, выбирайте консервативное значение и держите MSS clamping для TCP-потоков, которые всё равно будут рядом.