Как включить RDP в Windows 11 и проверить ограничения

Чтобы настроить RDP в Windows 11, я проверяю редакцию системы, включаю удалённый рабочий стол и NLA, затем ограничиваю подключения в брандмауэре. Для работы извне нужен отдельный защищённый вход. Ниже — порядок действий, команды и проверка результата: кто действительно может подключиться, а кто получает отказ.

Что проверить перед включением RDP в Windows 11

Сначала я проверяю компьютер, к которому будут подключаться. Принимать штатные RDP-подключения могут Windows 11 Pro, Enterprise и Education. Home подходит как клиент, но хостом удалённого рабочего стола не служит. Если переключателя нет, начинать с правки реестра бессмысленно: сначала смотрю редакцию. Для офиса я рассматриваю настройку удалённого доступа как настройку всего пути от сотрудника до рабочего ПК, включая учётную запись и правила сети.

Дальше открываю «Параметры → Система → О системе» и сверяю выпуск Windows с его жизненным циклом. Windows 11 22H2 уже не годится как рекомендуемая версия: обновления Home и Pro закончились 8 октября 2024 года, Enterprise и Education — 14 октября 2025 года. На дату проверки, 25 октября 2026 года, обе даты в прошлом. Я выбираю поддерживаемый выпуск, доступный для конкретного устройства, а затем устанавливаю его накопительные обновления. Название Windows 11 само по себе срок поддержки не продлевает.

До изменения доступа я уточняю, кто сможет подойти к компьютеру, если удалённое подключение оборвётся. Проверяю питание, сетевое подключение и возможность входа с консоли. Затем открываю «Параметры → Система → Удалённый рабочий стол» и включаю переключатель. Пользователю выдаю право подключения через список пользователей удалённого рабочего стола. Давать ему права администратора ради одной этой задачи не требуется: право подключиться и право менять систему — разные вещи.

Статус службы проверяю в командной строке или PowerShell командой sc.exe query TermService. Полное имя программы здесь полезно: сокращение sc в Windows PowerShell может обозначать другую команду. Состояние RUNNING говорит, что служба работает, но ещё не доказывает доступность подключения. Остаются сеть, разрешения пользователя и брандмауэр. Изменение fDenyTSConnections само по себе эти условия тоже не проверяет. Галочка в настройках — начало работы, а не акт приёмки.

• Проверить редакцию и поддержку установленного выпуска.
• Обеспечить вход с консоли на случай потери связи.
• Включить RDP и добавить только нужного пользователя.
• Проверить TermService и перейти к сетевым ограничениям.

Как ограничить RDP в брандмауэре и не оставить лазейку

Главная ошибка — добавить узкое разрешающее правило поверх широкого и решить, что остальные адреса теперь отсекаются. Старое разрешение от этого не исчезает. Я открываю брандмауэр в режиме повышенной безопасности и проверяю все входящие правила, которые могут пропускать RDP: локальные, встроенные и полученные из групповых политик. Смотрю действие, профиль сети, протокол и область удалённых адресов. Если осталось разрешение для любых источников, новый список доверенных адресов проблему не решает.

В учебном примере сеть администраторов — 10.10.0.0/24, а компьютер назначения — 10.10.0.5. Это условные частные адреса: у себя нужно подставить реальные разрешённые источники. Перед изменениями из консоли администратора сохраняю политику командой netsh advfirewall export "C:\RDP-before.wfw". Затем проверяю, что брандмауэр включён и входящие подключения по умолчанию блокируются. Экспорт храню с описанием изменений: восстановление всей политики затрагивает и другие приложения.

Если нужны отдельные правила, создаю их из консоли администратора. Этот пример разрешает вход только из указанной учебной подсети в доменном и частном профилях; широкие разрешения нужно предварительно отключить либо сузить, сохранив доступ с консоли.

netsh advfirewall firewall add rule name="RDP-Office-TCP" dir=in action=allow protocol=TCP localport=3389 remoteip=10.10.0.0/24 profile=domain,private
netsh advfirewall firewall add rule name="RDP-Office-UDP" dir=in action=allow protocol=UDP localport=3389 remoteip=10.10.0.0/24 profile=domain,private

RDP использует TCP 3389 и может использовать UDP 3389. Поэтому проверять только TCP-правило недостаточно. Если UDP в вашей схеме запрещён, я оставляю его закрытым и проверяю работу сеанса по TCP.

Не добавляю поверх этого общий запрет на тот же порт: явное блокирующее правило имеет приоритет над обычным разрешающим и может перекрыть нужные подключения. Для схемы со списком разрешённых источников достаточно корректной политики блокировки по умолчанию и отсутствия лишних разрешений. Отдельно смотрю IPv6, сетевые профили и правила из домена. После применения групповой политики ограничения должны сохраниться. Если локальные правила в организации не объединяются с доменными, меняю централизованную политику.

Временное разрешение не получает срок действия от слова Temp в имени или от параметра enable=yes. Автоматическое отключение требует отдельно настроенного и проверенного задания; без него я назначаю ответственного за удаление правила. Конкретное правило смотрю командой netsh advfirewall firewall show rule name="RDP-Office-TCP" verbose, а после теста повторяю проверку подключения из запрещённой сети. Подробнее о стандартном порте — в разборе порта удалённого рабочего стола. Перенос порта не заменяет ограничения источников.

• Проверить все действующие разрешения RDP.
• Сузить источники и проверить нужные профили.
• Учесть TCP, UDP и IPv6.
• Проверить ограничения после применения доменных политик.

Что дают NLA, блокировка учётной записи и MFA

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

Из экспертной базы здесь полезна конкретная проверка: для локальной учётной записи с пустым паролем удалённый вход должен оставаться запрещённым. В локальных параметрах безопасности нахожу политику «Учётные записи: разрешить использование пустых паролей только при консольном входе» и сохраняю её включённой. Если такой пользователь не входит по RDP, я задаю ему пароль, а не снимаю ограничение. У доменных учётных записей собственная политика паролей; переносить на них вывод о локальной настройке нельзя.

Политику блокировки ищу через secpol.msc в разделе «Политики учётных записей → Политика блокировки учётной записи». Нужны три согласованных параметра: порог неудачных входов, длительность блокировки и время сброса счётчика. Microsoft называет десять неудачных входов возможной отправной точкой, а не универсальным нормативом. Значения подбираю под офис и проверяю на отдельной тестовой записи. Для доменного пользователя проверяю действующую доменную политику. Слишком жёсткий порог позволяет постороннему мешать работе, намеренно блокируя известные имена.

Подключение компьютера к Microsoft Entra ID само по себе не гарантирует запрос Microsoft Authenticator при обычном RDP-входе. Второй фактор должен быть встроен в выбранный способ подключения. Один из документированных вариантов — RD Gateway с NPS и расширением Microsoft Entra MFA; это отдельное внедрение с проверкой требований и лицензирования. Для небольшого офиса я сначала проверяю, есть ли уже управляемый шлюз удалённого доступа с MFA. Затем закрываю прямой путь к рабочему ПК, который позволил бы пройти мимо шлюза. Установленное приложение на телефоне ещё не означает защищённый вход.

• Сохранить NLA и запрет удалённого входа с пустым паролем.
• Согласовать порог, длительность и сброс счётчика блокировки.
• Выбрать поддерживаемую интеграцию MFA.
• Проверить отсутствие прямого подключения мимо второго фактора.

Как проверить обновления без выдуманного патча RDP

Я не ищу один волшебный патч, после которого RDP навсегда безопасен. Сначала проверяю выпуск и сборку системы, затем открываю Windows Update и журнал обновлений. Сопоставляю установленное накопительное обновление с официальной историей именно этого выпуска. Пакет для другой ветки Windows не становится подходящим только потому, что в его описании тоже есть слово Security. Если обновление требует перезагрузки, включаю её в рабочее окно и после запуска проверяю подключение заново.

Фильтр по произвольному фрагменту номера KB не подтверждает устранение конкретной уязвимости. Я беру идентификатор исправления из официального описания проблемы и проверяю применимость к системе, установленную сборку и сведения о замене пакета более новым. Накопительное обновление может включать предыдущие исправления, поэтому отсутствие старого номера в отдельном списке ещё не означает отсутствие защиты. Команды на основе WMIC в универсальную инструкцию не включаю: на современных установках этой утилиты может уже не быть.

Плановые обновления Windows не означают, что каждый месяц выходит отдельное критическое исправление RDP. При появлении сообщения об уязвимости я сверяю затронутые продукты и условия эксплуатации с бюллетенем производителя. Если публикация не содержит настоящего идентификатора и ссылки на описание, она не годится как основание для срочного изменения системы. Слова «критическая дыра» без проверяемых условий — плохая замена техническому разбору. Здесь важны применимость и действие, а не громкость заголовка.

На время обслуживания я предупреждаю пользователя о разрыве сеанса, сохраняю открытые документы и проверяю резервную копию важных данных. После обновления записываю сборку, дату проверки и результат входа. Если появляется ошибка соединения, сначала отделяю сетевую недоступность от ошибки аутентификации; для второго случая пригодится разбор внутренней ошибки RDP. Массово отключать NLA или брандмауэр после любой неудачной попытки подключения я не считаю диагностикой.

• Сверить выпуск, сборку и официальную историю обновлений.
• Учесть замену старого исправления накопительным пакетом.
• Завершить требуемую перезагрузку.
• Повторить проверку доступа и сохранить результат.

Какие события входа собирать и как проверять сертификат

По экспертной базе полезная отправная точка — включённый аудит входов. В редакторе групповых политик открываю «Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Конфигурация расширенной политики аудита → Политики аудита системы → Вход/выход» и настраиваю «Аудит входа в систему» для успехов и отказов. В домене задаю это централизованно. После применения делаю тестовый вход и проверяю журнал «Безопасность» на принимающем ПК. Включённый пункт без появившегося события ещё ничего не доказывает.

Событие 4624 означает успешный вход, 4625 — неудачный. Это события разных способов входа, поэтому я не объявляю каждую запись атакой на RDP. Для 4624 тип входа 10 соответствует RemoteInteractive; при разборе учитываю также имя пользователя, время, источник и связанные события. Ошибки NLA могут отражаться иначе, поэтому ограничивать весь поиск только типом 10 нельзя. Если вход идёт через шлюз, добавляю его журналы и результат MFA. Так проще отличить опечатку в пароле от серии обращений с неожиданного адреса.

Порог оповещения выбираю после просмотра нормальной работы офиса. Смотрю серии отказов по одному пользователю, попытки с разных источников и успешный вход после необычной серии ошибок. Система мониторинга может собирать события и отправлять уведомления; от этого она автоматически не становится SIEM. В небольшой компании важнее назначить получателя сигнала и проверить доставку, чем написать красивое название системы в регламенте. Обязательно проверяю и потерю потока журналов: тишина бывает следствием отключившегося сборщика.

Ещё один конкретный факт из базы: первое подключение к RDP с самоподписанным сертификатом может вызвать предупреждение. Оно само по себе не доказывает взлом, но нажимать «продолжить» по привычке нельзя. Я сверяю имя компьютера, срок действия и доверие к сертификату, при необходимости проверяю отпечаток через независимый доверенный канал. Для регулярной работы настраиваю сертификат от центра, которому доверяют клиенты, и подключение по соответствующему имени. Подробности — в статье про сертификат удалённого рабочего стола.

• Включить аудит и получить тестовые события.
• Сопоставить отказы, успехи и журналы шлюза.
• Проверить доставку уведомления ответственному.
• Разобрать предупреждение сертификата до рабочего подключения.

Как принять настройку: три проверки и учебный разбор

С разрешённого компьютера запускаю в PowerShell Test-NetConnection -ComputerName 10.10.0.5 -Port 3389. Адрес здесь учебный. Поле TcpTestSucceeded со значением True подтверждает установление TCP-соединения из этой точки сети. Оно не проверяет пароль, сертификат, второй фактор или UDP. Затем запускаю mstsc.exe /v:10.10.0.5 и выполняю вход тестовым пользователем. Для проверки доверия к сертификату использую имя, указанное в сертификате: подключение по адресу может вызвать несовпадение имени.

С запрещённой, но маршрутизируемой до того же ПК сети повторяю TCP-проверку. Ожидаю отказ, а его причину подтверждаю действующими правилами и журналами: неуспех бывает вызван и недоступным маршрутом. При наличии IPv6 отдельно проверяю этот путь. Из внешней сети проверяю отсутствие прямого доступа к опубликованному адресу и работоспособность разрешённого входа через шлюз. Один успешный сеанс из офиса не доказывает, что интернет отрезан. Так же и сканирование из одной точки не описывает доступность порта для всех остальных.

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

Разберу учебную ситуацию для ООО «Юпитер», а не выдаю её за историю реального внедрения. Задаю три устройства: рабочий ПК 10.10.0.5 с поддерживаемой Windows 11 Pro, проверочный компьютер в разрешённой сети 10.10.0.0/24 и компьютер в другой маршрутизируемой подсети. Для упражнения выделяю час после установки обновлений; это бюджет учебной проверки, не обещанный срок услуги. Исходная ошибка — широкое встроенное разрешение осталось активным рядом с новым узким правилом. Я ограничиваю все подходящие разрешения и повторяю тесты с обоих источников.

Критерий завершения этого упражнения конкретный: разрешённый компьютер устанавливает сеанс, запрещённый не устанавливает соединение, тестовые входы видны в журнале. Для варианта со шлюзом дополнительно требуется проверенный второй фактор и отсутствие прямого внешнего пути. Я сохраняю список правил, параметры блокировки, сведения о сертификате, результаты тестов и порядок восстановления доступа. После перезагрузки и применения политик проверяю это снова. Если хотя бы одно условие не выполнено, работу ещё рано принимать: настройка должна выдерживать обычный следующий запуск компьютера.

• Проверить соединение и сеанс из разрешённой сети.
• Проверить отказ из запрещённой маршрутизируемой сети.
• Проверить внешний путь, MFA и блокировку тестовой записи.
• Сохранить результаты и повторить тест после перезагрузки.

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