strongSwan на EC2: нека VPC маршрутизира работното натоварване

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

Тунелът работи, инстанцията на шлюза може да прави ping до отдалечената мрежа, а инстанцията на приложението до нея не достига до никъде. Нищо не е счупено. Успешният тест започна на 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: проверете и след това върнете назад, ако е необходимо

Тествайте от самото натоварване с нова разрешена операция на приложението, след което повторете с дестинация, която трябва да бъде изключена. Запишете адреса на източника, който отдалечената услуга вижда, и обратния път, който тя използва. Ping към шлюза или зелен статус на IKE не е този тест.

Ако натоварването продължава да се проваля, докато шлюзът работи, вървете назад по стъпките в ред: селектор, след това препращане и групи за сигурност, след това свързаната таблица за маршрутизация. Всяка има различен симптом и отгатването пропуска тази, която е наистина грешна.

Връщането назад обръща същия ред. Премахнете маршрута на подмрежата на натоварването последен, след като възстановите предишните селектори, за да не оставите подмрежа, сочеща към шлюз, който вече не защитава нейните източници. Самостоятелният хостинг може да обслужва повече от хоста на шлюза, когато тези договори са в сила, а Site-to-Site VPN под управление на AWS е различен оперативен модел, при който strongSwan може вместо това да стои от страната на клиентския шлюз.

Подобни статии