Почему tcpdump показывает открытый текст IPsec только в одном направлении

Вы запускаете tcpdump на внешнем интерфейсе шлюза IPsec под Linux и видите две вещи сразу: входящие кадры ESP и, сразу за ними, расшифрованные внутренние пакеты. На выходе виден только ESP. Естественный вывод — ответы не отправляются или IPsec шифрует одно направление и забывает другое. Ни то, ни другое неверно.

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

Точка захвата решает, что вы видите

На обычном интерфейсе сокет AF_PACKET находится у уровня устройства. Пакеты, покидающие хост, сначала проходят обработку выхода IPsec, которая превращает внутренний сегмент TCP в датаграмму ESP или UDP-4500, и только потом достигают этого уровня. Приходящие пакеты копируются в сокет в момент прихода с провода, всё ещё зашифрованными, а расшифрованный результат становится виден позже, когда стек доставляет его локально или пересылает дальше.

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

Согласуйте фильтр со слоем, который имеете в виду

Выражение вроде tcp port 443 выбирает внутреннее соединение TCP. На выходе это соединение уже стало ESP к моменту обращения к сокету, поэтому фильтр ни с чем не совпадает. Если вы хотите считать защищённый трафик, фильтруйте вместо этого по внешней форме: протокол 50 для необработанного ESP или порт UDP 4500, когда используется обход NAT. Оба фильтра дают число пакетов, которое можно сравнить между двумя сторонами, что обычно и является причиной подсчёта. Ни один из них не говорит, был ли получен ответ на внутренний запрос.

Не относитесь к числу UDP 4500 как к числу пакетов ESP. IKE тоже использует этот порт для сообщений поддержания NAT-T и для инкапсулированного обмена, поэтому число включает трафик, который не является теми данными, что вы хотели измерить. Начальный обмен IKE по UDP 500 требует собственного фильтра, если вопрос именно в этом. Число, смешивающее управляющий трафик с данными, также делает любую оценку пропускной способности неверной на неизвестную величину. Отдельные подсчёты отвечают на отдельные вопросы.

Запишите фильтр рядом с вопросом, на который он отвечает. «Сколько ESP покинуло коробку» и «покинул ли веб-запрос коробку» — это разные измерения с разными фильтрами, и один захват не может решить оба. Без этой пометки два человека будут сравнивать числа, которые никогда не считали одно и то же.

Наблюдайте до преобразования, а не после

Если нужно увидеть исходящий открытый текст, переместите точку наблюдения раньше, до обработки выхода IPsec. NFLOG даёт вам крючок Netfilter, где правило может копировать выбранные пакеты в сокет в пользовательском пространстве, который tcpdump умеет читать. Руководство strongSwan по дампу трафика документирует этот подход именно по этой причине.

Совпадение с политикой ограничивает правило трафиком, который вот-вот войдёт в туннель. Именно -m policy --pol ipsec --dir out делает правило конкретным, вместо того чтобы логировать каждый пакет, который отправляет коробка. Затем читайте группу журнала с ограниченным захватом: небольшое число снимков и ограничение размера не дают диагностике превратиться в архив трафика. Ограниченный захват также легче передать рецензенту, не таща с собой постороннюю нагрузку. Решите число до начала, а не после того, как увидите, сколько пришло.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Выберите крючок по потоку. OUTPUT охватывает трафик, который порождает сам шлюз; транзит от клиента LAN проходит по цепочке FORWARD, и правило на OUTPUT никогда его не увидит. Адрес и порт выше — заполнители для одобренного тестового назначения.

Что доказывает наблюдение

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

Пустой журнал столь же неоднозначен. Проверьте счётчик пакетов правила, подтвердите направление, подтвердите, что поток действительно совпал с политикой IPsec, и подтвердите назначение. Только совпадающий счётчик на обеих сторонах превращает наблюдение в вывод. Затем сравните счётчики ассоциации безопасности на обеих сторонах для одной и той же контролируемой попытки, потому что счётчики SA — это авторитетная запись о том, что было защищено и отправлено.

Ещё одна ловушка: «открытый текст» здесь означает вне уровня шифрования IPsec. Внутренний сеанс HTTPS по-прежнему имеет собственный TLS. Захват декапсулированного пакета не расшифровывает TLS приложения, а читаемый HTTP там означает, что приложение никогда не использовало HTTPS.

Уберите за собой и сравните оба конца

Удалите именно то правило, которое вы вставили, по его владельцу, как только наблюдение закончено. Оставленное правило журналирования стоит процессорного времени на каждом совпадающем пакете и тихо создаёт проблему хранения данных. Удаляйте, повторяя правило с -D, а не очищая цепочку, которая вам не принадлежит.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Если развёртывание использует IPsec в пользовательском пространстве, интерфейс XFRM или аппаратную разгрузку, точки наблюдения смещаются, и этот рецепт может вообще не подойти. В случае libipsec документированное место наблюдения за внутренним трафиком — устройство TUN. Сначала определите путь, затем выберите точку, которая отвечает на вопрос, и ожидайте, что два направления будут выглядеть по-разному только тогда, когда вы смотрите на неправильную сторону преобразования.