Почему клиенты OpenVPN не попадают в селекторы IPsec шлюза

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

Ping со шлюза проверяет поток, который ваш клиент никогда не использует

Адрес источника определяет, какая политика применяется. Пакет, созданный на шлюзе, уходит с адресом из его локальной сети LAN или из конечной точки туннеля, и политика, которая ему соответствует, была написана именно для этого случая. Пакет клиента приходит на интерфейс OpenVPN с адресом из пула клиентов, а это совсем другой селектор.

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

Протолкните удалённый префикс, который приложению действительно нужен

Возьмите иллюстративную пару 10.8.0.0/24 для подключённых клиентов и 172.30.239.0/25 для защищённой удалённой сети. Клиенту нужен маршрут ко второму префиксу, а не к LAN шлюза и не к какому-то другому адресу туннеля. Именно протолкнутый в пул маршрут заставляет клиента вообще передать этот трафик шлюзу. Без него пакет никогда не дойдёт до того решения политики, которое вы отлаживаете.

На сервере Community, который принимает протолкнутые маршруты, директива берёт настоящую маску: push "route 172.30.239.0 255.255.255.128". Access Server настраивает тот же адрес назначения через параметры частной сети или правила доступа установленной версии, причём маршрутизируемый или транслирующий режим выбирается осознанно. Правка сгенерированных цепочек брандмауэра вместо ответной конфигурации — это путь, на котором рабочая установка становится невоспроизводимой.

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

Сделайте так, чтобы селекторы включали пул клиентов

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

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

Общий source NAT на шлюзе тоже может сломать совпадение. Если правило masquerade переписывает источник клиента до проверки политики, пакет уже не выглядит как написанный вами селектор. Это одна из причин, почему широкое правило masquerade — плохое исправление для второго VPN: оно меняет, какая политика применяется и какой адрес фиксирует удалённая сторона. Освободите трафик, который собираетесь маршрутизировать, или осознанно транслируйте его и обновите селекторы.

Осознанно выберите маршрутизацию или трансляцию

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

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

Замкните цикл на пересылке и ответе

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

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

Держите авторизацию назначения узкой во время теста и подтвердите, что клиент без правила не может добраться до сервиса. Установленный маршрут и установленная ассоциация — не то же самое, что предоставленный доступ.