RD Gateway на Windows Server 2008 R2: SSL-туннель для RDP без VPN

У одного из клиентов накопилась классическая история: полтора десятка ноутбуков у разъездных сотрудников, на каждом VPN-клиент, у каждого периодически что-то ломается - то сертификат протух, то обновление Windows снесло адаптер, то пользователь сам что-то нажал и теперь звонит в пятницу вечером. Поддержка VPN-инфраструктуры в таком масштабе - это не страшно, но муторно. Когда клиент спросил, нельзя ли как-то упростить, мы посмотрели на RD Gateway в Windows Server 2008 R2 внимательнее.

Идея простая: RDP-соединение оборачивается в HTTPS. Пользователю нужен только стандартный mstsc, сервер торчит наружу на 443-м порту, VPN на ноутбуке не нужен. С точки зрения безопасности - не хуже VPN при правильной настройке, а при неправильной - понятно.

Сертификат от корпоративного CA

Первый вопрос, который надо решить до всего остального - откуда берётся сертификат для RD Gateway. Можно купить публичный, можно выпустить от корпоративного CA. Мы пошли вторым путём: CA уже развёрнут в инфраструктуре клиента, корневой сертификат раскатан через GPO на все машины домена, так что пользователи предупреждений о недоверенном сертификате не видят.

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

На сам шлюз сертификат выпускается на внешнее DNS-имя - именно то, которое пользователь вводит в настройках mstsc. Внутренние имена тут не работают, если только не играть с split DNS, что мы и сделали: одно имя резолвится в разные IP в зависимости от того, снаружи или внутри обращаешься.

NPS-политики: кто, куда, когда

RD Gateway интегрируется с Network Policy Server - это позволяет контролировать не просто «пользователь прошёл аутентификацию», а конкретнее: этот пользователь имеет право подключаться вот к этим серверам, в такое-то время, с таких-то устройств.

Политик в NPS два типа:

• Connection Authorization Policies (CAP) - кто вообще может использовать шлюз. Сюда вешаем группу AD, членство в которой проверяется при каждом подключении.
• Resource Authorization Policies (RAP) - к каким ресурсам за шлюзом разрешён доступ. Отдельная группа AD для ресурсов, отдельная для пользователей.

Такая схема позволяет гибко управлять доступом: командировочный ноутбук - в одну группу, постоянный удалённый сотрудник - в другую, доступные серверы у каждой группы свои. Это не rocket science, но без NPS-политик шлюз превращается в дыру размером в весь периметр.

Отдельно настраивается таймаут сессии и idle disconnect - чтобы брошенные сессии не висели вечно. Для сотрудников это иногда неудобно, но с точки зрения безопасности нужно.

OTP-токены: второй фактор

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

Мы подключили OTP через RADIUS: NPS принимает запросы аутентификации, перенаправляет на RADIUS-сервер с OTP-бэкендом, тот проверяет одноразовый пароль. Пользователь при подключении вводит пароль в формате PIN+OTP - это стандартная схема для RADIUS с токенами.

Токены - аппаратные, TOTP-совместимые. Настройка со стороны пользователя минимальная: в поле пароля вводишь PIN и шестизначный код с токена. Несколько раз пришлось объяснять лично, потом написали одностраничную инструкцию - и вопросы прекратились.

Один момент, который мы не учли сразу: time sync. OTP-токены завязаны на время, и если на RADIUS-сервере время расходится больше чем на 30 секунд - аутентификация падает с непонятными ошибками. Пришлось убедиться, что NTP настроен и работает. Банальность, но потеряли на диагностике лишний час.

Что получилось в итоге

После внедрения картина стала такой:

• На ноутбуках нет ничего, кроме стандартного mstsc. Никаких VPN-клиентов, никаких дополнительных агентов.
• Подключение - HTTPS на 443 порт шлюза, дальше RDP внутрь. Работает через любой нормальный файрвол, в том числе гостевой WiFi в гостиницах, где обычные VPN-порты нередко заблокированы.
• Аутентификация - логин/пароль домена плюс OTP-токен.
• Аудит - все подключения логируются на шлюзе и в NPS, видно кто, когда, с какого IP и на какой ресурс подключался.

Несколько звонков «VPN сломался» уже не поступало - просто потому что VPN больше нет. Это пока рано называть победой, но первые недели эксплуатации прошли тихо.

Остался открытым вопрос с личными устройствами: что делать, если сотрудник хочет подключиться с домашнего компьютера, не входящего в домен. RD Gateway технически это позволяет - сертификат публичного CA решает проблему доверия, - но политика безопасности клиента ещё не определилась, разрешать ли такой сценарий. Пока доступ разрешён только с корпоративных машин.

Если у вас похожая задача - в рамках сопровождения ИТ-инфраструктуры мы разворачиваем подобные схемы под конкретные требования, включая интеграцию с уже имеющимися средствами аутентификации.