AWS Client VPN: вхід проходить, але підмережа недоступна

Ваш клієнт показує Connected, сертифікат дійсний, а сторінка інтранету все одно завершується тайм-аутом. Ця розбіжність майже ніколи не пов'язана з автентифікацією. AWS Client VPN авторизує призначення окремо від входу, і зазвичай є дві причини: значення групи, яке не збігається з надісланим постачальником ідентичності, і конкретніше правило призначення, яке перекриває широке. Обидва видно в конфігурації endpoint, якщо знати, куди дивитися.

Вхід пройшов; правило не збіглося

Автентифікація відповідає, хто користувач. Правила авторизації відповідають, до яких мережевих префіксів ця ідентичність може дістатися. Користувач може пройти перше і не пройти друге, а клієнт дає лише з'єднання, яке тримається, поки кожен запит завершується тайм-аутом.

Почніть із підтвердження, що endpoint має правило авторизації, призначення якого містить проблемну адресу. Якщо відповідного правила немає, з'єднання поводиться правильно; бракує політики.

Звідки насправді береться значення групи

У Active Directory поле access-group містить SID групи, а не її відображуване ім'я. За федерації SAML воно містить ідентифікатор або назву групи, які справді передає налаштований атрибут групи SAML. Копіюйте значення з assertion або із запиту до каталогу, а не зі сторінки вікі.

Група IAM — це інша площина керування. Дозвіл адмініструвати endpoint Client VPN не робить групу IAM VPN-групою користувача, а вставляння назви групи IAM у поле access-group не перетворює її на SID AD чи значення атрибута SAML.

Група зі схожою назвою в іншому каталозі нічого не доводить. Перевірте метод автентифікації endpoint і членство або assertion користувача в тій самій системі.

Перемагає найдовший префікс, включно з 0.0.0.0/0

Авторизація оцінюється за найдовшим збігом префікса, а правило для всіх призначень оцінюється останнім, не першим. Додайте правило 10.46.0.0/16 для Engineering і правило 0.0.0.0/0 для всіх, і користувач поза Engineering усе одно не потрапить на 10.46.20.10 через широке правило.

Саме тут виправлення може піти не так. Видалення вузького правила повертає доступ користувачеві й водночас надає цю підмережу кожній ідентичності, яку покриває широке правило. Побудуйте матрицю груп і мереж, перш ніж щось видаляти, і запишіть, які групи мають діставатися якого діапазону. Ці правила лише дозволяють; запису заборони, яким можна вирізати виняток із широкого дозволу, немає.

Зміни також потребують нового з'єднання, щоб їх можна було оцінити чесно. Перепідключіть клієнт після редагування правил, а потім перевірте знову.

Відокремте авторизацію від шляху даних

Правило, що збіглося, — це не маршрут. Endpoint потребує пов'язаної підмережі та запису в таблиці маршрутів для призначення, а група безпеки цільового ресурсу має приймати трафік. Зворотний трафік і DNS теж мають працювати.

Перевірте користувача, який має отримати доступ, і користувача, який має залишитися поза ним. Обидва можуть увійти, але лише один дістається підмережі, і саме ця різниця — потрібний вам доказ.

Якщо IP-адреса працює, а ім'я хоста ні, подивіться на resolver, перш ніж чіпати авторизацію. Якщо жоден маршрут не покриває адресу, виправте зв'язування або таблицю маршрутів. Якщо пакет надходить, а служба його відхиляє, наступна зупинка — політика цієї служби. Розширення матриці авторизації на всіх користувачів приховує, який із цих рівнів насправді був зламаний.

Перш ніж закрити заявку, запишіть джерело ідентичності, точне значення групи, префікси призначення та маршрут, яким іде трафік. Такий запис перетворює наступне повідомлення про підключення без доступу на порівняння за дві хвилини замість ще одного кола здогадів.