В практике системного администрирования часто возникают ситуации, когда удаленный доступ к серверу по протоколу RDP стабильно работает практически со всех узлов, но на одном конкретном рабочем месте или в отдельном офисе пользователи сталкиваются со странным поведением. При попытке авторизации система выдает ошибку «Неверный логин или пароль», хотя учетные данные гарантированно вводятся правильно. Более того, внешний вид окна авторизации на «проблемном» компьютере может существенно отличаться от стандартного.
В рамках этой статьи мы подробно разберем, почему возникает подобная сетевая коллизия, проанализируем внутренние механизмы авторизации операционных систем Windows на уровне RDP, а также рассмотрим пошаговые методы диагностики и исправления этой ошибки.
Рассмотрим ситуацию, когда целевым сервером является классический терминальный сервер на базе Windows Server 2003 (совмещающий роль контроллера домена), к которому осуществляется подключение по нестандартному RDP-порту. При подключении с большинства внешних компьютеров отображается старое классическое окно авторизации (с полями для ввода логина, пароля и явным выбором домена). Однако на проблемном рабочем месте при подключении появляется современное плиточное окно авторизации (с иконками пользователей и кнопкой «Другой пользователь»), характерное для более современных операционных систем, например Windows Server 2008 или Windows 7.
Давайте выясним причину такого визуального различия. Все дело в эволюции механизмов безопасности операционных систем Microsoft:
Windows Server 2003 и Windows XP по умолчанию. При таком сценарии RDP-клиент сначала полностью устанавливает графическую сессию с сервером, и только затем сервер внутри этой сессии отрисовывает свое собственное диалоговое окно для ввода учетных данных.Windows Server 2008 и Windows Vista, по умолчанию применяется аутентификация на уровне сети — NLA (Network Level Authentication). При включенной NLA клиент собирает учетные данные пользователя еще до создания полноценной терминальной сессии, используя локальный красивый интерфейс (плитки пользователей), шифрует их и передает серверу для предварительной проверки.Если при попытке подключения к серверу Windows Server 2003 вы внезапно видите современное плиточное окно авторизации NLA, это первый и самый надежный признак того, что ваш RDP-клиент фактически подключается не к целевому серверу 2003, а к какому-то другому, более новому серверу. Соответственно, попытка авторизоваться под учетной записью вашего удаленного домена (например, DOMEN\VASYA) на чужом сервере закономерно вызывает ошибку аутентификации.
Давайте проанализируем, каким образом сетевой трафик RDP-клиента перенаправляется на совершенно другой сервер. Источником проблемы здесь выступает некорректно настроенный роутер (шлюз) в той локальной сети, откуда совершается подключение.
Представим, что администратор локальной сети в проблемной точке опубликовал в интернет свой собственный внутренний сервер (например, на базе Windows Server 2008). Для этого на роутере было создано правило проброса портов (Port Forwarding / Destination NAT). По роковой случайности администратор этой сети использовал тот же самый нестандартный внешний порт для RDP, который вы выделили для своего удаленного сервера Windows Server 2003.
Основная техническая ошибка администратора при создании этого NAT-правила заключается в избыточной широте его действия. В настройках роутера (будь то MikroTik, Cisco, pfSense или маршрутизатор на базе iptables) при создании правила трансляции адресов типа dst-nat обязательно нужно четко ограничивать область его применения. Необходимо указывать либо входящий интерфейс (in-interface=WAN), либо конкретный внешний IP-адрес назначения (dst-address=внешний_IP).
Если эти параметры не заданы, правило трансляции начинает работать глобально по принципу:
«Любой TCP-пакет, проходящий через роутер и имеющий порт назначения XXXXX, должен быть перенаправлен на локальный IP-адрес внутреннего сервера 192.168.x.x».
Когда вы с рабочего места пытаетесь инициировать RDP-сессию наружу к вашему серверу, исходящий пакет доходит до локального роутера. Роутер видит совпадение по порту назначения, перехватывает его еще на этапе маршрутизации (в цепочке PREROUTING) и заворачивает обратно внутрь локальной сети на свой сервер. В итоге вы видите окно авторизации чужого сервера, который ничего не знает о ваших учетных данных.
Рассмотрим, как можно быстро выявить данную неисправность с помощью стандартных и специализированных инструментов системного администратора.
При первом подключении к новому узлу RDP-клиент всегда выводит предупреждение безопасности, запрашивая подтверждение доверия к SSL/TLS-сертификату узла. Если вы столкнулись с проблемой авторизации, обязательно нажмите кнопку «Показать сертификат» (View Certificate) на предупреждающем баннере. Проанализируйте поле «Кому выдан» (Issued to). Если там указано имя локального сервера текущей организации, а не вашего удаленного контроллера домена, значит, трафик перехвачен локальным шлюзом.
Стандартная утилита tracert в операционных системах Windows использует протокол ICMP, который проходит через роутер без изменений и показывает корректный маршрут до внешнего IP-адреса. Для выявления коллизии портов нам необходимо выполнить трассировку именно по конкретному TCP-порту RDP. Для этого мы рекомендуем воспользоваться бесплатными консольными утилитами, такими как tcpping или paping.
Запустите тест из командной строки, указав ваш внешний IP и нестандартный порт подключения:
paping.exe -p 53389 -c 4 удаленный_внешний_ip
Если коллизия имеет место, утилита покажет время отклика менее 1-2 миллисекунд (так как ответ идет от локального сервера в LAN-сети), в то время как реальный пинг до внешнего сервера через интернет должен составлять десятки миллисекунд.
Проанализируем доступность порта с помощью встроенного инструментария PowerShell. Для этого выполним командлет Test-NetConnection, который позволяет протестировать конкретный порт назначения:
Test-NetConnection -ComputerName "удаленный_внешний_ip" -Port 53389
Данная команда вернет детальную информацию о подключении. Обратите внимание на время отклика интерфейса и маршрут следования пакетов.
Рассмотрим два основных сценария решения этой технической проблемы: оперативное исправление коллизии на уровне роутера и кардинальное повышение безопасности сетевой инфраструктуры.
Если у вас есть доступ к управлению роутером в проблемной локации, необходимо строго ограничить область действия правила проброса портов. На примере маршрутизатора под управлением MikroTik RouterOS правильная настройка выглядит следующим образом:
/ip firewall nat
add chain=dstnat action=dst-nat to-addresses=192.168.1.100 to-ports=3389 protocol=tcp dst-port=53389 in-interface=ether1-wan
Обратите внимание на обязательное указание параметра in-interface=ether1-wan (или вашего актуального внешнего интерфейса). Это гарантирует, что правило будет срабатывать исключительно на запросы, поступающие из глобальной сети Интернет, и полностью исключит перехват исходящего трафика ваших локальных пользователей.
Публикация RDP-портов (даже нестандартных) напрямую в сеть Интернет сопряжена с критическими рисками безопасности. Такие порты непрерывно сканируются специализированными ботами, что приводит к постоянным попыткам подбора паролей (Brute-Force) и создает угрозу эксплуатации уязвимостей операционной системы.
Наиболее надежным и архитектурно правильным решением является полный отказ от проброса портов RDP наружу. Вместо этого мы рекомендуем развернуть защищенный VPN-туннель между клиентом (или его локальным роутером) и сетью вашего сервера. Для этих целей можно использовать современные протоколы:
После успешного подключения к VPN-серверу пользователи смогут запускать RDP-клиент, используя классический внутренний IP-адрес сервера (например, 192.168.10.10) и стандартный порт 3389. Это полностью и навсегда исключит любые коллизии портов на внешних шлюзах и обеспечит максимальную защиту ваших корпоративных данных.