VPN обеспечивает доступ удаленных пользователей в корпоративную сеть. Решений много, но выбор оптимального не всегда очевиден. В данной статье хотел бы поделиться опытом внедрения и использования такого продуктового решения как Always On VPN от компании Microsoft. Подчеркну, что это не просто технология постоянно работающего соединения (многие вендоры используют похожие слова), а название продукта или даже целой экосистемы.
Статья будет полезна архитекторам решений ВПН и тем, кто планирует внедрять ВПН на основе технологии Always On VPN (или еще сомневается). В документации вендора вопросы, затронутые в данной статье совсем не освещены и понять возможные трудности, можно только на основе личного опыта.
Disclaimer: Если вы еще не знакомы с плюсами этой технологии, эта статья может создать довольно негативное впечатление о продукте, что на самом деле в корне не верно. Технология находится в топе корпоративных ВПН решений, обеспечивая широкий набор работающего функционала.
В статье не приводил примеры конфигурации и пошаговые инструкции для внедрения – по двум причинам. Во-первых, эти материалы можно найти в документации Microsoft, а во-вторых, технология предоставляет множество альтернативных конфигураций, выбор которых должен осуществить архитектор решения, а уместить все в одну статью не получится.
Если говорить о практике, наши заказчики любят эту технологию за то, что она предоставляет:
очень высокий уровень безопасности (при «правильной» конфигурации);
высокий уровень автоматизации и интеграции. Минимальная загрузка ИТ отдела, отвечающего за ВПН решения;
способность работы с очень большим количеством пользователей;
относительно небольшие требования к вычислительным ресурсам;
не требует приобретения отдельных лицензий для ВПН. Все включено в серверные и клиентские ОС от Microsoft. Т.е. для организации ВПН сервера требуются только лицензии на Windows Server, более того, не активированные версии выполняют свои ВПН функции без ограничений*.
*Note 1
1) Не все ОС поддерживаются, в основном корпоративные.
2) Для использования облачных сервисов требуются дополнительные лицензии.
При этом они же опасаются использовать эту технологию, потому что видят:
высокий порог вхождения по уровню знаний. Требуется довольно глубокое понимание принципов работы и траблшутинга большого количества связанных продуктов Microsoft;
не единое решение «из коробки» а «куча» продуктов и решений от Microsoft. Хотя, если не выходить из экосистемы Microsoft, всё настраивается согласно документации, без «костылей»;
решение «из коробки» и настройками «по умолчанию» небезопасное и не рабочее;
тяжелый траблуштинг – логи разбросаны по разным компонентам, единой точки сбора логов нет. Надо хорошо понимать, что и где искать. Хотя, необходимые логи есть и можно очевидно понять в чем проблема. Вопрос опыта.
У Microsoft есть своё понимание того, что нужно ее клиентам. Эти идеи иногда расходятся с общепринятыми практиками и ожиданиями конечных пользователей. Все перечисленные ниже «проблемы», на самом деле не являются таковыми с точки зрения Microsoft, а скорее ненужными сценариями работы для корпоративных пользователей.
Мы же накопили многолетний опыт конфигурирования этой технологии для организаций в Европе и РФ с десятками тысяч пользователей, а заодно и обширный список «сложностей» и «непониманий», о которые спотыкаются наши заказчики. И эта статья как раз об этом.
Описание
Почему «Allways On»? Позволяет настроить ВПН соединение так, что соединение будет устанавливаться автоматически, можно подключаться к ВПН только в случае использования определенного приложения и на основе разных триггеров. Особый сценарий, когда до входа пользователя в операционную систему устанавливается туннель от имени компьютера, например, для связи с контролером домена. Такие туннели пользователь не сможет отключить и увидеть в трее.
Тут важно не путать. У других известных вендоров Always On – это параметр, а у Microsoft это название целой экосистемы для создания ВПН туннелей. Т.е. у Microsoft Always On VPN вовсе не обязательно будет подключен всегда – все зависит от конфигурации. Все сценарии конфигурации трудно перечислить, поэтому важно понимать ключевые возможности и ограничения.
Ниже приведу небольшую схему, описывающую технологию и ее описание для тех, кто глубоко не знаком с возможностями Always On VPN от MS:
На выбор предоставляется два варианта аутентификации:
для устройства (Device Tunnel) - пока пользователь не вошел в систему. Работает для всех пользователей.
для пользователя (User Tunnel) - доступный после входа (логина). Разрывается после выхода пользователя из системы.
Для пользовательского туннеля возможен выбор между двумя протоколами: IPSec или TLS (SSTP). В обоих случаях используется аутентификация PEAP. (возможны и другие, менее безопасные варианты, которые мы не рекомендуем своим клиентам и не рассматриваем далее). Для туннеля устройства такого выбора нет - только чистый IPsec IKEv2 с аутентификацией по сертификату.
Device Tunnel
Плюсы
Плюсы и важные возможности |
Комментарии |
Соединение работает независимо от входа пользователя |
— Компьютер всегда остается подключен к корпоративной сети. — Пользователь не может отключить такое соединение. — Все пользователи компьютера имеют доступ в ВПН туннель. — Основная цель – обеспечивается связь с доменом, обновляются пароли, связь со средствами защиты, логирование, мониторинг, и т.д. |
Соединение на основе сертификата устройства |
— Сертификат пользователя не используется, только сертификат компьютера (device). — Пароли и PSK не используются. — Большой выбор «криптопровадеров» для хранения закрытого ключа. — Сертификат устройства можно защитить разместив в TPM модуле. |
Высокая скорость внедрения |
— Сертификаты распространяются средствами Microsoft CA на доменные компьютеры с помощью политик «auto enroll». — В организациях, уделяющих внимание безопасности компьютеры уже имеют подходящий сертификат. — Также сертификаты можно распространять любыми сторонними средствами. |
Поддерживается отказоустойчивость при наличии внешнего балансировщика |
Если точнее, неограниченное количество серверов работают независимо. При переключении на другой сервер, компьютеры устанавливают новое соединение автоматически. |
Можно подключить ОС отличные от Windows |
Классический IPSec на основе сертификатов. |
Поддержка Split Tunneling и Full Tunneling |
Можно принудительно отправлять весь трафик пользователя (компьютера) в корпоративную сеть, а можно выбирать отдельные сети в зависимости от требований безопасности. |
Минусы
Сложности и ограничения |
Комментарии |
Невозможно ограничить доступ на основе Active Directory Security Group |
— RADIUS-сервер не участвует в аутентификации. — Аутентификация происходит на RAS |
Невозможно на одном сервере реализовать схему с нескольким пулами IP-адресов |
Один сервер RAS – один пул адресов. |
RAS-сервер для пользовательского туннеля (User tunnel) и сервер для туннеля устройства (Device tunnel) должны быть разными |
Совместить, конечно, возможно, но пользователи и компьютеры будут получать адреса из одного пула. В этом случае теряется смыл наличия двух туннелей при наличии одного пула адресов. |
Невозможно задать выделенный IP-адрес для компьютера |
— Адрес будет выдан из пула адресов случайным образом. — RADIUS-сервер не используется, RAS-сервер не обращается в базу AD и т.п. — При использовании внешнего DHCP-сервера привязка IP к MAC невозможна, более того, полноценно не работает. |
Тяжело «заблокировать» скомпрометированный компьютер |
— Отключение/блокировка компьютера возможна только на основе CRL. — Реакция на изменения не мгновенная, как, например, исключение из Security Group. Потребуется очистка кэша на сервере, чтобы изменения CRL были видны сразу. — В Windows 2022 был баг, когда очистить кеш без перезагрузки ОС невозможно. Для Windows 2019 таких проблем нет. |
Отсутствие визуального контроля подключения для пользователя |
— У пользователя нет статуса соединения и значков соединения. — Пользователь не может ни разорвать, ни установить соединение. — Конечно, по косвенным признакам можно понять, что соединение установлено но, в целом, это доступно не каждому пользователю. |
Только IPSec |
Нет возможности использовать SSTP (TCP/443), а трафик UDP500/4500 пропускается не всеми провайдерами. |
Невозможно сделать аутентификацию на основе SubCA |
RAS-сервер позволяет задать аутентификацию на основе сертификата, расположенного в корневом хранилище. |
Не все EKU поддерживаются сервером для фильтрации на этапе аутентификации. |
Очень ограниченный список EKU (списка как такого нет в документации, но большую часть путей настроить невозможно). Например, 1.3.6.1.5.5.7.3.7,1.3.6.1.5.5.7.3.2 фильтровать можно. |
По умолчанию максимально небезопасные настройки IPSec |
— Требуется донастройка сервера RAS с помощью команд. — «Из коробки» открывается полный доступ в сеть, так как входящий сертификат не проверяется. — Откровенно слабые алгоритмы, используемые по умолчанию, типа ENCR_3DES, AUTH_HMAC_SHA1, PRF_HMAC_SHA1, DF Group 2. — Пока вы их не настроили, посмотреть конфигурацию невозможно. Если настроили, то вернуть состояние к дефолтному не получится. |
Трудности определения работоспособности сервера балансировщиком |
— В случае применения отказоустойчивой конфигурации требуется установить балансировщик. Большинство балансировщиков не могут проверить работоспособность IPSec и портов UDP 500/4500. — Обходное решение: на сервере RAS запускается SSTP-сервер с User Tunnel без публикации в интернет. В этом случае балансировщик проверяет порт TCP/443. Решение обходное, так как проверяется другой тип туннеля. |
У соединения нет ограничения на время работы |
— Повторная аутентификация не проводится. — Если у сертификата истек срок действия или он был добавлен в CRL, соединение будет продолжать работать. — Необходимо вручную отключить сессию компьютера и очистить кэш CRL. |
Да, возможно, вышеперечисленный список мог создать негативное впечатление о технологии, и поэтому хотелось бы перечислить несколько пунктов «в оправдание»:
Соединение “Device tunnel” устанавливается для доменного компьютера, т.е. априори «своего», доверенного.
Если компьютер получил сертификат, значит ситуации, когда мы допускаем потерю связи с доменом, минимальны. Ведь связь с доменом и служебными сервисами — это приоритет.
Блокировки и богатые настройки для аутентификации через группы и пулы адресов в этом случае не нужны, а МФА-аутентификация невозможна «по определению».
Высокий уровень безопасности дает хранение ключа в TPM модуле. А дополнительные подключения, необходимые пользователю, нужно устанавливать другим типом соединения – на основе сертификата пользователя (User tunnel), после входа.
Доступ к критическим ресурсам будет получен уже на основе аутентификационных данных пользователя после входа пользователя.
Пользовательский туннель
Для туннеля пользователя предусмотрены различные способы аутентификации: Имя пользователя и пароль, смарт-карта (как физические, так и виртуальные), пользовательские сертификаты, Windows Hello. Далее рассуждения основываются на сценарии с аутентификацией на основе сертификатов, в том числе смарт-картах.*
*Note 2: При этом имя пользователя и пароль мы не рассматриваем как достаточно безопасный способ и не рекомендуем его своим клиентам.
Плюсы
Плюсы и важные возможности |
Комментарии |
Поддержка Split Tunneling и Full Tunneling |
Можно принудительно отправлять весь трафик пользователя в корпоративную сеть, а можно выбирать отдельные сети в зависимости от требований безопасности. |
VPN для каждого приложения |
— Возможно установить триггеры на «запуск» ВПН при использовании определенного приложения. — Постоянно работающий ВПН (неотключаемый пользователем) |
Поддержка MFA |
— Все MFA которые можно реализовать через RADIUS (NPS) будут работать нативно. — Исключение – не поддерживаются пуш-уведомления средствами Always On VPN на клиентах Windows. Т.е. в процессе соединения сервер не может показать пользователю окно и запросить код. — Необходима установка специальных приложений от «провайдеров» MFA. — В случае использования аппаратных сертификатов, MFA запрашивается |
Поддержка двойного стека для IPv4 и IPv6 |
Direct Access, предшественник Always On VPN, плотно использовал IPv6. Сейчас есть выбор и в подавляющем большинстве случаев мы отказываемся от IPv6. |
IP-адрес из профиля пользователя |
Кроме пула с выдачей случайного свободного адреса, есть возможность задавать в Active Directory профиле пользователя персональный выделенный IP. |
Поддержка механизмов высокой доступности |
Возможна реализация отказоустойчивых и высоконагруженных кластеров. Если точнее, неограниченное количество серверов работают независимо. При переключении на другой сервер, компьютеры устанавливают новое соединение. |
Условный доступ VPN (недоступен без Azure и облака от Microsoft) |
Перед подключением можно проверить безопасность компьютера (установленный антивирус или софт, с какого подозрительного адреса происходит подключение) и заблокировать подключение, или спросить дополнительный фактор аутентификации. |
IKEv2: при смене IP клиента соединение не разрывается (MOBIKE) |
— Функция доступна только для IKE варианта пользовательского туннеля. — Смена IP не приводит к разрыву соединения. Безопасность не страдает. — Реальные сценарии, где это было бы по-настоящему нужно, представить тяжело, но стабильности добавляет. |
Скорость IKEv2 vs SSTP |
Есть мнение, что IPSec работает быстрее SSTP. На самом деле в реальной жизни это не совсем так. Практика показывает, что победителя нет – бывает SSTP показывает результат немного лучше, а бывает наоборот. Скорее всего у провайдеров на пути трафика разное отношение к UDP и TCP в разное время дня. Мы рекомендуем использовать оба варианта. |
Минусы
Сложности и ограничения |
Комментарии |
Слабая поддержка ОС отличных от Windows |
— На практике поддержки Protected EAP совместимой с Microsoft в других ОС встретить не удалось (ни для IKEv2 ни для SSTP). Владельцы MacOS и Linux остаются вне этого типа туннеля. — Существует Windows Platform (UWP) Virtual Private Network (VPN) plugin API, но его широкого применения мы не заметили. — Не все версии Windows поддерживают полный набор функций ВПН и возможностей, так как технология ориентирована в первую очередь на корпоративный сектор. |
Сложная конфигурация параметров EAP для пользователя (если процесс не автоматизирован). Для администраторов повышенный порог вхождения |
Конфиг PEAP содержит огромное количество параметров (порядка 15 важных), включающих хэши сертификатов RADIUS серверов, которым мы доверяем. Microsoft даже разработала специальный скрипт для выгрузки конфига Windows в XML формат. |
Не настраивается из GUI в Windows |
Полноценно настроить соединение со всеми преимуществами AlwaysOnVPN можно только через Intune или XML-файл. Хотя тестовое подключение выполнить можно, даже сам Microsoft рекомендует выгружать настройки PEAP из соединения, настроенного вручную, через GUI. |
Нельзя передавать сетевые параметры клиенту с сервера RAS |
На стороне клиента определяется: — Роутинг (таблица маршрутизации) — ДНС-серверы — Регистрация в ДНС — Прокси-серверы Передать эти параметры с сервера к клиенту невозможно. Чтобы поменять их, нужно переконфигурировать профиль. При «правильной» и «продуманной» настройке это не проблема и конфиг можно проверять/обновлять при каждом подключении. Кстати, Intune это делает автоматически через интернет, но он в РФ недоступен. |
Невозможно на одном RAS-сервере реализовать схему с нескольким пулами |
— Один сервер RAS – один пул адресов. — Есть возможность задавать в доменном профиле пользователя персональный выделенный IP адрес (не обязательно из пула). Так как это профиль пользователя, а не DHCP-сервер, менеджмент таких адресов будет головной болью, так как инструмента для проверки того, кому принадлежит этот адрес в домене Microsoft нет. |
Профиль ВПН — это не файл |
— Например, при использовании AnyConnect достаточно просто заменить файл для изменения конфига, но этот легкий путь – не для Microsoft. — Конфигурация находится в пространстве имен root\cimv2\mdm\dmmap, ClassName MDM_VPNv2_01. — XML-файл используется на входе для конфигурирования профиля стандартными средствами. Не все параметры, связанные с ВПН, находятся в профиле, сохраняются/задаются в XML-файле, а находятся в других местах. |
Развернуть полноценный профиль только с правами пользователя невозможно |
— Нужны права Администратора на машине (точнее от имени Системы). — Упрощенный профиль развернуть можно через GUI, но он не будет содержать полного и важного конфига ВПН. |
Стандартные команды разворачивания профиля для пользователя не работают при удаленных подключениях (например, RDP) |
Проблема актуальна, если нужно разворачивать профиль не для всех пользователей компьютера, а именно – для каких-то определенных. В этом случае разворачивание профиля проводится: — Локально (тестовая фаза) — Через диспетчер задач — Через Intune Основная сложность и корень проблемы – получение имени пользователя для которого разворачивается профиль. Скрипт создания профиля должен выполняться от имени Администратора (Системы), а профиль разворачиваться уже для пользователя. В мире, где работает Intune, мы бы и не узнали об этих сложностях. |
При разворачивании сервера «по умолчанию» создаются небезопасные конфигурации IPSec и TLS (SSTP) |
— SSTP: Поддерживаются TLS 1.0 и много очень слабых алгоритмов шифрования. Чтобы отключить слабые алгоритмы надо создавать новые параметры в реестре на сервере RAS. — IPSec: ENCR_3DES, AUTH_HMAC_SHA1, PRF_HMAC_SHA1, DF Group 2 — Пока вы не настроили IPSec параметры, посмотреть их невозможно. |
Не работает автоматическое переключение между SSTP и IKE «из коробки» |
— В режиме Automatic, несмотря на заманчивое название, подключение будет выполняться по схеме SSTP -> IKEv2->PPTP->L2TP. (почему 2 последних попали в эту схему – загадка) — Схему IKEv2->SSTP надо настраивать довольно неочевидным способом - через rasphone.pbk (т.е. это не конфиг профиля ВПН). — Можно оставить только SSTP. Можно оставить только IKEv2. А вот схемы, когда SSTP будет первым, а потом IKEv2, нет. Зато есть недокументированная функция для схемы IKEv2->SSTP: в случае отказа IKEv2 возврата к нему больше не произойдет. Изменения записываются в конфиг автоматически.Можно периодически сбрасывать этот параметр с помощью скриптов. |
Не все приложения понимают конфигурацию ВПН |
— Часть конфигурации сети проходит через Nrpt таблицы, поэтому, «старые» приложения не видят некоторых «современных» параметров. — Например, DNS серверы, настроенные в NRPT не видны такому приложению как nslookup. Если у вас особая схема с «другими» DNS для ВПН и есть приложения, пытающиеся нестандартно и самостоятельно лазать на DNS серверы, то могут быть проблемы. — То же самое касается настройки прокси сервера. Многие браузеры увидят подключение по ВПН и заберут настройки нового прокси, а вот некоторые приложения будут использовать конфиг ОС или, что хуже, свой. |
Нет синхронизации конфигурации серверов в отказоустойчивом кластере |
— Каждый сервер функционирует независимо. Нагрузку перераспределяет балансировщик. — Администраторам требуется следить за синхронностью конфигурации. Правда, однажды настроенный сервер практически не требует перенастройки. Ведь конфигурация сетевых параметров это часть конфигурации профиля пользователя, а не сервера. |
Требования к корректной конфигурации PKI |
— Если вы установили «по умолчанию» PKI от Microsoft, то сертификаты выданные таким CA работать не будут. — Самая распространенная проблема у наших клиентов – это недоступность CRL листа |
Вместо заключения
В мире Microsoft ВПН разворачивают сертифицированные профессионалы, для управления компьютерами пользователей используется Intune, MFA и условный доступ реализуется средствами облака Azure, а все приложения – обновленные и современные.
Не забываем, что пока космические корабли бороздят просторы вселенной мир, движется (и уже давно пришел) к архитектуре ZeroTrust, когда смысл использования ВПН и закрытых сетей типа DMZ приближается к нулю. Суть ZeroTrust в том, что проверяются и защищаются абсолютно все соединения – неважно, внутри или снаружи периметра организации они устанавливаются. Основной приоритет не в том, чтобы спрятать какую-то “сеть”, а в том, чтобы ее защитить, даже если кто-то из сотрудников оказался не очень надежным. И с этой точки зрения перечисленные сложности — это просто ненужный сценарий работы.
AnGord
Спасибо, интересный обзор. Чем то решение напоминает другие большие продукты от MS.
А вот утверждение по поводу потеного шествия ZeroTrust концепции сомнительно - разграничение доступа это само собой, но зачем выставлять сервис на всеобщее обозрение даже если он отлично защищён - если излишне любопытные (назовем это так) личности чего то не видят, то и ненужного интереса к этому не проявляют .
y-konstantin Автор
Я придерживаюсь подхода, когда безопасность системы должна завесить не от «скрытности», а от «качества» алгоритма защиты. К этому надо стремиться. Разумеется, есть исключения, но они, как правило, продиктованы legacy приложениями, которые невозможно обновить/поменять; желанием сэкономить; ну и банальным отсутствием компетенций. Инструменты и технологии для реализации Zero Trust уже есть и они доступны большинству.
Zero Trust у ведущих вендоров это уже давно состоявшаяся реальность. Можно по-разному относиться к концепции, но "мир" развивается в этом направлении и все меньше и меньше места остается для старых приложений, требующих наличия VPN.
В мире Microsoft уже давно никто не устанавливает ВПН для работы с Office, One Drive, Teams, Blob storages и т.д.
Вот несколько ссылок поясняющих концепцию (извините за английския язык):
Microsoft: https://www.microsoft.com/en-us/security/business/zero-trust
Cisco: https://www.cisco.com/site/us/en/solutions/security/zero-trust/index.html?ysclid=lr974tq1ii882450018#accordion-63eff36105-item-1de197f591
Checkpoint https://www.checkpoint.com/solutions/zero-trust-security/
AWS https://aws.amazon.com/security/zero-trust/?nc1=h_ls
И немного википедии для пояснения первой мысли :-/
Безопасность через неясность — Википедия (wikipedia.org)
Принцип Керкгоффса — Википедия (wikipedia.org)