EC2-де strongSwan: 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 күйі бұл тест емес.

Егер шлюз жұмыс істеп тұрғанда жұмыс жүктемесі әлі сәтсіз болса, қадамдар бойынша кері шегініңіз: селектор, содан кейін жіберу және қауіпсіздік топтары, содан кейін байланысқан маршруттау кестесі. Әрқайсысының өз белгісі бар және болжау шын мәнінде қате болғанын өткізіп жібереді.

Артқа қайтару сол тәртіпті кері айналдырады. Жұмыс жүктемесінің ішкі желісінің маршрутын соңында жойыңыз, алдыңғы селекторларды қалпына келтіргеннен кейін, көздерін енді қорғамайтын шлюзге сілтейтін ішкі желі қалдырмас үшін. Бұл шарттар орындалғанда өзін-өзі орналастыру шлюз хостсынан көбірек қызмет ете алады, ал AWS басқаратын Site-to-Site VPN — strongSwan тұтынушы шлюзі жағында отыра алатын басқа операциялық модель.

Қатысты мақалалар