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, докато инстанцията се намира в 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-а и прочетете записите за оторизация, преди да промените нещо. Журналът посочва проверената дестинация и правилото, което е съвпаднало или не, а това свежда въпроса с четири слоя до един отговор.