Почему блокировка всего ICMP ломает работающий путь VPN
Сообщения обратной связи о размере — это не ответы ping. Когда они не приходят, мелкие пакеты проходят, крупные исчезают, и туннель выглядит мерцающим.
Туннель, который проходит аутентификацию, переносит ping и затем зависает на первой большой передаче, — классический признак отсутствующего сообщения ICMP, а не сломанного VPN. Отправитель так и не узнаёт, что пакет был слишком большим, повторяет тот же размер, а приложение ждёт. Исправление — это решение политики межсетевого экрана, а не переустановка клиента. Порядок важен: измерьте, где находится граница размера, затем сузьте правило, которое проглотило отчёт.
Что ICMP на самом деле переносит на этом пути
Обнаружение MTU пути IPv4 опирается на то, что маршрутизатор сообщает: пакет с установленным битом don't-fragment не удалось переслать. Это сообщение ICMP Fragmentation Needed, и без него у отправителя нет причины уменьшать размер сегмента. IPv6 строже: маршрутизаторы не фрагментируют в транзите, поэтому сообщение ICMPv6 Packet Too Big — единственный сигнал, заставляющий отправителя уменьшаться.
Оба сообщения — обратная связь плоскости управления, и ни одно не является диагностическим эхом. Политика, блокирующая ping, и политика, блокирующая весь ICMP, выглядят похоже в списке правил, но в сети ведут себя совершенно по-разному. Вторая может превратить правильно рассчитанный туннель в односторонний путь для всего, что больше самого малого звена в цепочке.
Некоторые транспорты реализуют собственное обнаружение с помощью зондирующих пакетов, как описывает RFC 4821, и они меньше зависят от этой обратной связи. Это аргумент проверить, какой транспорт вы используете, а не предполагать, что любой туннель невосприимчив.
| Сообщение | Назначение на пути | Если заблокировано |
|---|---|---|
| ICMPv4 тип 3 код 4 | Пакет был слишком велик для следующего звена | Отправитель повторяет попытки и зависает |
| ICMPv6 тип 2 | Packet Too Big, эквивалент для IPv6 | То же зависание, без резервной фрагментации |
| ICMP тип 11 | Время истекло, используется traceroute | Диагностика теряет переходы, трафик продолжает идти |
| Запрос и ответ эха ICMP | Проверка доступности | Ping не проходит, путь может быть в порядке |
Сбой зависит от размера
Спросите, связан ли сбой с размером пакета. Страница входа, запрос DNS и короткий вызов API проходят, а загрузка файла, большой ответ или скачивание изображения зависают. Эта картина указывает на ограничение размера где-то между двумя концами, а не на аутентификацию или маршрутизацию. Успешный маленький ping почти ничего не говорит о том, где находится эта граница.
Внутри туннеля нужно учитывать два уровня: пакет полезной нагрузки и внешний инкапсулированный пакет. Внутренний отправитель может вести себя правильно, пока внешний путь меньше, чем предполагает туннель, поэтому важны и собственные настройки MTU туннеля, и физическое звено под ним.
Измерьте перед правкой правил
Зондируйте с битом don't-fragment и выбранным вами размером полезной нагрузки, от неисправного клиента к защищённому адресу:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7Полезная нагрузка 1472 байта плюс 28 байт заголовков — это пакет 1500 байт. Если большой зонд не проходит с ошибкой фрагментации, а меньший проходит, вы нашли границу; учтите накладные расходы туннеля и повторяйте, пока рабочий размер не станет стабильным.
Затем убедитесь, что разрыв — это сам отчёт. Если зонд не проходит молча, без ошибки и без ответа, сообщение, скорее всего, отбрасывается, а не доставляется, и подозреваемым является правило.
Сузьте правило, затем перепроверьте задачу
Исправление должно разрешать конкретные управляющие сообщения, а не весь протокол. На хосте с iptables форма — это разрешение для конкретного типа; адаптируйте синтаксис к тому, что управляет межсетевым экраном на вашей платформе:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTОставьте ответы эха заблокированными, если это местная политика, поскольку пути они не нужны. Затем перепроверьте передачу, которая изначально не удалась, из нового соединения и убедитесь, что счётчики правила показывают приход сообщений.
Если большая передача всё ещё зависает после разрешения сообщений, оставшееся ограничение находится в другом месте: слишком высоко заданный MTU туннеля, прокси, переписывающий пакеты, или промежуточное устройство, которое отбрасывает вместо того, чтобы сообщать. Правило ICMP было необходимым, но не достаточным.