AWS Client VPN е поврзан, но EC2 сè уште не одговара

Мојот лаптоп покажуваше поврзан. Клиентот на AWS Client VPN го покажуваше своето зелено состојба, endpoint-от зачува сесија, и сепак не можев да отворам MongoDB порт на EC2 инстанца во приватна подмрежа. Ништо очигледно не беше расипано: сертификатот беше валиден, профилот доаѓаше од конзолата и тунелот пренесуваше сообраќај. Грешката беше моја, зашто поврзан го читав како овластен.

Најавувањето одговара точно на едно прашање: смее ли овој идентитет да воспостави сесија? Сè потоа го одлучуваат одделни правила што никогаш не го гледаат твојот сертификат. Сесијата што се автентицира и пакетот што пристигнува се два различни успеси, а јазот меѓу нив е местото каде живеат најголемиот дел од пријавите од типот VPN е вклучен, но домаќинот е недостапен.

Проверките подолу се редоследот што сега го користам.

Што всушност докажува поврзана сесија

За време на handshake-от endpoint-от го проверува клиентскиот сертификат против својот trust store или го пренасочува прелистувачот кон твојот давател на идентитет кога 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 на дестинација и ID на група по правило. Во него се кријат два порази. Правилото може да авторизира 10.0.0.0/16, а инстанцата да стои во peer-увано 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-от и прочитај ги записите за авторизација пред да смениш нешто. Дневникот ја именува проверената дестинација и правилото што се совпаднало или не, и тоа го сведува прашањето со четири слоја на еден одговор.