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 — не гэты тэст.

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

Адкат перавяртае той жа парадак. Выдаліце маршрут падсеткі рабочай нагрузкі апошнім, пасля аднаўлення папярэдніх селектараў, каб не пакінуць падсетку, якая паказвае на шлюз, які больш не абараняе яе крыніцы. Самастойны хостынг можа абслугоўваць больш за хост шлюза, калі гэтыя кантракты выконваюцца, а Site-to-Site VPN пад кіраваннем AWS — іншая аперацыйная мадэль, дзе strongSwan можа знаходзіцца на баку кліенцкага шлюза.