MTU-фрагментация при туннелировании и проблемы UDP

Как работает MTU фрагментация при туннелировании и почему это ломает UDP-приложения

Туннелирование трафика — обычная штука, когда нужно сделать приватный канал поверх публичной сети. Но есть проблема с MTU (Maximum Transmission Unit). Когда туннельный протокол добавляет свои заголовки, итоговый пакет может стать больше, чем MTU физического интерфейса, и приходится фрагментировать. Для UDP-приложений это прям беда: пакеты теряются, задержки растут, всё лагает.

1. Что такое MTU и как оно влияет на передачу данных

MTU — это максимальный размер пакета, который можно передать по сети без фрагментации. Обычно для Ethernet это 1500 байт. Если пакет больше, его режут на куски, каждый летит отдельно, а на стороне получателя собирают обратно.

Фрагментация — это нормально для IP, но она создает лишнюю работу: каждый кусок имеет свой заголовок, а если один кусок потерялся, весь исходный пакет идет лесом. Для TCP это решается пересылкой, для UDP — нет.

2. Как туннелирование меняет структуру пакета

Когда делаешь туннель (например, IPv6-in-IPv4, GRE, IPsec), исходный пакет целиком пихается в новый пакет, а сверху добавляются заголовки туннеля. Допустим, для IPv6-in-IPv4 добавляется 20 байт IPv4-заголовка. В итоге размер пакета увеличивается на 20–50 байт, в зависимости от протокола.

Если исходный пакет уже почти 1500 байт, после добавления заголовков он станет 1520 байт. Такой пакет уже не отправить целиком — нужна фрагментация.

3. Механизм фрагментации при туннелировании

Фрагментация может быть на двух уровнях:

- **На уровне исходного протокола** — если у туннельного интерфейса MTU меньше, чем у физического. Например, MTU туннеля 1480 байт. Тогда исходные пакеты режутся до того, как попадут в туннель.

- **На уровне транспорта** — если туннельный пакет превышает MTU физического интерфейса, фрагментируется уже он сам, вместе с заголовками.

Второй вариант хуже: режется не исходник, а весь туннельный пакет. Получатель сначала собирает куски туннельного пакета, потом достает исходный. Если хоть один кусок потерян, весь пакет отбрасывается.

4. Почему UDP страдает сильнее TCP

У TCP есть встроенные штуки для обнаружения потерь и пересылки, а также Path MTU Discovery (PMTUD), который подстраивает размер сегмента под MTU пути. UDP — это протокол без соединений и без гарантий. При фрагментации:

- Потеря одного куска — потеря всей UDP-дейтаграммы.

- UDP не говорит отправителю, что надо уменьшить размер.

- Многие UDP-приложения (DNS, VoIP, видеозвонки, игры) не умеют сами восстанавливаться.

5. Проблема Path MTU Discovery для UDP

PMTUD для TCP работает через ICMP-сообщения "Fragmentation Needed" (тип 3, код 4). Но многие сети блокируют ICMP для защиты. В таком случае TCP может полагаться на тайм-ауты и пересылки, а UDP просто теряет пакеты без обратной связи.

Для UDP-приложений в туннелях это значит, что даже если отправитель пытается использовать PMTUD (через флаг DF — Don't Fragment), он не получит ICMP-сообщение и не узнает, что надо уменьшить размер.

6. Практический пример: потеря DNS-запросов через туннель

Пример: DNS-клиент шлет запрос размером 1400 байт через IPv6-in-IPv4 туннель. После добавления заголовков размер становится 1420 байт. Если MTU физического интерфейса 1500, фрагментация не нужна. Но если MTU снижен до 1400 (например, из-за PPPoE или VPN), пакет режется.

DNS-сервер получает два куска. Если один потерялся, запрос не обрабатывается. Клиент ждет тайм-аут (обычно 5-10 секунд) и повторяет. Для критичных по времени приложений (например, VoIP) такие потери неприемлемы.

7. Как MTU фрагментация влияет на реальные UDP-приложения

- **VoIP (RTP)**: пакеты голоса обычно маленькие (60-200 байт), но при туннелировании с большими заголовками (например, IPsec + UDP encapsulation) размер может вырасти. Фрагментация редка, но если MTU пути падает, начинаются потери, речь прерывается.

- **Видеоконференции (WebRTC)**: видеопакеты могут быть крупнее (до 1200-1400 байт). При туннелировании они легко превышают MTU, вызывая фрагментацию и артефакты видео.

- **Игры (UDP-based)**: пакеты состояния игры часто мелкие, но некоторые игры передают крупные обновления (карты, текстуры). Фрагментация приводит к "вылетам" или задержкам.

- **DNS over HTTPS/TLS**: хотя это TCP-based, DoH использует HTTP/2, который фрагментирует данные на уровне приложения, но транспортный слой может страдать от тех же проблем.

8. Стратегии обхода проблемы для UDP-приложений

- **Настройка MTU туннеля**: уменьшение MTU на туннельном интерфейсе до 1400-1450 байт предотвращает фрагментацию на транспортном уровне. Но это надо настраивать вручную, и не всегда возможно.

- **Использование UDP-Lite**: протокол, который позволяет передавать данные с частичной защитой контрольной суммой. Фрагментация обрабатывается иначе, но поддержка ограничена.

- **Прикладная фрагментация**: приложение само режет данные на части, которые гарантированно влезают в туннель. Например, DNS-клиенты могут отправлять запросы не больше 1232 байт (рекомендация RFC 6891).

- **Обнаружение MTU пути через ICMP с тайм-аутами**: если приложение может ждать, оно может слать пробные пакеты с DF-флагом и уменьшать размер, если нет ответа. Но для реального времени это не подходит.

9. Технические ограничения IPv6 туннелей

IPv6-туннели (например, 6in4, 6rd) добавляют 20-40 байт служебной информации. Если исходный IPv6-пакет уже имеет MTU 1500, после инкапсуляции в IPv4 размер становится 1520-1540. Это гарантированно превышает MTU большинства сетей, если не настроить специальный MTU на туннеле.

Провайдеры IPv6-туннелей, такие как lexic.ml, дают чистые IPv6-адреса с огромным пулом, но технически туннелирование требует правильной настройки MTU на стороне клиента. Без этого UDP-приложения будут страдать от потерь.

10. Как тестировать и диагностировать проблему

- **Использование ping с DF-флагом**: `ping -M do -s <размер> <адрес>` покажет, при каком размере начинается фрагментация.

- **tcpdump или Wireshark**: захват трафика покажет, есть ли фрагментированные пакеты (флаги More Fragments, смещение).

- **Проверка ICMP-сообщений**: если сеть не блокирует ICMP, можно увидеть "Fragmentation Needed" от промежуточных маршрутизаторов.

- **Тестирование UDP-приложения**: отправка тестовых UDP-пакетов с разным размером через туннель и проверка по

терям. Оптимальный MTU для туннеля обычно на 40-80 байт меньше стандартного. Настройте на клиенте MSS clamping или уменьшите MTU интерфейса — и UDP заработает без потерь.