AWS Client VPN падключаны, але EC2 усё яшчэ не адказвае

Мой ноўтбук паказваў падключана. Кліент AWS Client VPN паказваў зялёны стан, endpoint запісаў сесію, і ўсё роўна я не мог адкрыць порт MongoDB на інстансе EC2 у прыватнай падсетцы. Нічога відавочна не было зламана: сертыфікат быў сапраўдны, профіль прыйшоў з кансолі, і тунель перадаваў трафік. Памылка была мая, бо я чытаў падключана як аўтарызавана.

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

Праверкі ніжэй — гэта парадак, які я выкарыстоўваю цяпер.

Што насамрэч даказвае падключаная сесія

Падчас handshake endpoint правярае сертыфікат кліента супраць свайго trust store або перанакіроўвае браўзер да вашага identity provider, калі наладжаны SAML. Калі гэта праходзіць, кліент атрымлівае адрас з кліенцкага CIDR endpoint, і кансоль паказвае актыўнае злучэнне. Ні ў які момант гэтага абмену нішто не пытаецца, ці можаце вы дасягнуць 10.0.4.17 на порце 27017.

Дазвол для пункту прызначэння — асобны аб’ект на endpoint. Кожны паток звяраецца з правіламі аўтарызацыі, і кожнае з іх спалучае CIDR прызначэння з групай, якой даецца правіла. Калі ніводнае правіла не пакрывае пункт прызначэння, endpoint прымае сесію і скідае трафік. Няма ні банэра, ні цыкла перападлучэння, ні чаго-небудзь у інтэрфейсе кліента, што кажа адмоўлена.

Параўнайце правіла аўтарызацыі з рэсурсам, а не з VPC

Пералічыце правілы і пакладзіце іх побач з адрасам, які інстанс насамрэч мае:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

Вывад паказвае CIDR прызначэння і ідэнтыфікатар групы для кожнага правіла. У ім хаваюцца дзве няспраўнасці. Правіла можа дазваляць 10.0.0.0/16, тады як інстанс знаходзіцца ў аб’яднанай праз peering VPC на 10.1.0.0/16; маршрут peering існуе, але ніхто не напісаў правіла аўтарызацыі для другога дыяпазону. Або правіла паказвае на групу каталога, у якую карыстальнік уваходзіць у каталозе, але не ў групе, якую ацэньвае endpoint.

Напішыце самае вузкае правіла, якое пакрывае пункт прызначэння, і дадавайце другое толькі тады, калі другі CIDR сапраўды патрэбны. Шырокае правіла 0.0.0.0/0 з хуткага старту працуе, і менавіта таму яно дажывае да прадукцыі і хавае мадэль.

Дзве табліцы маршрутаў вырашаюць, ці рушыць пакет

Маршрут endpoint супастаўляе CIDR прызначэння з адной з падсетак, з якімі звязаны endpoint. Гэта палова шляху. Уласная табліца маршрутаў падсеткі ўсё яшчэ павінна ведаць, як перадаць пакет, і гэта важна ў той момант, калі пункт прызначэння знаходзіцца за peering-злучэннем, transit gateway або лакальным дыяпазонам, дасяжным праз тунель site-to-site.

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

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

Адна кліенцкая налада ламае маршрутызацыю, не ламаючы тунель: профіль, які змяшчае route-nopull. Дырэктыва кажа кліенту на аснове OpenVPN ігнараваць маршруты, якія штурхае сервер, таму інтэрфейс узнімаецца толькі з уласным адрасам endpoint, і пункт прызначэння проста не мае маршруту. Праверце з дапамогай ip route show у Linux або netstat -rn у macOS, ці існуе маршрут праз інтэрфейс tun. Калі не, выдаліце route-nopull з экспартаванага профіля і перападключыцеся, каб штурханыя маршруты прымяніліся.

Групы бяспекі не бачаць адрас вашага кліента

Гэта тая частка, у якой я памыляўся цэлую пасляабедзенную пару. Для IPv4-endpoint, звязанага з падсеткай, сэрвіс пераўтварае адрас крыніцы кліента ў адрас сеткавага інтэрфейса endpoint у гэтай падсетцы. Пакет, які даходзіць да інстанса, не нясе адрас, які паказаў ваш кліент, таму правіла групы бяспекі, якое дазваляе пул кліентаў, скажам 172.16.0.0/22, не супадае ні з чым.

Дазвольце порт з групы бяспекі endpoint, якая прымацавана да інтэрфейса асацыяцыі, а не з кліенцкага CIDR. Спасылка на групу трывалейшая за жорстка зададзены адрас, бо адрас інтэрфейса не вам кантраляваць. Сеткавыя ACL не захоўваюць стану, таму там, дзе ёсць уласныя запісы, і ўваходны, і выходны кірунак павінны дазваляць паток.

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

Парадак ізаляцыі, які спыняецца на першай няўдачы

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

1. Пацвердзіце, якую ідэнтычнасць выкарыстала сесія і якую групу ацэньвае endpoint. Сертыфікат з аднаго trust store — не той самы суб’ект, што SAML-сцвярджэнне з каталога.
2. Пацвердзіце, што правіла аўтарызацыі пакрывае CIDR рэсурсу для гэтай групы.
3. Пацвердзіце, што маршрут endpoint існуе і накіраваны на звязаную падсетку, затым што табліца маршрутаў падсеткі можа перадаць далей.
4. Пацвердзіце, што група бяспекі дазваляе порт з інтэрфейса endpoint, а не з пула кліентаў.
5. Тэстуйце знутры VPC, з сесіяй SSM на іншым інстансе ў той жа падсетцы, каб аддзяліць праблему праграмы ад праблемы кліенцкага шляху.

Калі крокі не вырашаюць, я абапіраюся на гэтую табліцу:

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

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