ESP расшифровывает нормально, а внутренний пакет всё равно никуда не доходит

Счётчик приёма ESP растёт, туннель остаётся поднятым, а приложение так и не видит пакета. Расшифровка прошла, проверка целостности успешна, и затем получателю нужно было решить, чем на самом деле является защищённая полезная нагрузка. Именно на этом последнем шаге и появляется несоответствие формата, а снаружи это совсем не похоже на проблему межсетевого экрана.

Что вы видите, когда метка лжёт

Ничто в журнале клиента не отличает это от чёрной дыры маршрутизации. И то и другое даёт тайм-аут приложения рядом со здоровым туннелем, поэтому первыми обвиняют счётчики.

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

Тип живёт в трейлере

В обычном режиме туннеля IPsec защищённая ESP полезная нагрузка содержит полный внутренний IP-пакет. Поле следующего заголовка в трейлере определяет, что это за нагрузка, и это не порт TCP, не номер протокола во внешнем заголовке и не часть начального поля SPI и порядкового номера. RFC 4303 раздел 2.6 определяет его как поле типа нагрузки, то есть точное имя для точной задачи.

Значения, которые вам встретятся, малы и их стоит запомнить: IPv4 это 4 (0x04), а IPv6 это 41 (0x29).

Эти числа берутся из распределения номеров протоколов IANA, а не из местного обычая. Отправитель, объявляющий IPv4 и при этом упаковывающий пакет IPv6, создал несоответствие формата, и ни одно правило межсетевого экрана не исправит байты, противоречащие собственной метке.

Как отличить это от обычных подозреваемых

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

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

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

Чем ремонт не является

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

Если подтверждённое несоответствие исходит от реализации партнёра, сохраните минимальное очищенное воспроизведение и отнесите его в поддерживаемый канал этой реализации.

Проверяйте поток, а не счётчик

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

Запишите в тикет оба результата. Движение счётчика вместе с работающим потоком это исправление; одно лишь движение счётчика ровно то, что было у вас до начала.