Правила AWS Client VPN относятся к ресурсу, а не к подсети

Сотрудникам нужно попадать в одно приложение в VPC и нельзя попадать в слушатель базы данных на том же инстансе, поэтому кто-то добавляет вторую публичную подсеть для эндпоинта VPN и объявляет требование выполненным. Размещение подсети меняет маршрутизацию и доступность. Оно не даёт и не отнимает ни одного порта. Разрешение, выражающее требование, находится в пункте назначения, в группе безопасности ресурса, а граница VPN даёт ручку, на которую ссылается это правило.

Размещение подсети — это маршрутизация, а не авторизация

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

Начните вместо этого с требования: кто вызывает, какой ресурс, какой порт службы и какое направление. Затем выберите модель правила, способную выразить эти четыре вещи в пункте назначения. Такой подход обычно полностью убирает лишнюю подсеть из проекта.

Группа связывания Client VPN и есть эта ручка

Для эндпоинта AWS Client VPN, связанного с подсетью, документированный порядок конкретен. Примените предполагаемую группу безопасности к сетевым связываниям целевой сети эндпоинта, затем разрешите нужный трафик в группе безопасности ресурса, используя эту группу Client VPN как источник.

Конкретно, группа инстанса приложения разрешает порт приложения из группы связывания и ничего больше. Процедура доступа к ресурсу AWS описывает это отношение, и стоит сохранять одну и ту же политику группы на каждой подсети, с которой связывается эндпоинт, потому что устаревшее связывание с другой группой тихо расширяет границу.

Это правило никого не аутентифицирует. Вход — отдельный контроль, а путь к ресурсу — третий. Все три должны выполняться до прихода запроса. Какое из них отказало, определяет правильное исправление, и изменение правила — верный ответ только для первого.

Что не может различить одна группа связывания

Каждый клиент за одной и той же группой связывания достигает ресурса как один и тот же источник группы безопасности. Два пользователя с разными ролями неразличимы на этом уровне, как бы группа ни называлась и ни помечалась. Авторизация внешних групп в Client VPN ограничивает доступ по префиксу назначения для группы каталога или SAML, что грубее роли ресурса и должно рассматриваться как сетевая граница, а не как система идентичности.

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

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

Не копируйте это правило в каждый проект VPN

Самостоятельно управляемый шлюз EC2 VPN, маршрутизируемое устройство проверки и управляемый Client VPN — это три разных пути пакетов. Установите, какой адрес источника действительно достигает ресурса, происходит ли по пути трансляция и какие механизмы ссылок служба поддерживает на этом пути.

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

Одного перехода NAT на пути достаточно, чтобы сломать предположение, и сбой выглядит как правило, которое есть, но никогда не совпадает.

Проверьте фактическую границу

Прочитайте каждую группу безопасности, прикреплённую к ресурсу, потому что разрешающие правила складываются, а узкое правило не отменяет более широкое в другой группе. Затем проверьте сетевой ACL, брандмауэр хоста и собственную авторизацию приложения — это отдельные уровни с отдельными ошибками.

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

Порядок работы: напишите требование из четырёх частей, прикрепите группу к связываниям, ограничьте правило ресурса портом, проверьте одно разрешение и один отказ и только затем рассматривайте разделение подсетей ради маршрутизации.