Слишком большой пакет IPv6: почему большие передачи через VPN замирают

Пинг работает, браузер загружает небольшую страницу, а передача файла зависает — и всё это по IPv6 через один и тот же туннель. Такая картина обычно означает, что отправитель так и не узнал реальный размер пути, а не то, что туннель медленный. IPv6 ожидает, что маршрутизаторы сообщат о проблеме сообщением Packet Too Big, а инкапсуляция добавляет накладные расходы ещё до того, как пакет достигнет внешней сети. Если это сообщение фильтруется, отправитель продолжает повторять размер, который не может пройти.

Маленькие запросы, большие остановки

Туннель заворачивает каждый пакет в ещё один заголовок, поэтому полезный размер внутри меньше размера снаружи. Пакет, рассчитанный на физический канал до инкапсуляции, после неё становится слишком большим. Маршрутизаторы IPv4 могут фрагментировать по пути, а маршрутизаторы IPv6 не делают этого за отправителя, поэтому отправитель должен подстраиваться сам. И эта подстройка полностью зависит от получения обратной связи.

Одного потерянного сообщения достаточно для классического симптома: рукопожатия и небольшие ответы проходят, а листинг каталога или загрузка встают каждый раз в одном и том же месте. Пользователи описывают это как медленный VPN, а журналы не показывают ничего плохого в аутентификации. Оба наблюдения верны, и ни одно из них не находит место неисправности.

Packet Too Big — это обратная связь, а не трафик

Сообщение ICMPv6 Packet Too Big несёт размер, который может принять следующий узел, и отправитель использует его, чтобы снизить свою оценку. Фильтровать его — всё равно что убрать дорожный знак и потом винить водителей. Правило, отбрасывающее весь ICMPv6, выглядит строгим, но ломает обнаружение пути на каждом канале, которому оно нужно. Сообщение — это управляющая информация о пути, а не полезная нагрузка приложения.

Выборочная фильтрация всё ещё разумна. Эхо-запросы и обнаружение соседей играют другую роль, чем сообщения об ошибках, и политика может обращаться с ними иначе. Следуйте документированным рекомендациям платформы по фильтрации, а не принимайте или отбрасывайте весь протокол, потому что RFC 8201 определяет, как эта обратная связь управляет обнаружением.

Проверяйте оба семейства адресов по отдельности

Проверяйте IPv6 отдельно, потому что успешная передача по IPv4 ничего не доказывает о пути IPv6. Затем захватите управляющие сообщения, пока большая передача висит. Две записи вместе либо показывают, что обратная связь уходит, либо доказывают, что она так и не дошла.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Пробник отправляет пакет с установленным битом do-not-fragment и сообщает размер, на котором он терпит неудачу, — это число, которое туннель должен вместить. Запрос маршрута называет интерфейс, который понёс бы адресата, так что вы знаете, какой MTU канала действует. Захват фильтрует ICMPv6 типа 2, сообщение Packet Too Big, и показывает, доходит ли оно вообще до этого узла. Если сообщение появляется в захвате, а передача всё ещё висит, отправитель его игнорирует, что переносит расследование в стек, а не в сеть.

Меняйте размер туннеля только после доказательств

Снижение MTU туннеля может скрыть отфильтрованное сообщение и убрать симптом, но ценой больших накладных расходов на каждый пакет. Это обход, а не диагностика, и он должен следовать за захватом, а не заменять его. Произвольно низкое значение тоже ничего видимо не ломает, поэтому живёт в конфигурациях годами. Меняйте его осознанно, записывайте значение и отмечайте, какое измерение его оправдало.

Когда вы управляете шлюзом, проверьте правило, которое отбрасывает сообщение, вместо отключения межсетевого экрана. Одно исправленное правило уже, чем исключение в политике, и гораздо проще защищается позже. Та же логика применима к тайм-аутам: не каждое зависание — проблема размера, и именно захват разделяет эти два случая.