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 статус није тај тест.

Ако радно оптерећење и даље не успева док пролаз ради, вратите се кроз кораке по реду: селектор, затим прослеђивање и сигурносне групе, затим повезана табела рутирања. Сваки има различит симптом, а нагађање прескаче онај који је стварно погрешан.

Враћање обрће исти редослед. Уклоните руту подмреже радног оптерећења последњу, након што обновите претходне селекторе, да не оставите подмрежу која показује на пролаз који више не штити њене изворе. Самостални хостинг може да служи више од хоста пролаза када ови уговори важе, а AWS-ом управљани Site-to-Site VPN је другачији оперативни модел у коме strongSwan може да седи на страни корисничког пролаза.