Короткий ответ

RDP не должен слушаться на WAN. Схема: клиент → VPN vpn.example.com UDP (например 51820) → адрес 10.8.0.10 → RDP на 10.0.10.10:3389. На edge удалите DNAT/проброс 3389, на хостах ограничьте правило источником 10.0.10.0/24 и 10.8.0.0/24. С улицы Test-NetConnection <белый_IP> -Port 3389 обязан быть неуспешным. Не «смените порт на 3390 и успокойтесь»: сканеры найдут.

Перед снятием проброса убедитесь, что VPN и RDP через туннель уже работают у администратора. Иначе отрежете себя.

Симптомы и как отличить

  • Shodan/скан показывает 3389 на белом IP офиса или самого vpn.example.com.
  • Security log хоста: неудачные входы с публичных адресов.
  • Пользователи привыкли mstsc /v:1.2.3.4.

Это не про «RDP внутри VPN не идёт» — тогда RDP через VPN. Цель здесь — периметр.

Возможные причины

  1. Проброс на MikroTik/Cisco/домашнем роутере «временно на карантин».
  2. Azure/NSG/Security Group allow 3389/Any.
  3. Windows firewall Domain+Public Any.
  4. RDS Gateway на 443 путают с «уже безопасно» — это другой сервис, его тоже не оставляют Any без MFA.
  5. IPv6 AAAA открыт, IPv4 закрыли.

Диагностика

С хоста вне офиса (телефон LTE, не Wi-Fi офиса):

Test-NetConnection vpn.example.com -Port 3389
Test-NetConnection <WAN-IP-офиса> -Port 3389

С внутри после VPN:

Test-NetConnection 10.0.10.10 -Port 3389

На шлюзе:

nft list ruleset
iptables -t nat -L PREROUTING -n -v
ss -lnt | grep 3389
tcpdump -n -i eth0 tcp port 3389

Windows-хост:

Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Get-NetFirewallAddressFilter
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetIPAddress -AddressFamily IPv4

Решение

Сценарий A. Проброс на роутере

Удалите dst-nat WAN:3389 → 10.0.10.10:3389. Сохраните конфиг. Проверьте, что UDP VPN-порта (51820 / 500 / 4500 / OpenVPN) по-прежнему открыт точечно.

Сценарий B. Облачная NSG

Inbound 3389 только с 10.8.0.0/24 не сработает с интернета напрямую — в облаке обычно VPN-сеть как источник. Разрешите 3389 из подсети туннеля/VNet peer, Source Internet = deny.

Сценарий C. Правила на каждом Windows

$rdp = Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Where-Object Enabled -eq True
# пример узкого правила (имена адаптируйте):
New-NetFirewallRule -Name 'RDP-from-VPN' -DisplayName 'RDP from VPN 10.8.0.0/24' -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 10.8.0.0/24,10.0.10.0/24 -Action Allow

Отключите широкие стандартные правила Any, не оставляя дыру. Профиль Public — без 3389.

Сценарий D. Сервер с белым IP на NIC

Уберите белый IP с сервера приложений или фильтруйте на хосте: 3389 не с WAN-адреса. Лучше сервер только в LAN 10.0.10.0/24.

Сценарий E. Пользовательский привычный IP

Выдайте инструкцию: сначала VPN, затем pc01.contoso.example. Закройте старый путь в один день, иначе снова откроют «на час».

Дополнительно: MFA на VPN (админский VPN), журнал коннектов.

Стенд: инвентарь слушателей 3389

Не верьте только роутеру. На каждом сервере с белым IP:

Get-NetTCPConnection -LocalPort 3389 -State Listen | Format-Table LocalAddress, OwningProcess
Get-NetIPAddress -AddressFamily IPv4 | Where-Object IPAddress -notlike '10.*'

LocalAddress 0.0.0.0 плюс белый IP на NIC = RDP торчит, даже если DNAT на MikroTik уже сняли. Режьте Windows Firewall: 3389 только 10.0.10.0/24,10.8.0.0/24. IPv6: Get-NetTCPConnection -AddressFamily IPv6 -LocalPort 3389.

С LTE (не офисный Wi-Fi):

Test-NetConnection vpn.example.com -Port 3389
Test-NetConnection vpn.example.com -Port 51820

3389 fail, VPN UDP/IKE жив. Затем VPN Connect и Test-NetConnection 10.0.10.10 -Port 3389 success. Если с LTE 3389 внезапно success — закрыли не тот IP (старый NAT, второй WAN, AAAA).

Журнал Security после закрытия: попытки с публичных адресов должны иссякнуть. Если идут на другой порт (3390, 3388) — кто-то «спрятал» RDP сменой порта; найдите TermService listen и уберите WAN так же.

Rollback: консоль гипервизора/iLO до снятия DNAT. Один админ с рабочим WG-профилем в сейфе заявок, не в общем чате.

RDS Gateway на 443 не отменяет задачу. Если Gateway торчит в Internet Any, brute идёт туда. MFA на Gateway обязателен, либо уберите роль и оставьте RDP только после VPN. Проверьте Get-NetTCPConnection -LocalPort 443 на шлюзе: это IIS/VPN/OpenVPN TCP, не «ещё один RDP». Смена порта RDP на 3390 без закрытия WAN — не выполнение этой статьи. Сканеры найдут порт, Security log продолжит шуметь. VPN + фильтр источника остаётся обязательным. Зафиксируйте в политике: DNAT 3389 запрещён, review раз в квартал ss -lnt на edge.

Как проверить, что проблема устранена

  1. С LTE: 3389 на всех белых IP офиса — fail.
  2. С LTE: VPN поднимается, RDP на 10.0.10.10 — success.
  3. tcpdump на WAN не видит успешных TCP handshake 3389.
  4. В Security нет попыток с публичных IP (после TTL старых логов).
Test-NetConnection vpn.example.com -Port 3389
Get-VpnConnection
Test-NetConnection 10.0.10.10 -Port 3389

Если не помогло

  • Закрыли IPv4, открыт IPv6 — сканируйте AAAA.
  • RDS Gateway 443 Any — отдельный риск, не 3389, но тот же класс.
  • Кто-то включил TeamViewer «вместо RDP» с Any — инвентарь remote tools.
  • Cloudflare/CDN не прячет RDP; RDP не должен быть на том же IP что сайт без фильтра.

Профилактика

  • Политика: запрет DNAT 3389, review раз в квартал ss/Get-NetTCPConnection.
  • Алерт IDS на 3389 SYN с WAN.
  • Бастион + VPN для админов, не прямые столы бухгалтерии в туннель всем подряд.
  • Отзыв VPN при увольнении, иначе закрытый 3389 не спасёт.

FAQ

Смена порта вместо VPN?

Нет как основная мера. Может снизить шум сканеров, не парольный brute с целевым сканом.

Можно ли оставить 3389 для «своего» домашнего IP?

Домашний IP меняется. Это вечная заявка и ложное чувство безопасности. VPN с ключом лучше.

Нужен ли RD Gateway плюс VPN?

Избыточно для малого офиса. Если Gateway — только с MFA и не Any/Any. VPN всё равно полезен для SMB/RDP внутри.

Что с macOS Screen Sharing / VNC?

Та же идея: не WAN, только из 10.8.0.0/24.

После закрытия 3389 админ в командировке без VPN-профиля

Выдайте профиль до закрытия. Консоль гипервизора — запасной вход, не RDP в интернет.