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 може стояти на боці клієнтського шлюзу.