Хост доходит до IPsec-партнёра, контейнер Docker — нет

Вы пингуете удалённый хост с машины Linux, и он отвечает, значит туннель работает. Контейнер рядом всё ещё уходит в таймаут, и естественный следующий шаг — перезапустить Docker. Контейнер в мостовой сети обычно стартует с другого адреса источника и входит в хост через пересылку, а не через собственный выходной путь приложения на хосте, поэтому успешный тест измерил другой пакет. Для туннеля strongSwan на основе политик обычного маршрута к удалённой подсети недостаточно, когда пересылаемый пакет не соответствует установленной политике IPsec.

Ниже разбор прослеживает одну цель через два источника, читая состояние до того, как что-то менять.

Начните с одной цели и двух источников

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

Затем повторите неудачный запрос изнутри контейнера и зафиксируйте источник, который он действительно использует. Если этот адрес не покрыт локальным селектором, вы уже знаете результат, и никакое пересоздание контейнера этого не изменит.

Прочитайте политики, прежде чем трогать Docker

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

ip rule show
ip route show table all
ip xfrm policy

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

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

Проверьте фильтрацию и трансляцию по порядку

Мостовой файрвол Linux в Docker может блокировать пересылку независимо от IPsec. С бэкендом iptables изучите путь FORWARD и решения DOCKER-USER, помня, что правило, добавленное после более раннего вердикта, может никогда не выполниться. Бэкенд nftables интегрируется иначе, поэтому не создавайте цепочку DOCKER-USER только потому, что пример iptables назвал её так; проверьте, какой бэкенд ваш демон действительно использует.

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

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

Затем решите: маршрутизация или трансляция

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

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

Следите и за гибридным сбоем: половина набора правил транслирована, половина нет, что даёт перемежающийся успех, зависящий от порта назначения, а не от чего-либо в сети.

Проверяйте новым соединением, а не перезапуском

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

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