Ад strongSwan да AWS Site-to-Site: чаму Child SA нічога не выбірае

Тунэль IKE можа быць у стане up, але дзіцячая асацыяцыя выключае вашы падсеткі. Спачатку параўнайце лакальны і аддалены CIDR у AWS з 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, патрабуе перакладу ў форму esp= і ike= strongSwan, а назвы алгарытмаў адрозніваюцца. Паколькі GCM аўтэнтыфікуе падчас шыфравання, ён не патрабуе асобнага пераўтварэння цэласнасці, у адрозненне ад набору CBC у пары з SHA. Радок фазы 2, устаўлены з аднаго дэмана ў іншы без перакладу, дае адмову, якая выглядае як няўзгодненасць селектараў.

Правярайце асацыяцыю child, а не індыкатар тунэля

Калі злучэнне загружаецца, але асацыяцыя child не ўзнікае, значыць адхілілі альбо прапанову, альбо селектары. Калі child узнікае, але яго селектары выключаюць вашы прэфіксы, пакеты фільтруюцца яшчэ да траплення ў тунэль. Індыкатар кансолі ахоплівае толькі ўзровень IKE, таму не можа сказаць, што з двух адбылося.

ipsec statusall

Знайдзіце асацыяцыю бяспекі child і прачытайце селектары трафіку, надрукаваныя побач, затым параўнайце іх з прэфіксамі са створанай канфігурацыі.

Тэстуйце з хоста ўнутры лакальнага прэфікса да хоста ўнутры прэфікса VPC і праверце зваротны шлях, а таксама любую групу бяспекі або сеткавы ACL на баку AWS. Правільныя селектары не абараняюць пакет ад адкідання пазней.

Калі пасля супадзення селектараў усё яшчэ не працуе

Пацвердзіце, што маршрут з абодвух бакоў вядзе да тунэля, затым пацвердзіце, што прылада NAT не перапісвае трафік так, як палітыка не чакае. Тунэль на аснове палітыкі супастаўляе адрасы пакетаў, таму пераўтварэнне, ужытае пасля рашэння палітыкі, змяняе вынік.

Зарэгіструйце адзін пакет на ўваход і адзін на выхад з кожнага боку, перш чым мяняць чарговую прапанову.

Запішыце селектары, прапановы фазы 1 і фазы 2 і адрас крыніцы у тыкет. Гэтыя чатыры значэнні тлумачаць большасць збояў site-to-site без званка.

Падобныя артыкулы