strongSwan-нан AWS Site-to-Site-қа: Child SA неге ештеңе таңдамайды

IKE туннелі көтерілген күйде болуы мүмкін, ал балалық ассоциация сіздің ішкі желілеріңізді алып тастайды. Алдымен AWS-тың жергілікті және қашықтағы CIDR-ін leftsubnet және rightsubnet-пен салыстырыңыз.

Консоль up күйін көрсетеді, strongSwan орнатылған IKE ассоциациясы туралы хабарлайды, бірақ пакеттер әлі де жетпейді. Келесі салыстыратын нәрсе — алдын ала бөлісілген кілт емес, әрбір тарап туннель қорғайды деп ойлайтын префикстер жұбы. Төмендегі тексерулерді ретімен өткізіңіз, өйткені алғашқы екеуі туннельдің трафигіңізді мүлде тасымалдай алатынын шешеді.

AWS атауларын strongSwan терминдеріне аударыңыз

AWS қосылымды клиент жағынан сипаттайды: клиент шлюзінің мекенжайы мен жергілікті CIDR сізге тиесілі, ал қашықтағы CIDR VPC-ке тиесілі. strongSwan екі ұшты left және right деп атайды, сіздің префиксіңіз leftsubnet-те, VPC префиксі rightsubnet-те болады. Бір жұпты кері аударып қою дұрыс емес трафикпен келіссөз жүргізетін және оны таңдайтын туннель жасайды.

AWS қосылым үшін жасайтын конфигурацияны жүктеп алыңыз және оны дәл сол қосылымның анықтамасы ретінде қарастырыңыз, туннель мекенжайлары мен префикстерді қоса. Жасау кезінде екі CIDR өрісін де бос қалдырсаңыз, қызмет әр жақта 0.0.0.0/0 әдепкі мәнін пайдаланады. Тар префикспен конфигурацияланған маршрутизатор оған ешқашан сәйкес келмейді, сондықтан өрістерді толтырыңыз немесе селекторды әдейі кеңейтіңіз.

Мұндағы сәйкессіздік маршруттау ақауына ұқсайды, бірақ ол емес.

AWS шын мәнінде көретін мекенжайды бекітіңіз

NAT артындағы маршрутизатор IKE-ні қарсы жақ ешқашан білмеген интерфейстен жібере алады. AWS-те жазылған шлюз мекенжайы AWS желіде көретін мекенжай болуы керек, ал маршрутизатор әдепкі маршрутына сенудің орнына сол жергілікті мекенжайға бекітілуі керек.

conn %default
    local_addrs = 203.0.113.10

strongSwan-да local_addrs IKE үшін бастапқы мекенжайды таңдайды, ал ескі OpenSwan конфигурациялары сол идеяны left деп жазады. Оны жалпыға қолжетімді мекенжайы бар интерфейске бағыттаңыз, содан кейін NAT құрылғысының өзінде UDP 500 мен 4500 сол хостқа жететінін тексеріңіз, өйткені бұрынғы маршрутизатордан қалған ереже оларды үнсіз тастап кетеді. Дұрыс селекторлар жұбы қате бастапқы мекенжаймен де сәтсіз аяқталады, ал журнал ұсынысты кінәлайды. Осы адастыру бастапқы мекенжайдың жеке тексеріске лайық болуының себебі.

Байланыс ережесін болжамдаудың орнына растаңыз, өйткені алдыңғы маршрутизатор үшін дұрыс болған ереже жиі қалып қояды.

1-ші және 2-ші фазаларды бөлек қарастырыңыз

AWS IKE және ESP опцияларын бөлек тізімдер ретінде көрсетеді. Екі жақ та қабылдайтын IKE жиынтығы ESP ұсынысы туралы ештеңе айтпайды, өйткені екі тізім тәуелсіз. Екеуін де жасалған конфигурациядан оқып, бір-бірден салыстырыңыз.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Синтаксис іске асырулар арасында ауыспайды. OpenSwan-да жұмыс істейтін жұп, мысалы phase2alg=aes_gcm ike=aes256-sha1;modp1024-пен, strongSwan-ның esp= және ike= формасына аударылуы керек, ал алгоритм атаулары әртүрлі. GCM шифрлау кезінде аутентификация жасайтындықтан, оған бөлек тұтастық трансформациясы қажет емес, SHA-мен жұпталған CBC жиынтығынан өзгеше. Бір демоннан екіншісіне аудармайсыз қойылған 2-ші фаза жолы селекторлар сәйкессіздігіне ұқсайтын бас тарту тудырады.

Туннель индикаторын емес, балалық ассоциацияны тексеріңіз

Қосылым жүктелсе де балалық ассоциация пайда болмаса, ұсыныс немесе селекторлар қабылданбаған. Егер бала пайда болып, оның селекторлары сіздің префикстеріңізді алып тастаса, пакеттер туннельге жетпей тұрып сүзіледі. Консоль индикаторы тек IKE деңгейін қамтиды, сондықтан екеуінің қайсысы болғанын айта алмайды.

ipsec statusall

Балалық қауіпсіздік ассоциациясын тауып, оның жанында басылған трафик селекторларын оқыңыз, содан кейін оларды жасалған конфигурацияның префикстерімен салыстырыңыз.

Жергілікті префикс ішіндегі хосттан VPC префиксі ішіндегі хостқа дейін сынап көріңіз және қайту жолын, сондай-ақ AWS жағындағы кез келген қауіпсіздік тобын немесе желілік ACL-ды тексеріңіз. Дұрыс селекторлар пакетті кейінірек тасталудан қорғамайды.

Селекторлар сәйкес келгеннен кейін де істемесе

Екі жақтағы маршрут туннельге бағытталғанын растаңыз, содан кейін NAT құрылғысы трафикті саясат күтпеген түрде қайта жазбайтынын растаңыз. Саясатқа негізделген туннель пакет мекенжайларымен сәйкестендіреді, сондықтан саясат шешімінен кейін қолданылған аударма нәтижені өзгертеді.

Басқа ұсынысты өзгерту алдында әр жақта бір кіріс және бір шығыс пакетін журналға жазыңыз.

Тикетке селекторларды, 1-ші және 2-ші фаза ұсыныстарын және бастапқы мекенжайды жазыңыз. Осы төрт мән site-to-site ақауларының көбін қоңыраусыз түсіндіреді.

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