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

Шаг 1: напишите требование до счёта

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

Будьте конкретны в отношении адресатов. «Доступ к VPC» обычно означает три разные вещи: CIDR VPC, пиринговую сеть и локальный диапазон за Transit Gateway. Управляемая конечная точка достигает всех трёх, но каждой нужен маршрут и правило авторизации, и каждая — отдельная строка в вашем требовании.

Шаг 2: перечислите то, что уже работает

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

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

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

Запишите также группы безопасности, привязанные к любому собственному инстансу. Эти правила — часть модели доступа, и именно они первыми тихо ломаются, когда кто-то пересобирает инстанс из шаблона.

Шаг 3: разделите ответственность

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

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

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

Шаг 4: сравнивайте с рабочей нагрузкой, которую можно описать

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

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

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

Шаг 5: переходите с откатом, который вы уже отработали

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

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

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

Похожие статьи