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-а и прочитај уносе ауторизације пре него што било шта промениш. Дневник именује проверено одредиште и правило које се поклопило или није, и то своди питање са четири слоја на један одговор.