mstsc не доходит до сервера: проверить NLA, имя в сертификате и сеть, не открывать 3389 в интернет

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

Клиент mstsc на WS-042 проверяйте слоями: маршрут до TCP 3389 (или шлюза RD Gateway 443), DNS имени, NLA/CredSSP, сертификат (CN/SAN = имя, которому вы подключаетесь), учётные данные ivan.petrov. Не лечите отказ открытием RDP в интернет и не отключайте NLA на сервере «навсегда» без jump-хоста и MFA. Код 0x204 у Microsoft Remote Desktop часто «не достучались», не «сломанный клиент Windows 11».

Microsoft 365 Apps здесь ни при чём, кроме путаницы «не открывается Outlook» vs «не открывается удалённый рабочий стол».

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

• Таймаут vs мгновенный отказ с текстом политики/сертификата/NLA.
• Другой ПК в том же VLAN подключается — клиент WS-042 (firewall, креды, UDP).
• Никто не подключается — сервер, служба TermService, NLA, сеть сервера.
• Только из дома — нет VPN/маршрута, см. VPN.

Не путайте с теневым сеансом helpdesk и с Quick Assist.

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

1. Нет маршрута, хост выключен, фильтр 3389.
2. Клиент резолвит старый IP (DNS cache).
3. NLA включён, учётка без права, сервер не доверяет, время.
4. Сертификат самоподписанный / имя app01 vs app01.contoso.example.
5. CredSSP / Encryption Oracle: клиент обновлён, сервер нет (или наоборот).
6. Сохранённый пароль.
7. UDP 3389 режется, кто-то выключил UDP на клиенте криво; обычно TCP достаточно.
8. RDP с Microsoft Store vs mstsc — разные коды, тот же 3389.

Диагностика

1. Порт и имя

Resolve-DnsName app01.contoso.example
Test-NetConnection app01.contoso.example -Port 3389

False на 3389 — не трогайте сертификаты. Смотрите хост firewall (профиль Domain/Public), ACL, слушает ли TermService.

2. Служба на целевом узле (если доступна консоль)

Get-Service TermService, UmRdpService | Format-Table Name, Status, StartType

Не путать с WinRM 5985.

3. Сертификат

В диалоге mstsc «не удаётся проверить подлинность». Смотрите, на какое имя подключаетесь. SAN должен его содержать. Дата, цепочка корпоративного CA на WS-042 в Trusted Root / Intermediate.

4. Политика NLA

На сервере: свойства системы → удалённый доступ → NLA. На клиенте GPO CredSSP. Журнал Microsoft-Windows-TerminalServices-Client/Operational на WS-042.

5. Креды

cmdkey /list | Select-String TERMSRV

Firewall клиента исходящий 3389 обычно разрешён; входящий на WS-042 для исходящего mstsc не нужен. Не disable профиля.

Windows 11 24H2: клиент поддерживает современные шифры; древний Server 2012 без патчей может ругаться на CredSSP. Патч сервера, не «вечный workaround oracle».

Решение

Сценарий A. Сеть

Почините IP клиента, VPN, маршрут к VLAN серверов. Test-NetConnection должен стать True. Хост спит — Wake/консоль гипервизора, не «переустановить клиент».

Сценарий B. DNS

Flush cache, подключение по FQDN. Не пишите IP в ярлык как стандарт, если нужен Kerberos/сертификат на имя.

Сценарий C. Сертификат

Выпустите шаблон Computer с SAN DNS app01.contoso.example, назначьте в «Параметры RDP» / Listener. Распространите корень CA. Пользователь жмёт «да» на неизвестный сертификат — плохая привычка; лучше нормальный шаблон.

Сценарий D. NLA / права

ivan.petrov в группе Remote Desktop Users на целевом сервере (или через GPO restricted groups по регламенту). NLA требует сетевой логон: пароль/Kerberos, не пустая гостевая.

Сценарий E. CredSSP

Установите обновления на оба конца. Не включайте AllowEncryptionOracle = 2 как постоянную политику парка.

Сценарий F. Шлюз

RD Gateway: порт 443, сертификат шлюза, RAP/CAP. Ошибка шлюза не лечится правкой 3389 на app01 с интернета.

Не используйте WS-042 как сервер RDP «чтобы с дома на свой ПК» без VPN: это тот же антипаттерн публикации 3389.

UDP: если TCP есть, а сессия рвётся — смотрите UDP/Shortpath отдельно; для «не подключается вообще» UDP не первый шаг.

Сохранённые пароли TERMSRV удалите при 1326.

На клиенте Windows 11 23H2/24H2 оставьте NLA включённым. Для проверки маршрута достаточно Test-NetConnection app01.contoso.example -Port 3389 с WS-042. Если False — не тратьте время на SAN сертификата. Если True, а mstsc ругается на имя — подключайтесь тем FQDN, который в SAN, не коротким app01, если сертификат его не содержит.

Не используйте WS-042 как постоянный RDP-сервер из интернета. Helpdesk: Intune/агент или VPN+NLA. UDP 3389 не обязателен для установления сессии по TCP; гонитесь за UDP, только когда «подключается, но рвётся качество». Сохранённые TERMSRV креды после смены пароля удаляйте, это стык с Credential Manager.

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

1. Test-NetConnection -Port 3389 True.
2. Сессия ivan.petrov на app01, рабочий стол.
3. Предупреждение сертификата исчезло (или явно доверен).
4. Повтор с холодного WS-042 после reboot.
5. С дома — только через штатный VPN/Gateway.

Снимите диагностику, если спор «у меня не работает».

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

• RDS CAL на ферме — отдельная ошибка лицензирования, не 0x204.
• Restricted Admin / Remote Credential Guard политика.
• Двойной NAT, hairpin.
• Клиент Store к Azure VM — NSG, не mstsc GPO.
• Сервер в Public профиле firewall режет 3389.

Не ставьте сторонние «RDP booster». Не отключайте NLA на DC.

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

• RDP только из VLAN admin/VPN.
• Сертификаты шаблона, FQDN.
• NLA включён, патчи CredSSP.
• Группы, не Everyone.
• Запрет проброса 3389 на периметре.

FAQ

Нужно ли включать RDP на самой рабочей станции?

Только если регламент поддержки через RDP к WS-042. Иначе helpdesk через агент/Intune. Не открывать в интернет.

mstsc vs приложение «Подключение к удалённому рабочему столу» из Store

Разные UI, один протокол. Для разбора 0x204 проверяйте 3389, не магазин.

Можно ли выключить NLA для «старого тонкого клиента»?

Только как исключение с сетью, ограниченной jump, и планом замены клиента. Не на весь OU.

Почему пинг есть, RDP нет?

ICMP ≠ 3389. Фильтр.

Encryption Oracle предупреждение

Патчи на сервер и клиент. Не постоянный AllowEncryptionOracle=Vulnerable.

Биометрия/Hello для RDP

Зависит от политики и NLA. Часто нужен пароль или смарт-карта, не PIN с локальной машины.