strongSwan на EC2: пусть VPC маршрутизирует рабочую нагрузку

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

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

Сначала запишите четыре адреса

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

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

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

Шаг 1: дайте подсети рабочей нагрузки маршрут

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

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

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

Шаг 2: включите пересылку на госте

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

Группы безопасности — это место, где этот шаг обычно застревает. Промежуточное устройство не наследует поведение ссылок на группы безопасности прямого взаимодействия экземпляров, поэтому правило, скопированное из примера управляемого Client VPN, может никогда не совпасть. Проверьте группу безопасности и ACL подсети на реальном пути, в обоих направлениях.

Шаг 3: расширьте селекторы до реальных источников

Политика, покрывающая на стороне AWS только 10.60.1.10/32, объясняет успех, начавшийся на шлюзе, не покрывая 10.60.2.20. Маршрут к удалённому назначению не расширяет селектор трафика, и это вторая половина того же сюрприза.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Если согласованный проект защищает весь VPC, обе стороны должны принять 10.60.0.0/16 и 10.90.0.0/24. Если он защищает одну рабочую нагрузку, сознательно используйте этот более узкий префикс. В любом случае проверьте установленную политику CHILD-SA, потому что конфигурация, которую вы правили, и сторона, сузившая её иначе, — не одно и то же соглашение.

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

Шаг 4: проверьте, а затем откатите при необходимости

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

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

Откат меняет тот же порядок на обратный. Удалите маршрут подсети рабочей нагрузки последним, после восстановления прежних селекторов, чтобы не оставить подсеть, указывающую на шлюз, который больше не защищает её источники. Самостоятельный хостинг может обслуживать больше, чем хост шлюза, когда эти контракты соблюдаются, а Site-to-Site VPN под управлением AWS — другая операционная модель, где strongSwan может стоять на стороне клиентского шлюза.

Похожие статьи