ICMP-редиректы и ваши маршруты VPN: что на самом деле меняется

Поток, который должен идти через туннель, выбирает другой следующий узел, и кто-то находит ICMP-редирект в перехвате. Это гипотеза, а не диагноз. Редирект — это подсказка маршрутизатора о лучшем следующем узле, и то, станет ли хост ей следовать, зависит от настроек, которые различаются по платформе, по интерфейсу и по семейству адресов.

Редирект — это подсказка от маршрутизатора

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

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

Именно на этом различии ошибается большинство расследований редиректов.

IPv4 и IPv6 доставляют его по-разному

В IPv6 аналогичный механизм находится внутри обнаружения соседей, а не в ICMPv4, с другими форматами сообщений и другими правилами проверки. Понятия рифмуются, пакеты нет. Фильтр перехвата, написанный для типа ICMP 5, ничего не покажет в сети IPv6, и это иногда читают как доказательство того, что редиректа не было.

Настройки политики тоже раздельные, поэтому хост может принимать редиректы IPv4 и игнорировать IPv6, или наоборот.

Проверяйте оба семейства, если рассматриваемый поток может использовать любое из них.

Приём — это политика хоста, а не факт сети

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

Настройки безопасных редиректов дополнительно ограничивают, каким шлюзам можно верить.

Если вы ужесточаете хост, просматривать нужно именно эти параметры, и они же объясняют, почему две машины в одной сети могут вести себя по-разному. Меняйте их как политику, а не как лазейку при отладке.

Чего редирект объяснить не может

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

Устаревший перехват — вторая ловушка, ведь клиент, сменивший сеть, имеет другой локальный шлюз.

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

Проверьте маршрут, прежде чем винить туннель

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

Редирект никогда не должен быть причиной того, что защищённый путь тихо становится незащищённым, поэтому политика приёма относится к проектной проверке. Определение в RFC 792 остаётся ориентиром для того, что может сообщать IPv4-сообщение.

Запишите результат проверки маршрута и метку времени перехвата вместе, и следующий человек сможет воспроизвести ваш вывод.