AWS Client VPN или Site-to-Site: проверьте, кто открывает подключение

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

Каждую проверку проводите по фактической конечной точке, клиенту и семейству адресов, которые вы собираетесь использовать, а не по категории. Управляемые VPN-продукты отличаются от строительных блоков OpenVPN и IPsec, на которые они похожи.

Во-первых, кто открывает подключение

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

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

Во-вторых, что аутентифицирует AWS

В Client VPN AWS аутентифицирует настроенную идентичность клиента или пользователя: сертификаты, каталог или федеративную идентичность, в зависимости от настройки. В Site-to-Site VPN AWS аутентифицирует идентичность партнёра шлюза. Эта разница не косметическая. Одна модель масштабируется добавлением пользователей и отзывом их учётных данных; другая масштабируется доверием ко всему, что стоит за одним шлюзом.

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

В-третьих, как подключение привязывается

Client VPN привязывается через связи подсетей VPC или поддерживаемое прямое подключение Transit Gateway. Site-to-Site VPN привязывается к цели AWS VPN, обычно к виртуальному частному шлюзу или Transit Gateway. Руководство по архитектуре Client VPN документирует вариант Transit Gateway, и его наличие не превращает сессию ноутбука в шлюз филиала и не отменяет описанные выше аутентификацию и авторизацию клиента.

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

В-четвёртых, какие маршрутизация и политика идут вместе с ним

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

Не выводите неподдерживаемое поведение из категории ни в одном направлении. VPN удалённого доступа не являются универсально неспособными передавать обратный трафик или поддерживать шлюзовые схемы, и IPsec не блокируется автоматически NAT — AWS документирует прохождение NAT и требования к клиентскому шлюзу, и реальное ограничение — это поддерживаемая конфигурация шлюза. Проверьте ограничения для своей конечной точки, прежде чем требовать подключений, инициируемых в сторону клиентов, или пересылать LAN за одной сессией. Та же осторожность касается семейств адресов: конечная точка, работающая по IPv4, не подразумевает путь IPv6, поэтому подтвердите семейство, о котором ваш клиент или шлюз действительно будет договариваться.

Site-to-Site VPN даёт два туннеля на подключение, и эта избыточность — задача проектирования, а не функция, которую можно предположить. Эксплуатация клиентского шлюза, переключение маршрутов при отказе и покрытие тестами должны быть спланированы; сравнение одной сессии ноутбука с абстрактным VPN-сервером ничего не доказывает ни о том, ни о другом.

Где встречаются два проекта

Сервисы не исключают друг друга, и обычная продуктовая форма использует оба: сотрудники на Client VPN, сети филиалов на Site-to-Site, с явными маршрутами и политикой доступа между пунктами назначения, которым нужно общаться. Таблица — это сводка четырёх проверок, а не замена их выполнения.

Одно, чего не заменяет ни один из двух продуктов: TLS к приложению, требование шифрования которого выходит за пределы конечной точки VPN. Если ваша область соответствия заканчивается на приложении, туннель — это транспорт, а сертификат по-прежнему остаётся средством контроля.

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