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 бузулуштарынын көбүн чалуусуз түшүндүрөт.

Тектеш макалалар