Какой порт у RDP, как его проверить и сменить в Windows — и зачем это на самом деле нужно

RDP по умолчанию слушает порт 3389, и по TCP, и по UDP. Сменить его можно одним параметром реестра PortNumber плюс правило в брандмауэре и перезагрузка. Но защитой это не является. Ниже: как проверить порт, как сменить без потери доступа, что ломается и чем заменить «безопасность через номер порта».

Какой порт использует RDP: 3389 по умолчанию, TCP и UDP

Короткий ответ: стандартный порт протокола удалённого рабочего стола — 3389. В официальной таблице портов Remote Desktop Services у Microsoft он записан как «TCP and UDP 3389: Standard Remote Desktop Protocol (RDP) port» с пометкой, что номер можно настроить на хосте и на клиенте. Вопрос «rdp port» мне задают почти на каждом первом звонке, когда у клиента что-то не подключается или когда подрядчик просит «открыть порт на роутере». Если вам нужен не просто номер порта, а нормальный удалённый доступ к рабочим местам через VPN, то порт — самая малая часть задачи, и дальше я объясню почему.

Важная деталь, которую часто упускают: RDP использует не только TCP. Современные клиенты пробуют ещё и UDP на том же номере, он нужен для более плавной картинки на нестабильных каналах. Поэтому, когда вы открываете или закрываете порт в брандмауэре, думайте о паре TCP плюс UDP. Если открыт только TCP, подключение, как правило, всё равно работает, просто идёт целиком по TCP. Это нормально, и бежать открывать UDP «потому что так написано в статье» не надо. Я оставляю UDP открытым только там, где пользователи реально жалуются на лаги по Wi-Fi или через интернет-канал.

Отдельно стоят порты шлюза удалённых рабочих столов. По той же таблице Microsoft, для RD Gateway снаружи используются TCP 443 (HTTP поверх SSL, в том числе RPC over HTTP) и UDP 3391 (RDP поверх UDP), оба номера настраиваются в консоли RD Gateway Management. А внутри, от шлюза к самим серверам, снова TCP и UDP 3389. Это ключ к нормальной архитектуре: наружу смотрит 443, а 3389 остаётся только внутри сети. Для RD Web Access добавляется TCP 443, а брокеру подключений нужны свои порты, но в офисе на 10–20 мест брокер обычно не нужен совсем.

Чтобы не путаться, держите перед глазами короткую таблицу. Она собрана из документа Microsoft «Ports That Are Used by RDS» и описывает только то, что нужно малому офису. | Направление | Порт | Зачем | |---|---|---| | Клиент → сервер или ПК напрямую | TCP и UDP 3389 | Стандартный RDP, меняется параметром реестра | | Клиент → RD Gateway снаружи | TCP 443 | RDP внутри HTTPS | | Клиент → RD Gateway снаружи | UDP 3391 | RDP поверх UDP, настраивается в консоли шлюза | | RD Gateway → внутренние серверы | TCP и UDP 3389 | Внутренний RDP за шлюзом |

Как узнать, на каком порту сейчас работает RDP

Прежде чем что-то менять, выясните, что стоит сейчас. Я видел офисы, где предыдущий админ уже сменил порт «для безопасности», записал номер в голове и уехал в другой город, а новый человек полчаса ищет, почему на 3389 никто не отвечает. Номер порта лежит в реестре, в ключе HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, параметр PortNumber. Microsoft в своей инструкции предлагает читать его так, в PowerShell от администратора:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name 'PortNumber'

В выводе будет строка PortNumber с числом. Если там 3389, порт стандартный.

Значение в реестре говорит, на что настроено, но не говорит, что служба реально слушает порт. Проверить это можно штатным командлетом Get-NetTCPConnection, у которого есть параметры -LocalPort и -State. Подставьте номер из реестра:

Get-NetTCPConnection -LocalPort 3389 -State Listen

Если строка вернулась, служба терминалов слушает порт. Если команда сообщает, что подходящих соединений нет, значит порт в реестре поменяли, но перезагрузка ещё не прошла, или служба не запущена. Это самая частая причина «вроде поменяли, а не работает».

Третья проверка — с клиента, по сети, потому что именно она отражает путь пользователя вместе с брандмауэром и роутером. В PowerShell на клиентском компьютере используйте Test-NetConnection с параметрами -ComputerName и -Port:

Test-NetConnection -ComputerName 192.0.2.10 -Port 3389

В выводе нас интересует поле TcpTestSucceeded: True означает, что TCP-соединение установилось. Заодно у этого командлета есть удобный параметр -CommonTCPPort RDP, который проверяет стандартный порт без указания номера. Помните, что Test-NetConnection проверяет только TCP. Про UDP он ничего не скажет, и для проверки UDP-транспорта придётся смотреть на поведение клиента.

Как сменить порт RDP в Windows: реестр, брандмауэр, подключение

Порядок действий у меня всегда одинаковый, и первое правило — не делать это по удалённой сессии, пока вы не уверены в двух вещах: новое правило брандмауэра создано и есть второй способ попасть на машину (консоль гипервизора, физический доступ, соседний сервер). Иначе вы сами себя отрежете. Ссылаюсь на актуальную страницу Microsoft «Change Remote Desktop listening port on Windows and Windows Server». Первым шагом меняем параметр PortNumber. Через PowerShell от администратора это выглядит так, номер 3390 взят как пример:

$portValue = '3390'
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name 'PortNumber' -Value $portValue

То же самое можно сделать вручную в Registry Editor: открыть тот же ключ, выбрать PortNumber, Edit, Modify, переключить систему счисления на Decimal, ввести номер. Эту деталь про Decimal стоит запомнить: если оставить шестнадцатеричное, получите совсем другой порт.

Вторым шагом открываем новый порт в брандмауэре Windows. Microsoft в той же инструкции даёт два правила, на TCP и на UDP. Обратите внимание на параметр -Profile: в примере Microsoft стоит Public. Если ваша сеть в Windows определена как Private или Domain, такое правило к ней не применится, и вы получите «порт открыт в правиле, но не отвечает». Параметр -Profile по умолчанию равен Any, поэтому я просто его не указываю, а доступ сразу сужаю по адресу источника. Параметр -RemoteAddress принимает адрес, подсеть в виде 192.0.2.0/24, диапазон или ключевое слово LocalSubnet:

$portValue = '3390'
New-NetFirewallRule -DisplayName 'RDP-custom-TCP-In' -Direction Inbound -Action Allow -Protocol TCP -LocalPort $portValue -RemoteAddress 192.0.2.0/24
New-NetFirewallRule -DisplayName 'RDP-custom-UDP-In' -Direction Inbound -Action Allow -Protocol UDP -LocalPort $portValue -RemoteAddress 192.0.2.0/24

Если у вас стоит ещё и сторонний брандмауэр или UTM, Microsoft прямо предупреждает в блоке Important: разрешить новый порт нужно и там.

Третьим шагом перезагрузка. В актуальной инструкции Microsoft (вариант через Registry Editor) последний шаг так и звучит: «restart your computer». В старой документации по Windows Server 2008 R2 (описание события 260 слушателя RDP) вместо перезагрузки предлагалось перезапустить службу Remote Desktop Services и затем убедиться, что порт сменился, но на рабочем сервере я всё равно не рестартую службу при живых сессиях: пользователей выкинет. Делаю вечером, когда никого нет. После перезагрузки подключаемся с указанием порта через двоеточие, как в примере Microsoft про pc1.contoso.com:3390. В нашем случае из командной строки:

mstsc /v:192.0.2.10:3390

В графическом окне Remote Desktop Connection адрес пишется точно так же: имя или IP, двоеточие, порт. После проверки можно удалить или отключить старое правило для 3389, но делайте это только когда новая схема подтверждена с реального рабочего места.

Если RDP-серверов несколько, помните: у каждого свой PortNumber. Отдельной административной настройки групповой политики для номера порта нет, это параметр реестра каждой машины, поэтому в домене его раскатывают через Group Policy Preferences (элемент реестра) или скриптом, а правило брандмауэра — отдельным параметром политики. В моей практике для офисов до 50 мест проще не плодить разные порты, а оставить 3389 внутри сети и закрыть его на границе. Разные номера на каждом сервере — это путаница в документации, которую через полгода никто не вспомнит. Подробно про включение RDP на разных версиях Windows у нас есть полное руководство по настройке RDP, здесь я сосредоточен именно на порте.

Что ломается после смены порта RDP

Смена порта — это три-четыре места, где легко ошибиться, и почти все «после смены не подключается» сводятся к одному из них. Я сложил их в порядке частоты. Первое — брандмауэр: правило не создано, создано только на TCP, или создано для профиля, которого у вас нет. Второе — роутер: на границе сети проброс всё ещё указывает на старый внутренний порт, и внешний запрос идёт в пустоту. Третье — клиент: человек по привычке вводит адрес без порта, а подключение молча уходит на 3389. Четвёртое — перезагрузка не прошла, и в реестре одно, а на сокете другое. Это удобно проверять тем самым Get-NetTCPConnection -State Listen.

Отдельный класс проблем — всё, что кроме mstsc ходит на 3389 по умолчанию: сканеры инвентаризации, мониторинг, скрипты резервного копирования, ярлыки .rdp, записанные годы назад. Все они продолжат стучаться на старый порт. Если у вас в Zabbix или другом мониторинге стоит проверка «порт 3389 открыт», после смены она покраснеет, и это правильная реакция: поправьте проверку, а не отключайте её. Ярлыки .rdp удобнее раздать заново, чем объяснять каждому пользователю про двоеточие.

Если у вас ферма на нескольких серверах терминалов, смена порта на отдельном узле ещё и требует согласованности с брокером и шлюзом: шлюз по документации ходит к внутренним ресурсам на TCP и UDP 3389, и если вы на сервере сменили номер, нужно соответственно поправить, куда шлюз подключается. Как правильно строить такую ферму, я разбирал в статье про настройку фермы RDP на Windows Server. А если подключение не падает совсем, а просто тормозит, то порт тут ни при чём, смотрите пошаговую диагностику тормозов RDP.

• Правило брандмауэра не создано или создано только для TCP, а клиент пробует и UDP.
• Правило привязано к профилю сети, которого на сервере нет (в примере Microsoft указан Public).
• На роутере проброс всё ещё ведёт на старый внутренний порт.
• Клиент вводит адрес без номера порта.
• Перезагрузки не было: проверьте Get-NetTCPConnection -LocalPort <порт> -State Listen.
• Мониторинг и ярлыки .rdp продолжают проверять старый порт 3389.

Защищает ли смена порта RDP и что поставить вместо этого

Честно: нет, не защищает. Смена порта убирает часть шума от автоматических сканеров, которые по умолчанию стучатся на 3389, и лог неудачных входов становится чище. Но это не барьер. Сканеры умеют проходить по всем портам, а служба RDP на нестандартном порту всё равно отвечает как RDP и ровно так же принимает перебор паролей. Microsoft в документации формулирует очень осторожно: порт можно менять «для безопасности или по конфигурации», и больше ничего не обещает. В старой документации по Windows Server 2008 R2 (описание события 1036) прямо сказано, что Microsoft не рекомендует менять порт, назначенный RDP. Я отношусь к смене порта как к гигиене: допустимо, если вы понимаете её пределы, и вредно, если она подменяет настоящую защиту.

Что действительно работает, в порядке приоритета. Первое: не выставлять RDP в интернет вообще. Это основная мысль нашей статьи про проброшенный наружу RDP-порт 3389, и я с ней полностью согласен. Второе: если доступ снаружи нужен, ставить его за VPN или за шлюз удалённых рабочих столов, где наружу смотрит только TCP 443, а UDP 3391 по желанию. Про шлюз у нас есть отдельная статья про безопасный доступ через RD Gateway. Третье: сузить правило брандмауэра по источнику, как в команде выше, через -RemoteAddress. Это дешёвый и надёжный слой, который в разы эффективнее любой смены номера.

Четвёртое — всё, что связано с учётными записями: блокировка после неудачных попыток, двухфакторная аутентификация, запрет входа по RDP для лишних пользователей, Network Level Authentication. Microsoft в разделе про включение удалённого рабочего стола отдельно рекомендует NLA: пользователь аутентифицируется до создания сеанса, и это снижает риск несанкционированного доступа. Отключать NLA имеет смысл только временно, для совсем старых клиентов. Пятое — журналирование и разбор подключений: как собирать и читать их, описано в нашей статье про аудит RDP-подключений. Без аудита вы не узнаете, что кто-то уже зашёл.

Если свести совет в одну строку: в офисе до 50 рабочих мест я оставляю 3389 как есть, закрываю его от интернета, сужаю по подсети и даю удалённым людям вход через VPN. Менять номер порта имеет смысл в двух случаях: когда на одном внешнем адресе нужно различать несколько серверов без шлюза (и тогда лучше всё же перейти на шлюз), и когда этого требует чужая политика или аудит. Во всех остальных случаях время лучше потратить на VPN и учётные записи.

Разбор: «Игольное ушко», 9 рабочих мест и проброшенный RDP

Условный клиент — магазин швейных принадлежностей «Игольное ушко», 9 рабочих мест: продавцы, склад, бухгалтерия, владелица. Один сервер на Windows Server 2022 с файловой базой учёта и общими папками, роутер на границе. Удалённо работали двое: бухгалтер из дома и владелица в поездках. Доступ был устроен так, как его годами делают в малом бизнесе: на роутере проброс внешнего порта на 3389 сервера, пароль «посложнее». Первичный запрос звучал как «сделайте нам нестандартный порт, нам сказали, что так безопаснее».

Мы согласились поменять порт, но не остановились на этом. Сначала сделали то, что описано выше: прочитали PortNumber, убедились, что порт слушается, создали правила на TCP и UDP для нового номера с ограничением по LocalSubnet, перезагрузили сервер вечером и проверили подключение с рабочего места через mstsc с указанием порта. На этом шаге мы поймали классическую ошибку: правило из примера создали по привычке с -Profile Public, а сетевой профиль сервера был другим, и подключение не проходило. Пересоздали правило без указания профиля. Весь этот этап занял около часа, и такой простой не страшен, потому что работали вне рабочего времени.

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

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