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

Если ping до 10.0.10.10 есть, а RDP нет — это уже не «VPN сломан», а порт 3389/tcp на хосте, профиль firewall (Public vs Domain), NLA/CredSSP и имя в сертификате/SPN. Не открывайте 3389 на WAN vpn.example.com, чтобы «проверить». Диагностика: Test-NetConnection 10.0.10.10 -Port 3389 с клиента туннеля 10.8.0.0/24, затем правила на целевой Windows.

RDP по IP часто проходит NLA хуже, чем по FQDN pc01.contoso.example, если включена проверка аутентификации на уровне сети и Kerberos.

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

  • VPN Connected, ICMP ок, mstsc висит / «не удалось подключиться».
  • TcpTestSucceeded : False на 3389.
  • Ошибки NLA, CredSSP, «срок действия сертификата».
  • По IP входим, по имени нет — DNS; наоборот — firewall по имени не при чём, смотрите NLA/Kerberos.

Не это: нет ping — LAN. Сессия рвётся на картинке — MTU. Цель — убрать RDP из интернета — закрыть 3389.

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

  1. На хосте firewall разрешает RDP только профилю Domain, а NIC в Public (особенно после VPN на самом хосте — редкость, чаще у невведённых в домен).
  2. Служба TermService не running / RDP выключен в System properties.
  3. NLA, клиент старый, или время/secure channel.
  4. DNS не резолвит pc01.contoso.example через VPN.
  5. Хост слушает 3389 только на LAN NIC, не на адресе, куда приходит SNAT с VPN-шлюза — обычно всё же 0.0.0.0, но бывают dual-homed с узким bind.
  6. NLA + вход по IP = NTLM, политика запрещает.
  7. Network Level Authentication требует доменный ДК, недоступный с этого VPN (нет маршрута к DC).

Диагностика

1. Порт с клиента VPN

Test-NetConnection 10.0.10.10 -Port 3389
Resolve-DnsName pc01.contoso.example
Get-VpnConnection
ipconfig

Linux:

ip route get 10.0.10.10
nc -vz 10.0.10.10 3389

2. На целевом хосте

Get-Service TermService
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 3389 }
Get-NetConnectionProfile
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections

fDenyTSConnections = 1 — RDP выключен.

3. Профиль и правило

Правило «Remote Desktop» должно быть Enabled для профиля, который реально на NIC (часто Domain.example). Если профиль Public — либо почините определение сети, либо добавьте узкое правило: 3389 только с 10.8.0.0/24, не «Public any».

4. NLA / DC

nltest /dsgetdc:contoso.example
w32tm /query /status

Если с хоста нет DC, NLA для доменных учёток развалится. Тогда либо маршрут к DC через ту же LAN, либо (хуже) временный локальный аккаунт для аварии — с последующим отзывом.

Решение

Сценарий A. Порт закрыт

Enable-NetFirewallRule -DisplayGroup 'Remote Desktop'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 0

Затем сузьте правило до источника 10.8.0.0/24 и LAN 10.0.10.0/24. Проверьте, что WAN-интерфейс не входит в scope.

Сценарий B. Профиль Public

Верните машину в Domain profile (DNS суффикс, DC). Как костыль — правило RDP для Public только с 10.8.0.0/24. Не Public + Any.

Сценарий C. DNS/имя

Почините DNS через VPN, подключайтесь к pc01.contoso.example. Если только IP — ожидайте NTLM и возможные политики ограничения.

Сценарий D. MTU

TCP SYN проходит, сессия мрёт на графике — clamp MSS, статья MTU.

Сценарий E. Подрядчик

Не давайте 3389 на все 10.0.10.0/24. Один бастион, см. подрядчик.

Стенд: NLA, DC и SNAT

Клиент в 10.8.0.10 стучится на 10.0.10.10:3389. На шлюзе включён MASQUERADE в LAN, хост видит источник 10.0.10.1 (VPN-сервер). Firewall «Remote Desktop / Local subnet» пропускает. Без SNAT источник 10.8.0.10, правило Local subnet не включает туннель — SYN drop, ping при этом мог быть разрешён отдельно. Снимите Get-NetFirewallRule с AddressFilter и tcpdump на хосте: виден ли SYN с 10.8.0.10.

NLA: хост должен достучаться до DC за TGT. Если VPN-пользователь ходит на workstation, а с workstation нет маршрута к DC (изолированный VLAN) — RDP по доменной учётке падает, локальная проходит. Это не «сломан VPN», а зависимость NLA от DC. Либо пустите хост к DC, либо используйте бастион в LAN, где DC доступен.

Test-NetConnection 10.0.10.10 -Port 3389
nltest /dsgetdc:contoso.example
whoami /upn

Не публикуйте 3389 «на час», чтобы отличить NLA от сети: отличите TcpTestSucceeded и NLA-текст ошибки. Публикация WAN смешивает инцидент с brute-force.

Проверка с двух источников

Сделайте RDP с хоста в LAN 10.0.10.20 и с VPN 10.8.0.10. Если LAN ок, VPN нет — фильтр по источнику или маршрут. Если оба нет — TermService/NLA, не туннель. Зафиксируйте оба Test-NetConnection в заявке, иначе L2 начнёт крутить AllowedIPs вхолостую.

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

С клиента в 10.8.0.0/24:

Test-NetConnection pc01.contoso.example -Port 3389
# mstsc /v:pc01.contoso.example

Вход с доменной учёткой, NLA проходит. С WAN адреса компании Test-NetConnection vpn.example.com -Port 3389 должен быть False (RDP не торчит в интернет). Ping по-прежнему жив.

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

  • Слушает 3389, SYN есть, сразу RST — политика NLA/CredSSP, патчи CredSSP.
  • RDS broker / NLB — не «простой» хост, смотрите коллекцию RDS, не firewall ПК.
  • Mac/мобильный клиент RDP старый — NLA.
  • Хост за своим фаерволом третьей стороны (CrowdStrike hardening) — правило там.

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

  • RDP только из LAN + 10.8.0.0/24.
  • Не публиковать 3389/tcp на edge.
  • Мониторинг слушающего 3389 на WAN.
  • NLA включён, время синхронно с DC.

FAQ

Почему с офиса RDP есть, с VPN нет?

Источник другой: 10.8.0.10 vs 10.0.10.20. Правило «Remote Desktop / Domain / Local subnet» не включает туннель. Добавьте 10.8.0.0/24 или SNAT в LAN (хуже для логов).

Нужно ли отключать NLA для VPN?

Нет. Почините DNS, время, DC. Отключение NLA расширяет аутентификацию до полного RDP handshake.

IP работает, имя нет

DNS/NRPT. Статья DNS.

Можно ли сменить порт с 3389?

Да, усложняет сканеры, не заменяет VPN и firewall. Документируйте, не считайте это «безопасностью».

Get-VpnConnection Connected, mstsc на localhost хоста

Вы подключились не туда. Цель — 10.0.10.10, не 127.0.0.1 и не WAN vpn.example.com.