RD Gateway за 48 часов: CAP/RAP политики, NPS с MFA и мониторинг для 300 пользователей

В прошлую пятницу пришёл звонок от клиента на managed-сопровождении: «К понедельнику нужно перевести всех на удалёнку, сколько займёт поднять нормальный шлюз для RDP?» Суббота, 300 пользователей, ничего кроме базовой Windows Server-инфраструктуры. Мы сказали «48 часов» - и в общем-то уложились.

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

Почему RD Gateway, а не просто VPN

Клиент использует терминальные серверы для работы с ERP и внутренними приложениями. Пускать RDP напрямую через NAT или VPN с открытым портом 3389 - плохая идея, которую мы уже разбирали после BlueKeep. RD Gateway решает задачу: пользователь устанавливает один HTTPS-туннель (порт 443) до шлюза, и уже через него - RDP до нужного сервера. Наружу торчит только 443, все политики контролируются централизованно.

У клиента VPN-шлюз тоже есть, но после событий прошлой недели с перегрузкой концентраторов мы решили не добавлять на него нагрузку. RD Gateway плюс NPS - независимый путь к терминальным серверам, не трогающий VPN-инфраструктуру.

Что делали и в каком порядке

Роль сервера и SSL-сертификат

RD Gateway ставится как роль Windows Server, мы подняли его на отдельной виртуальной машине с Windows Server 2019 (4 vCPU, 8 ГБ RAM - для 300 пользователей с запасом, один RDP-туннель через шлюз потребляет мало ресурсов, основная нагрузка на терминальных серверах).

Первый камень преткновения - SSL-сертификат. RD Gateway требует доверенный сертификат: без него клиент получает предупреждение, которое часть пользователей пропускает не глядя, а часть приходит в панику. У клиента был wildcard-сертификат от коммерческого CA - его и использовали. Если сертификата нет, Let's Encrypt работает, но требует публично резолвящегося имени и автоматического обновления, что немного добавляет к сложности первоначальной настройки.

DNS-имя шлюза (rdg.client-domain.ru) прописали в публичном DNS и в A-запись внешнего IP. Всё.

CAP и RAP политики

Это самое концептуально важное в RD Gateway, и именно здесь легко напортачить.

CAP (Connection Authorization Policy) - кто вообще может подключиться через шлюз. Условия: членство в группе AD + метод аутентификации. Мы создали группу RDG-Users, добавили в неё нужные учётки, в CAP поставили условие членства в этой группе. Метод аутентификации - пароль плюс смарт-карта или пароль плюс OTP (через NPS, об этом ниже). Без попадания в CAP пользователь даже до экрана логина на терминальный сервер не доберётся.

RAP (Resource Authorization Policy) - до каких серверов можно доходить через этот шлюз. Здесь создали отдельную группу AD для терминальных серверов (RDG-TargetServers), в RAP указали только её. Это важно: без RAP с ограничением шлюз превращается в туннель до любого RDP-хоста в сети, что категорически лишнее.

Разделение CAP и RAP позволяет строить гибкие схемы: одна группа пользователей может ходить только на бухгалтерские серверы, другая - на общие терминалы. В данном случае логика простая - все через один RAP, но структура уже заложена.

NPS и MFA

Одним паролем нас не устраивала история с перебором и credential stuffing - особенно с учётом того, что мы говорим про публично доступный шлюз на 443. NPS (Network Policy Server) в роли RADIUS-сервера дал нам возможность добавить второй фактор.

Интеграцию с TOTP сделали через Azure MFA Server (клиент уже использовал Azure AD). Схема: RD Gateway отправляет аутентификацию на NPS, NPS проверяет пароль через AD, потом дёргает Azure MFA - приходит push-уведомление или запрашивается TOTP-код. Только после подтверждения второго фактора NPS возвращает Access-Accept.

Если Azure AD в инфраструктуре нет - TOTP через FreeRADIUS или другой NPS-совместимый сервер, принцип тот же. Мы это делали для других клиентов, как писали в посте про MFA-интеграцию.

Мониторинг подключений

После поднятия шлюза нужно было понимать, что происходит - сколько активных сессий, кто подключён, есть ли аномалии. RD Gateway пишет в журнал событий Windows (Microsoft-Windows-TerminalServices-Gateway), плюс есть счётчики Performance Monitor.

Настроили сбор через Zabbix: агент на шлюзе собирает счётчики текущих подключений, успешных и отклонённых аутентификаций. Алёрт на число активных сессий - при приближении к плановому максимуму (250 из 300 лицензий) и на нетипичный рост числа failed auth - потенциальный перебор.

Отдельно - журнал аудита NPS. При каждой попытке аутентификации NPS пишет событие с именем пользователя, IP-источником и результатом. Это и операционный мониторинг, и основа для расследования инцидентов.

Что заняло больше времени чем ожидалось

Первое - согласование сертификата. Wildcard был, но ответственный за PKI-часть уехал на дачу, и первые четыре часа ушли на получение файлов. Больше организационно, чем технически.

Второе - тестирование с разных клиентов. Windows 10 с RDP-клиентом 10.x работает через шлюз без проблем. Старые клиенты (встроенный mstsc на Windows 7) потребовали проверки совместимости - в итоге всё работает, но мы потеряли пару часов на выяснение почему у одного тестового пользователя ошибка подключения, которая оказалась кешированным профилем rdp с неправильным именем шлюза.

Третье - инструктаж пользователей. RDP-файл с готовыми настройками (адрес шлюза прописан, имя сервера прописано) рассылали через почту. Но часть пользователей запускала mstsc вручную и не понимала куда вводить адрес шлюза. Написали одностраничную инструкцию с картинками - это оказалось важнее любой технической настройки.

Итог и что дальше

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

Осталось несколько вещей в очереди: разбивка RAP на более детальные группы по подразделениям (чтобы бухгалтерия не могла дойти до dev-серверов даже теоретически), настройка session timeout для неактивных подключений (людей у которых ноутбук просто закрылся - отключать через 30 минут, не держать лицензию вечно), и отработка процедуры аварийного доступа если NPS недоступен.

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