IPv6 MTU и Path MTU Discovery: Избегаем проблем фрагментации

Фрагментация пакетов — одна из тех проблем, которые вы не замечаете, пока она не ломает всё.

Почему MTU важнее в IPv6#

IPv6 полностью удалил фрагментацию на маршрутизаторах. В IPv4, если маршрутизатор получает пакет слишком большой для следующего транзитного участка, он может его фрагментировать. Маршрутизаторы IPv6 не могут этого делать — они отбрасывают пакет и отправляют ICMPv6-сообщение «Packet Too Big» обратно источнику.

Хост-источник отвечает за всю фрагментацию. Это проектное решение улучшает производительность маршрутизаторов и упрощает протокол, но перекладывает бремя на конечные точки и делает Path MTU Discovery (PMTUD) критичным.

Если PMTUD не работает, ваши соединения загадочно зависают. TCP-рукопожатия завершаются, но передача данных останавливается. HTTP-запросы истекают по таймауту. SSH-сессии замерзают после аутентификации. Это классические симптомы чёрной дыры MTU.

Минимальный MTU IPv6#

Все каналы IPv6 должны поддерживать как минимум 1280 байт. Это минимальный MTU, и это не обсуждается. Если ваш канал не может обрабатывать пакеты в 1280 байт, он не соответствует IPv6.

Большинство сетей использует 1500 байт (стандартный Ethernet MTU), что даёт место для 40-байтового заголовка IPv6 плюс 1460 байт полезной нагрузки. Это эквивалентно типичному TCP MSS IPv4 в 1460.

Туннели и протоколы инкапсуляции уменьшают доступный MTU. Если вы используете IPv6-in-IPv4 (6in4), 6to4 или ISATAP, вы теряете байты на внешний заголовок. VPN, IPsec, GRE и VXLAN — всё потребляет пространство MTU.

Распространённые значения MTU, с которыми вы столкнётесь:

• 1500: Стандартный Ethernet
• 1480: PPPoE (теряется 8 байт на накладные расходы PPP)
• 1460: Туннель 6in4 (теряется 20 байт на заголовок IPv4)
• 1420: 6in4 через PPPoE
• 1280: Минимальный MTU IPv6, резервное значение
• 9000: Jumbo-кадры (сети центров обработки данных)

Как работает Path MTU Discovery#

PMTUD определяет наибольший размер пакета, который может пройти путь между источником и назначением без фрагментации.

Процесс прямолинеен:

1. Хост отправляет пакеты с текущим MTU
2. Если маршрутизатор на пути имеет меньший MTU, он отбрасывает пакет
3. Маршрутизатор отправляет ICMPv6 Type 2 «Packet Too Big» обратно источнику
4. Сообщение включает MTU следующего транзитного участка
5. Хост уменьшает свой path MTU и повторно отправляет
6. Процесс повторяется, пока пакеты не пройдут весь путь

Сообщение «Packet Too Big» (ICMPv6 Type 2, Code 0) содержит значение MTU в полезной нагрузке сообщения. Это сообщает источнику точно, насколько большими могут быть пакеты, а не только что они слишком большие.

Вот как выглядит ICMPv6-сообщение:

ICMPv6 Packet Too Big:
  Type: 2
  Code: 0
  MTU: 1280
  [Заголовки исходного пакета до минимального MTU]

Хост поддерживает кэш path MTU с записями, которые обычно истекают через 10 минут (рекомендация RFC 8201). Если сетевые пути изменяются, устаревшие записи кэша могут вызывать проблемы до истечения.

Чёрные дыры PMTUD#

Система ломается, когда ICMPv6 Type 2 сообщения блокируются. Это создаёт «чёрные дыры PMTUD», где пакеты исчезают бесшумно.

Распространённые причины:

Чрезмерно ревностные межсетевые экраны: Администраторы иногда блокируют весь ICMP-трафик, рассматривая его как риск безопасности. Это неправильно. ICMPv6 является неотъемлемой частью работы IPv6, а не опциональным диагностическим протоколом, как ping.

Проблемы с stateful inspection: Некоторые межсетевые экраны не связывают правильно ICMPv6-сообщения об ошибках с существующими соединениями, отбрасывая их как незапрошенный трафик.

Ограничение скорости: Устройства безопасности могут ограничивать ICMPv6, отбрасывая легитимные PMTUD-сообщения в периоды загрузки.

Шлюзы NAT64: Трансляция между IPv6 и IPv4 может терять информацию PMTUD, если шлюз не переводит правильно ICMP-сообщения.

Симптомы чёрных дыр PMTUD:

• TCP-соединение устанавливается (SYN, SYN-ACK, ACK завершены)
• Маленькие пакеты работают (DNS-запросы, баннер входа SSH)
• Большие пакеты не работают (передачи файлов, HTTP POST с телом, SSH-сессия после аутентификации)
• Нет сообщений об ошибках, только таймауты
• Проблема кажется прерывистой (зависит от размера пакета)

Диагностика проблем MTU#

Начните с ping. Отправляйте пакеты определённых размеров для тестирования path MTU:

# Тест с 1280 байтами (минимальный MTU)
ping6 -M do -s 1232 2001:db8::1
 
# Тест с 1500 байтами (стандартный Ethernet)
ping6 -M do -s 1452 2001:db8::1
 
# Тест с полезной нагрузкой 1280 байт
ping6 -c 5 -s 1280 2001:db8::1

Флаг -M do запрещает фрагментацию (don't fragment). Аргумент -s указывает размер полезной нагрузки — добавьте 8 байт для заголовка ICMPv6 и 40 для заголовка IPv6, чтобы получить общий размер пакета.

Если 1452 байта не работает, но 1232 успешно, ваш path MTU между 1280 и 1500. Двоичный поиск для точного значения:

# Попробуйте 1400
ping6 -M do -s 1352 2001:db8::1
 
# Попробуйте 1450
ping6 -M do -s 1402 2001:db8::1

Используйте traceroute для определения, где MTU изменяется:

traceroute6 -n 2001:db8::1

Затем тестируйте MTU для каждого транзитного участка индивидуально. Транзитный участок, где большие пакеты начинают не работать, — ваша проблемная точка.

Для TCP-соединений наблюдайте фактическое поведение:

# Захват пакетов
tcpdump -i eth0 -n 'ip6 and (icmp6 or tcp)'

Ищите:

• TCP-повторные передачи после начального рукопожатия
• ICMPv6 Type 2 сообщения (должны появляться, если PMTUD работает)
• Отсутствие ICMPv6 Type 2 (указывает на блокировку или чёрную дыру)

Современные инструменты могут автоматизировать это. MTR объединяет traceroute с тестированием размера пакетов:

# Тест с пакетами 1400 байт
mtr -6 -s 1400 2001:db8::1

TCP MSS Clamping#

MSS (Maximum Segment Size) — это опция TCP, которая сообщает другой стороне, сколько данных она может отправить в каждом сегменте. MSS = MTU - заголовок IP - заголовок TCP.

Для IPv6: MSS = MTU - 40 (IPv6) - 20 (TCP) = MTU - 60

С стандартным MTU 1500 байт: MSS = 1440

MSS clamping принуждает TCP-соединения использовать более низкое значение MSS, обходя проблемы MTU без зависимости от PMTUD. Это распространено на маршрутизаторах, которые завершают туннели или PPPoE-соединения.

Настройка MSS clamping в Linux:

# Ограничить MSS до 1280 для IPv6
ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1220

Значение 1220 учитывает MTU 1280 минус 60 байт для заголовков.

Для PPPoE с MTU 1492:

ip6tables -t mangle -A FORWARD \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1432

MSS clamping влияет только на TCP. UDP, SCTP и другие протоколы по-прежнему полагаются на PMTUD или фрагментацию на уровне приложения.

Конфигурация межсетевого экрана#

Ваш межсетевой экран должен разрешать ICMPv6 Type 2 сообщения для функционирования PMTUD. Это не обсуждается для производственных IPv6-сетей.

Минимально необходимые типы ICMPv6 для работы IPv6:

• Type 1: Destination Unreachable
• Type 2: Packet Too Big (PMTUD)
• Type 3: Time Exceeded
• Type 4: Parameter Problem
• Type 133-137: Neighbor Discovery Protocol

Правило iptables для PMTUD:

# Разрешить ICMPv6 Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

Лучший подход — разрешить все необходимые ICMPv6:

# Разрешить установленный ICMPv6
ip6tables -A INPUT -p ipv6-icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
 
# Разрешить необходимые типы ICMPv6
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 1 -j ACCEPT    # Destination Unreachable
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT    # Packet Too Big
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 3 -j ACCEPT    # Time Exceeded
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 4 -j ACCEPT    # Parameter Problem
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -j ACCEPT  # Echo Request
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT  # Echo Reply
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 133 -j ACCEPT  # Router Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 134 -j ACCEPT  # Router Advertisement
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -j ACCEPT  # Neighbor Solicitation
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -j ACCEPT  # Neighbor Advertisement

Ограничение скорости приемлемо, но установите щедрые лимиты:

# Разрешить ICMPv6 с ограничением скорости
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 \
  -m limit --limit 10/sec --limit-burst 20 -j ACCEPT

Никогда полностью не блокируйте ICMPv6. Это не риск безопасности — это требование протокола.

Соображения MTU для туннелей#

Туннели уменьшают эффективный MTU на величину накладных расходов заголовков инкапсуляции.

Распространённые типы туннелей и накладные расходы:

Настройте MTU туннеля явно, чтобы избежать проблем:

# Туннель 6in4
ip tunnel add tun6in4 mode sit remote 203.0.113.1 local 198.51.100.1
ip link set tun6in4 mtu 1480
ip link set tun6in4 up

Для WireGuard:

[Interface]
MTU = 1420

Некоторые протоколы туннелей поддерживают обнаружение MTU, но явная конфигурация более надёжна.

Jumbo-кадры и центры обработки данных#

Сети центров обработки данных часто используют MTU 9000 байт (jumbo-кадры) для улучшения пропускной способности при массовых передачах.

Включение jumbo-кадров на интерфейсах:

ip link set eth0 mtu 9000

Убедитесь, что все коммутаторы и маршрутизаторы на пути поддерживают jumbo-кадры. Одно устройство с MTU 1500 байт станет узким местом.

PMTUD по-прежнему применяется. Если пакет покидает вашу jumbo-кадровую сеть в сторону Интернета, он должен уменьшиться до 1500 или менее.

Тестирование и проверка#

Проверьте конфигурацию MTU вашего хоста:

ip -6 link show

Ищите значение MTU на каждом интерфейсе.

Проверьте текущий кэш path MTU:

ip -6 route get 2001:db8::1

Вывод показывает кэшированный MTU для этого назначения.

Протестируйте сквозную связность с различными размерами пакетов:

for size in 1232 1352 1402 1452; do
  echo "Тестирование $size байт:"
  ping6 -M do -s $size -c 3 2001:db8::1
done

Используйте netcat для тестирования согласования TCP MSS:

# Сервер
nc -6 -l 8080
 
# Клиент
nc -6 2001:db8::1 8080

Захватывайте пакеты с tcpdump и проверяйте значения MSS в SYN-пакетах.

Распространённые сценарии и исправления#

Проблема: Веб-страницы загружаются медленно, изображения не загружаются Причина: Чёрная дыра PMTUD из-за блокировки межсетевым экраном ICMPv6 Type 2 Исправление: Настройте межсетевой экран для разрешения ICMPv6 Type 2

Проблема: SSH подключается, но замерзает после входа Причина: MTU слишком большой, PMTUD не работает Исправление: Уменьшите MTU на клиентском интерфейсе или включите MSS clamping на маршрутизаторе

Проблема: VPN работает для малых передач, не работает для больших файлов Причина: MTU туннеля настроен неправильно Исправление: Уменьшите MTU туннеля для учёта накладных расходов инкапсуляции

Проблема: IPv6 работает в локальной сети, не работает через Интернет Причина: Восходящий маршрутизатор имеет меньший MTU, не объявляет его правильно Исправление: Свяжитесь с ISP или уменьшите локальный MTU до 1280 (минимум)

Проблема: Некоторые назначения работают, другие не работают Причина: Проблемы MTU, специфичные для пути Исправление: Тестируйте с ping для определения работающего MTU, настройте интерфейс соответственно

Лучшие практики#

1. Всегда разрешайте ICMPv6 Type 2 в межсетевых экранах
2. Настраивайте MTU туннеля явно, а не полагайтесь на автообнаружение
3. Тестируйте с минимальным MTU (1280) для обеспечения базовой связности
4. Используйте MSS clamping на конечных точках туннелей и PPPoE-соединениях
5. Мониторьте сбои PMTUD с захватами пакетов при устранении неполадок
6. Документируйте MTU вашей сети на каждом уровне (физический, туннель, приложение)
7. Устанавливайте консервативные значения MTU в сомнениях (1280 всегда работает)

Связанные статьи#

• ICMPv6 объяснён — Понимание управляющего протокола IPv6
• Конфигурация межсетевого экрана IPv6 — Защита IPv6 без нарушения функциональности
• Устранение неполадок IPv6 — Отладка распространённых проблем связности IPv6

Дополнительные ресурсы#

• RFC 8201: Path MTU Discovery для IPv6
• RFC 4821: Packetization Layer Path MTU Discovery
• IPv6 MTU Issues - RIPE Labs