Remote Desktop Gateway: настройка безопасного удалённого доступа через HTTPS

Открытый порт 3389 во внешнюю сеть — это не просто риск, это гарантированные брутфорс-атаки. Мы проверяли: среднестатистический Windows Server с проброшенным RDP получает первые попытки подбора пароля уже через 10–15 минут после появления в интернете. Remote Desktop Gateway (RD Gateway, ранее TS Gateway) закрывает эту дыру: весь RDP-трафик упаковывается в HTTPS-туннель через порт 443. Клиент цепляется к шлюзу по SSL, а шлюз сам разруливает соединение до нужного сервера или рабочей станции внутри сети. В этом руководстве поднимем RD Gateway с нуля на Windows Server 2019/2022, настроим политики доступа, прикрутим SSL-сертификат и разберём грабли, на которые наступают администраторы при первом развёртывании.

Зачем нужен RD Gateway и как он работает?

RD Gateway — это посредник между внешним миром и вашей RDS-инфраструктурой. Клиент поднимает HTTPS-соединение со шлюзом на порту 443, проходит аутентификацию, и только после этого шлюз создаёт RDP-сессию с нужным сервером внутри корпоративной сети. На внешнем файрволе открыт исключительно 443/TCP. Порт 3389 снаружи вообще не торчит.

Чем это лучше VPN-подключения:

• Никакого VPN-клиента — пользователь запускает стандартный mstsc.exe, который стоит на любой Windows
• Работает отовсюду, где пропускают HTTPS — гостиничный wi-fi, аэропорт, кофейня с параноидальным файрволом
• Доступ управляется через политики CAP/RAP централизованно, без ковыряния настроек на каждом сервере
• Каждое подключение пишется в лог с IP-адресом и именем пользователя — потом легко разобраться, кто, когда и куда ходил
• Интегрируется с NPS/RADIUS — можно подключить двухфакторную аутентификацию без лишних плясок

Требования и подготовка к установке

Что понадобится для развёртывания RD Gateway:

• Windows Server 2016/2019/2022 — редакция Standard или Datacenter
• SSL-сертификат — самоподписанный подойдёт для стенда, для продуктива берите Let's Encrypt или коммерческий CA
• Внешний IP-адрес с DNS-записью — например, rdgw.company.ru
• Порт 443/TCP на внешнем файрволе, пробросить на сервер шлюза
• Опционально: 3391/UDP — UDP-транспорт, даёт заметный прирост отзывчивости RDP-сессии

Шлюз можно поднять как на отдельной машине в DMZ, так и совместить с другими ролями RDS — RD Session Host, RD Connection Broker. Если честно, в продуктиве мы всегда рекомендуем выделенный сервер: и безопаснее, и проще разбираться с проблемами, когда что-то пойдёт не так.

Установка роли RD Gateway через PowerShell

Запустите PowerShell от имени администратора и выполните:

# Установка роли RD Gateway со всеми компонентами
Install-WindowsFeature RDS-Gateway -IncludeAllSubFeature -IncludeManagementTools

# Проверка установленных ролей
Get-WindowsFeature RDS* | Where-Object Installed -eq $true

После установки в системе появится оснастка RD Gateway Manager (tsgateway.msc). Сервер в домене — роль сама зарегистрируется в Active Directory. Рабочая группа — ничего дополнительно настраивать не нужно, всё работает на локальных группах.

Создание и настройка SSL-сертификата

SSL-сертификат — это не просто галочка в настройках. CN или SAN в сертификате обязан совпадать с тем DNS-именем, по которому клиенты будут подключаться к шлюзу. Не совпадает — получите ошибку сертификата у каждого пользователя.

Вариант 1: Самоподписанный сертификат (для тестов)

# Создаём самоподписанный сертификат на 5 лет
$todaydate = Get-Date
$addyear = $todaydate.AddYears(5)
$cert = New-SelfSignedCertificate `
    -DnsName "rdgw.company.ru","192.168.1.100" `
    -NotAfter $addyear `
    -CertStoreLocation cert:\LocalMachine\My `
    -KeyLength 2048

# Экспортируем для распространения на клиентов
Export-Certificate -Cert $cert -FilePath C:\rdgw-cert.cer
Write-Host "Thumbprint: $($cert.Thumbprint)"

Самоподписанный сертификат придётся вручную раскидать по клиентским машинам в хранилище Trusted Root Certification Authorities. В доменной среде проще: раскатываете через GPO за пару минут.

Вариант 2: Let's Encrypt (для продуктива)

# Установка win-acme
Invoke-WebRequest -Uri "https://github.com/win-acme/win-acme/releases/latest" -OutFile wacs.zip
Expand-Archive wacs.zip -DestinationPath C:\wacs

# Запрос сертификата (интерактивный режим)
C:\wacs\wacs.exe --target manual --host rdgw.company.ru `
    --store certificatestore --certificatestore My `
    --installation script --script "C:\scripts\update-rdgw-cert.ps1"

Настройка политик подключения (CAP) и ресурсов (RAP)

RD Gateway контролирует доступ через два типа политик:

• Connection Authorization Policy (CAP) — отвечает на вопрос кто вообще может аутентифицироваться на шлюзе
• Resource Authorization Policy (RAP) — определяет, к каким серверам конкретный пользователь получит доступ через этот шлюз

Подготовка групп в Active Directory

# Группа пользователей, которым разрешена аутентификация на шлюзе
New-ADGroup -Name "rdgwExtUsers" -GroupScope Global `
    -Path "OU=Groups,DC=company,DC=ru"

# Группа администраторов с доступом к серверам через шлюз
New-ADGroup -Name "rdgwExternalAdmins" -GroupScope Global `
    -Path "OU=Groups,DC=company,DC=ru"

# Группа целевых серверов
New-ADGroup -Name "rdgwTargetServers" -GroupScope Global `
    -Path "OU=Groups,DC=company,DC=ru"

# Добавляем пользователей и серверы
Add-ADGroupMember -Identity "rdgwExtUsers" -Members user1,user2,user3
Add-ADGroupMember -Identity "rdgwExternalAdmins" -Members admin1,admin2
Add-ADGroupMember -Identity "rdgwTargetServers" -Members "SRV-RDS01$","SRV-RDS02$"

Создание политик через PowerShell

# Импортируем модуль
Import-Module RemoteDesktopServices

# Создаём CAP — разрешаем аутентификацию группе rdgwExtUsers
New-Item -Path 'RDS:\GatewayServer\CAP' `
    -Name 'AllowExternalUsers-CAP' `
    -UserGroups "rdgwExtUsers@company.ru" `
    -AuthMethod 1

# Создаём RAP — разрешаем доступ к серверам из группы rdgwTargetServers
New-Item -Path 'RDS:\GatewayServer\RAP' `
    -Name 'AllowRDSServers-RAP' `
    -UserGroups "rdgwExternalAdmins@company.ru" `
    -ComputerGroupType 1 `
    -ComputerGroup "rdgwTargetServers@company.ru"

Привязка сертификата к RD Gateway

Когда политики созданы, привязываем SSL-сертификат к службе шлюза:

# Привязка сертификата через PowerShell
$cert = Get-ChildItem cert:\LocalMachine\My | Where-Object {
    $_.Subject -like "*rdgw.company.ru*"
}
Set-Item -Path "RDS:\GatewayServer\SSLCertificate\Thumbprint" `
    -Value $cert.Thumbprint

# Перезапуск службы
Restart-Service TSGateway

Можно сделать то же самое через оснастку RD Gateway Manager: правый клик на имени сервера → Properties → вкладка SSL Certificate → Select Existing Certificate.

Настройка RDP-клиента для подключения через шлюз

На клиентской машине открываем mstsc.exe и настраиваем подключение:

1. В поле Computer — внутреннее имя или IP целевого сервера, например SRV-RDS01.company.ru
2. Вкладка Advanced → Settings в разделе Connect from anywhere
3. Выбираем Use these RD Gateway server settings
4. В поле Server name — внешнее DNS-имя шлюза: rdgw.company.ru
5. Ставим галочку Use my RD Gateway credentials for the remote computer — так пользователь не будет вводить пароль дважды

# Альтернативный способ — через .rdp файл
full address:s:SRV-RDS01.company.ru
gatewayhostname:s:rdgw.company.ru
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
gatewayaccesstoken:s:
gatewaycredentialssource:i:0

Настройка RD Gateway в рабочей группе (без домена)

Active Directory есть далеко не у всех. RD Gateway отлично работает и без домена — на локальных группах и учётных записях. Мы разворачивали такую схему в небольших компаниях, всё прекрасно живёт.

# Создаём локального пользователя для подключения
New-LocalUser -Name "rdpuser1" -Password (ConvertTo-SecureString "P@ssw0rd!" -AsPlainText -Force)
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "rdpuser1"

# Создаём CAP с локальной группой
New-Item -Path 'RDS:\GatewayServer\CAP' `
    -Name 'Workgroup-CAP' `
    -UserGroups "BUILTIN\Remote Desktop Users" `
    -AuthMethod 1

# Создаём RAP — разрешаем подключение к любому компьютеру
New-Item -Path 'RDS:\GatewayServer\RAP' `
    -Name 'Workgroup-RAP' `
    -UserGroups "BUILTIN\Remote Desktop Users" `
    -ComputerGroupType 2

Мониторинг подключений и аудит безопасности

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

# Просмотр успешных подключений (Event ID 302)
$properties = @(
    @{n='User';e={$_.Properties[0].Value}},
    @{n='SourceIP';e={$_.Properties[1].Value}},
    @{n='TimeStamp';e={$_.TimeCreated}},
    @{n='TargetHost';e={$_.Properties[3].Value}}
)
Get-WinEvent -FilterHashTable @{
    LogName='Microsoft-Windows-TerminalServices-Gateway/Operational'
    ID=302
} -MaxEvents 50 | Select-Object $properties | Format-Table -AutoSize

Event ID, за которыми стоит следить:

• 300 — пользователь успешно прошёл аутентификацию на шлюзе, CAP отработала штатно
• 302 — соединение с целевым ресурсом поднято, RAP проверку прошла
• 303 — пользователь сам закрыл сессию
• 304 — сессия упала по таймауту простоя
• 312 — ошибка аутентификации: неверный пароль, истёкший аккаунт или что-то сломалось в Kerberos

Интеграция с NPS для двухфакторной аутентификации

Один фактор — это слабо. Особенно когда речь о точке входа из интернета. RD Gateway умеет работать с RADIUS через Network Policy Server (NPS), и это самый прямой путь прикрутить второй фактор без сторонних костылей.

# Установка роли NPS
Install-WindowsFeature NPAS -IncludeManagementTools

# Регистрация NPS в Active Directory
netsh ras add registeredserver

В оснастке RD Gateway Manager заходите в Properties → RD CAP Store, переключаете на Central NPS, указываете IP-адрес NPS-сервера и shared secret. На стороне NPS прописываете RADIUS-клиент — им будет ваш RD Gateway — и настраиваете политику подключения, которая требует второй фактор. Что использовать: Azure MFA Extension, MultiFactor, что-то своё — решать вам, вариантов хватает.

Оптимизация производительности RD Gateway

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

• Включите UDP-транспорт — откройте порт 3391/UDP на файрволе. На практике это заметно снижает задержки, особенно там, где гоняют видео или работают с графическими приложениями
• Настройте таймауты — в свойствах CAP выставьте idle timeout в районе 15-30 минут. Брошенные сессии иначе держат ресурсы часами
• Отключите ненужное перенаправление — в Device Redirection политики CAP уберите перенаправление принтеров и дисков, если реально никто ими не пользуется. Меньше трафика, меньше проблем
• Мониторьте загрузку IIS — RD Gateway живёт поверх IIS, и пул приложений RPC вполне может стать узким местом под нагрузкой

# Проверка текущих активных подключений
Get-WmiObject -Namespace "root\cimv2\TerminalServices" `
    -Class "Win32_TSGatewayConnection" |
    Select-Object UserName, ConnectedResource, ConnectedTime |
    Format-Table -AutoSize

Типичные ошибки и их решение

Ошибка: «Не удалось подключиться к шлюзу удалённых рабочих столов»

Когда подключение не идёт, сначала проверяем четыре вещи: резолвится ли DNS-имя шлюза с клиентской машины; открыт ли 443-й порт на файрволе; запущена ли служба TSGateway; не протух ли сертификат и совпадает ли CN/SAN с тем DNS-именем, которое указал клиент. Половина обращений в поддержку закрывается на этих четырёх пунктах.

Ошибка: «Ваш компьютер не может подключиться к удалённому компьютеру» (код 0x804)

Такое бывает: CAP пользователя пропустила, а подключение до сервера всё равно не доходит. Здесь смотрите RAP — скорее всего, целевой сервер просто не входит в группу компьютеров, которая там прописана. Добавьте его в нужную группу, и всё заработает.

Ошибка NTLMv1 и уязвимость Channel Binding

Чтобы закрыть возможность relay-атак, пропишите в реестре RD Gateway следующее:

# Включение Channel Binding для защиты от NTLM-relay
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core" `
    -Name "EnforceChannelBinding" -Value 1 -Type DWord

Балансировка нагрузки нескольких шлюзов

Один шлюз — это единая точка отказа, и в продуктиве это риск. Мы обычно ставим два-три сервера RD Gateway за балансировщиком — NLB, HAProxy, F5, кому что ближе. Важный момент: на всех шлюзах должен стоять одинаковый SSL-сертификат, wildcard или с нужными SAN под общее имя. Политики CAP/RAP хранятся локально на каждой машине, централизованного хранилища нет, так что синхронизировать их придётся руками или скриптом — это немного неудобно, но жить можно.

# Экспорт политик с первого шлюза
Export-Module RDGateway -Path C:\rdgw-policies-backup

# На каждом шлюзе в ферме:
# 1. Установите роль RDS-Gateway
# 2. Привяжите общий сертификат
# 3. Импортируйте одинаковые политики CAP/RAP

Настройка RemoteApp через RD Gateway

RD Gateway умеет пробрасывать не только полные рабочие столы. RemoteApp через шлюз работает отлично — просто добавьте нужные параметры в .rdp-файл приложения:

# Параметры RD Gateway в .rdp файле RemoteApp
gatewayhostname:s:rdgw.company.ru
gatewayusagemethod:i:1
gatewayprofileusagemethod:i:1
remoteapplicationmode:i:1
remoteapplicationname:s:1C Предприятие
remoteapplicationprogram:s:||1cv8c
alternate full address:s:SRV-RDS01.company.ru

Защита RD Gateway: лучшие практики безопасности

• Используйте доверенный SSL-сертификат — самоподписанный сертификат создаёт головную боль с мобильными клиентами и не закрывает риск MITM. Мы видели, как из-за этого компании неделями не могли нормально развернуть мобильный доступ
• Включите NLA (Network Level Authentication) на целевых серверах — без него пользователь видит экран входа ещё до аутентификации, что само по себе уже нехорошо
• Ограничьте список серверов в RAP — ComputerGroupType 2 разрешает подключение к любому серверу сети. В продуктиве это недопустимо, точка
• Настройте блокировку учётных записей — 5 неудачных попыток, потом 30 минут блокировки. Без этого шлюз, торчащий в интернет, будет перебираться брутфорсом
• Регулярно проверяйте логи — настройте алерты на Event ID 312. Если видите всплеск этих событий ночью с одного IP — уже есть повод разбираться
• Обновляйте сервер — RD Gateway смотрит в интернет, и дыры в нём находят регулярно. Критические обновления безопасности ставить сразу, без откладывания на потом