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, прежде чем трогать авторизацию. Если ни один маршрут не покрывает адрес, исправьте связывание или таблицу маршрутов. Если пакет приходит, а служба его отвергает, следующая остановка — политика этой службы. Расширение матрицы авторизации на всех пользователей скрывает, какой из этих уровней действительно был сломан.

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