VPN и RDP на Windows: безопасный удалённый доступ к рабочему столу

MAATRIX

Открытый в интернет порт 3389 находят автоматические сканеры, и журнал безопасности сервера быстро наполняется чужими попытками входа. Правильное решение — не усиливать пароль, а убрать сам порт из зоны видимости: RDP слушает только приватный адрес внутри VPN-туннеля, а снаружи его нет. Ниже — как собрать такую схему на Windows, как убедиться, что она реально работает, и что делать, когда что-то ломается.

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

Типовая исходная ситуация: на публичном IP открыт порт 3389, клиент подключается напрямую, единственная защита — пароль Windows. Любой бот в интернете может постучаться в этот порт и получить ответ. После настройки будет так:

• На публичном IP открыт только один порт VPN (например UDP 51820 для WireGuard). Всё остальное закрыто.
• Порт 3389 на публичном интерфейсе не отвечает вообще — для внешнего сканера RDP на этом сервере как будто не существует.
• Клиент сначала поднимает туннель, получает приватный адрес вида 10.20.0.2 и уже из этой сети идёт на 10.20.0.1:3389.
• Внутри туннеля работает NLA: даже попав в VPN-сеть, без валидных учётных данных Windows сессию не открыть.

Чем это безопаснее: атакующему нужно сначала пройти криптографическую аутентификацию VPN (у WireGuard по ключу, у IKEv2 по сертификату), и только потом он увидит, что RDP вообще существует. Перебор паролей извне становится невозможен не потому, что пароль хороший, а потому, что перебирать некуда. Уязвимости самой реализации RDP тоже уходят из-под удара.

Словарь: что это всё значит

Почему голый RDP наружу — плохая идея

Проблема не гипотетическая, а системная. Вот что реально происходит с открытым 3389:

• Порт находят без вашего участия. Сканирование всего публичного IPv4-диапазона — рутинная автоматическая операция, результаты складываются в готовые базы «открытых 3389». Свежий сервер попадает туда вскоре после запуска, даже если о нём никто не знает.
• Перебор идёт непрерывно. Ботнеты долбят типовые пары: Administrator, admin, user, словарные пароли. Фоновый шум, который не адресован лично вам и не прекращается.
• Журналы забиваются мусором, ресурсы тратятся впустую. Security Log переполняется событиями 4625, и на этом фоне легко пропустить единственное действительно важное событие. Каждая попытка — это ещё и TCP-сессия с рукопожатием: на слабом VPS поток сканеров заметен по нагрузке и объёму логов.
• RDP исторически даёт критические CVE. В протоколе и его стеке не раз находили уязвимости класса «удалённое выполнение кода без аутентификации» (BlueKeep и родственные). Пароль от такого не спасает: код выполняется до ввода пароля.
• Утечка учётных данных = мгновенный доступ. Если пароль ушёл через фишинг или заражённый компьютер, при открытом 3389 между утечкой и чужой сессией нет ни одного барьера.

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

Правильная схема: VPN-туннель + RDP только внутри него

Идея укладывается в одну фразу: сервер слушает RDP только на внутреннем VPN-интерфейсе, а на публичном 3389 закрыт наглухо. RDP должен быть виден лишь внутри частной сети, которую вы контролируете, — такую сеть и строит VPN.

[Ваш ноутбук] --VPN-туннель (WireGuard/OpenVPN/IKEv2)--> [Публичный IP сервера]
                                                                |
                                                       внутренний VPN-интерфейс
                                                       (например 10.20.0.1)
                                                                |
                                                       RDP слушает только здесь
                                                       (10.20.0.1:3389)

Ключевые правила:

1. VPN-сервер и терминальный сервер могут быть одной машиной. Поднимаете RRAS или ставите WireGuard — и та же машина принимает RDP-сессии.
2. RDP биндится на приватный адрес. Ограничьте listener конкретным IP, чтобы порт не «утёк» наружу даже при ошибке в файрволе.
3. Файрвол на внешнем интерфейсе блокирует 3389 без исключений — не «разрешить с моего домашнего IP» (адрес меняется, а исключение остаётся), а полный запрет.
4. NLA остаётся включённым внутри туннеля — на случай украденного конфига или скомпрометированного ноутбука коллеги.

Разбор связки WireGuard + RDP с конкретными адресами есть в статье про RDP через WireGuard, установка WireGuard на серверную Windows — в отдельной инструкции.

Выбор протокола VPN

Подходит любой VPN, который даёт стабильный приватный адрес и предсказуемо работает на Windows.

Для одного администратора или небольшой команды разумный дефолт — WireGuard. Если нужна интеграция без стороннего клиента, смотрите в сторону IKEv2 через RRAS.

Настройка: RDP только на VPN-интерфейсе

Шаги для WireGuard; для OpenVPN и IKEv2 логика ограничения RDP идентична, меняется только VPN-слой.

1. Поднимаем WireGuard-сервер с приватной подсетью, например 10.20.0.0/24:

# C:\Program Files\WireGuard\Data\Configurations\wg0.conf (серверная сторона)
[Interface]
PrivateKey = <серверный приватный ключ>
Address = 10.20.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <публичный ключ клиента>
AllowedIPs = 10.20.0.2/32

2. Разрешаем в файрволе только сам VPN-порт извне:

New-NetFirewallRule -DisplayName "WireGuard-In" -Direction Inbound `
  -Protocol UDP -LocalPort 51820 -Action Allow

3. Открываем RDP только со стороны VPN-подсети:

New-NetFirewallRule -DisplayName "RDP-from-VPN-only" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress 10.20.0.0/24 -Action Allow

# Политика профиля: всё, что не разрешено явно, — запрещено
Set-NetFirewallProfile -Profile Public -DefaultInboundAction Block

Важный нюанс: в Windows Firewall блокирующие правила приоритетнее разрешающих, поэтому не добавляйте отдельное правило «блокировать 3389 с Any» — оно перекроет и разрешение для VPN-подсети. И обязательно отключите штатное правило Remote Desktop, которое Windows создаёт сама при включении удалённого рабочего стола, иначе порт останется открытым.

4. Ограничиваем listener RDP приватным адресом, чтобы служба не слушала публичный интерфейс даже при ошибке в правилах. Настраивается в свойствах RDP-Tcp listener, после изменения службу перезапускают.

Ещё одна частая причина «правила вроде есть, а не работают» — профили сети (Domain/Private/Public) и то, к какому из них Windows отнесла VPN-интерфейс; разбор — в статье про настройку файрвола под VPN-туннель.

NLA поверх VPN — второй независимый слой

NLA заставляет клиента подтвердить учётные данные ещё до того, как сервер откроет графическую сессию: аутентификация проходит на уровне CredSSP, и неавторизованный клиент интерфейс входа вообще не видит. В связке с VPN это разделение ответственности — без NLA любой, кто получил VPN-конфиг, автоматически получает и экран входа RDP.

# Проверить текущее состояние NLA
(Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices `
  -Filter "TerminalName='RDP-tcp'").UserAuthenticationRequired

# Включить NLA (1 = включено)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -name "UserAuthenticationRequired" -Value 1

После включения перезапустите службу удалённых рабочих столов (Restart-Service TermService -Force) — это разорвёт текущие сессии, поэтому делайте это через консоль провайдера или в окно обслуживания. Очень старые RDP-клиенты NLA не поддерживают и не подключатся, пока не обновятся.

Как проверить, что всё сделано правильно

Настройка без проверки — это надежда, а не безопасность. Пройдите четыре пункта.

1. RDP не отвечает снаружи. С машины, которая НЕ в вашем VPN (компьютер с отключённым туннелем, телефон на мобильном интернете), просканируйте публичный адрес:

nmap -p 3389 <публичный_IP_сервера>

Ожидаемо: filtered (пакет отброшен молча) или closed. Если видите open — схема не работает. Без nmap подойдёт штатная проверка с любой Windows-машины: Test-NetConnection <публичный_IP> -Port 3389, в поле TcpTestSucceeded должно быть False. Проверять надо именно снаружи: с самого сервера или из туннеля вы получите True — верный результат, но не тот, который проверяется.

2. RDP отвечает внутри туннеля. Поднимите VPN и повторите проверку по приватному адресу — Test-NetConnection 10.20.0.1 -Port 3389 должен вернуть True.

3. Наружу открыт только VPN-порт. Просканируйте снаружи типовой набор портов. UDP-порт WireGuard штатно молчит на посторонние пакеты — отсутствие ответа на 51820 не значит, что VPN не работает.

4. Служба слушает нужный адрес. На сервере: netstat -ano | findstr :3389. Строка 10.20.0.1:3389 — правильно. Строка 0.0.0.0:3389 значит, что служба слушает все интерфейсы и вас держит только файрвол: одно неверное правило — и порт снова наружу.

Повторяйте пункт 1 после каждого крупного изменения: обновления Windows, правок в файрволе.

Типичные грабли

RDP не подключается через туннель. Проверьте, что туннель поднят и приватный адрес получен (ipconfig на клиенте), а в AllowedIPs для этого пира указан адрес клиента: при несовпадении диапазонов пакеты уходят в никуда. Тот же корень у «handshake есть, трафика нет».

Сессия отваливается при простое. У WireGuard за это отвечает PersistentKeepalive на клиенте (типовое значение — 25 секунд): без него NAT провайдера закрывает трансляцию и туннель «замерзает». Отдельно смотрите таймауты простоя RDP в групповых политиках — они рвут сессию независимо от VPN. Если рвётся и под нагрузкой — см. обрывы соединения WireGuard.

«Чёрный экран» после подключения. Сессия установилась, рабочий стол не рисуется. Обычно помогает снизить качество графики в клиенте и отключить аппаратное ускорение либо переключить транспорт с UDP на TCP. Бывает и при подключении к зависшей сессии — её нужно завершить (logoff).

Не работает буфер обмена и проброс дисков. Разрешать должны обе стороны: на клиенте — вкладка «Локальные ресурсы» в mstsc, на сервере — политики перенаправления устройств. Если работало и перестало — завис rdpclip.exe, перезапустите его.

Подвисания при передаче файлов, MTU. Интерфейс отзывается, мелкие действия проходят, а копирование файла встаёт на нескольких процентах. Это фрагментация: туннель добавляет заголовки, пакет превышает MTU по пути и молча отбрасывается. Лечится снижением MTU на VPN-интерфейсе, значение подбирается опытным путём — методика в статье про фрагментацию и подбор MTU.

Доступ пропал после перезагрузки сервера. Сервер загрузился, VPN не поднялся, RDP закрыт файрволом — вы заперты снаружи. Причина обычно в том, что туннель настроен как приложение, а не как служба с автозапуском; разбор — в статье про WireGuard после перезагрузки. До первой перезагрузки убедитесь, что запасной путь (консоль или KVM провайдера) работает.

Доступ пропал после перезагрузки роутера. Сменился ваш внешний адрес. Схема к этому устойчива — клиент инициирует соединение сам, входящие порты дома не нужны. Но если приём VPN ограничен по IP клиента, правило перестанет вас пропускать.

Приёмы, которые усиливают схему

• Ограничение доступа по IP. При статическом адресе сузьте правило для VPN-порта: принимать соединения только с него — это отсекает даже попытки рукопожатия от посторонних. Оговорка: с динамическим адресом такое правило рано или поздно запрёт вас самих.
• Смена стандартного порта — слой, а не защита. Перевод RDP с 3389 на нестандартный порт убирает шум примитивных сканеров и чистит логи. Но честно: полное сканирование находит новое расположение, и сама по себе смена порта ничего не защищает — смысл она имеет поверх изоляции сетью.
• Блокировка после N неудачных попыток. Политика Account lockout threshold (разумный старт — блокировка на 15 минут после 5 попыток) обесценивает перебор даже внутри VPN-сети. Обратная сторона: агрессивные настройки дают заблокировать собственную учётку опечаткой, поэтому держите вторую.
• Отдельный пользователь для RDP. Не работайте под встроенным Administrator: заведите именованную учётную запись с минимумом нужных прав, а встроенную отключите или переименуйте — словари перебора бьют в первую очередь по ней.
• Журналы входов. В Security Log важны три события: 4625 — неудачный вход (после закрытия порта их число должно упасть почти до нуля, всплеск значит, что источник уже внутри VPN-сети), 4624 — успешный вход (смотрите тип входа 10, это RDP, и время суток), 4771/4776 — проблемы проверки учётных данных. Сверяйте их с журналом VPN: у каждого RDP-входа должно быть парное VPN-подключение. Как выстроить учёт — в статье про аудит VPN-подключений.
• Доступ с телефона. Клиент WireGuard есть под iOS и Android, конфиг переносится QR-кодом, поверх туннеля запускается обычный RDP-клиент на приватный адрес. Заведите телефону отдельный ключ, а не копируйте ключ ноутбука: потерянный телефон тогда отзывается одной правкой конфига. Настройка — в статье про подключение WireGuard с iPhone.

Если протокол позволяет (IKEv2/SSTP через RADIUS), добавьте двухфакторную аутентификацию на входе в туннель. Ни один приём не заменяет базовую схему «VPN снаружи, RDP только внутри»; общий список мер — в чек-листе безопасности VPN-сервера.

Симптом → вероятная причина → что делать

Шпаргалка команд

Файрвол (PowerShell от администратора):

# Все правила, касающиеся порта 3389
Get-NetFirewallPortFilter | Where-Object LocalPort -eq 3389 |
  Get-NetFirewallRule | Select-Object DisplayName, Direction, Action, Enabled

# С каких адресов разрешает конкретное правило
Get-NetFirewallRule -DisplayName "RDP-from-VPN-only" | Get-NetFirewallAddressFilter

# Отключить штатное правило RDP, не удаляя его
Disable-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)"

Get-NetConnectionProfile        # какой профиль сети на каком интерфейсе

Порты и сессии:

netstat -ano | findstr :3389    # кто слушает 3389 и на каком адресе
query session                   # активные RDP-сессии
Restart-Service TermService -Force   # перезапуск службы (рвёт сессии!)

Сеть, маршруты, MTU:

ipconfig /all                                  # адреса интерфейсов, включая VPN
route print                                    # уходит ли подсеть в туннель
Test-NetConnection 10.20.0.1 -Port 3389        # доступность порта: True/False
netsh interface ipv4 show subinterfaces        # текущий MTU интерфейсов
netsh interface ipv4 set subinterface "wg0" mtu=1420 store=persistent

Журналы:

# Последние неудачные входы (4625); для успешных RDP-входов подставьте Id=4624
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 |
  Select-Object TimeCreated, Message

Частые вопросы