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, тоді як інстанс перебуває в об'єднаній через 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 і прочитайте записи авторизації, перш ніж щось змінювати. Журнал називає перевірене призначення і правило, яке збіглося або ні, і це зводить питання з чотирьох шарів до однієї відповіді.