Меня попросили взглянуть на сервер Win2k3 друзей членов семьи - удаленный рабочий стол больше не работал, и они пытались понять, почему. На этом сервере работает Win2k3 SP2.
Я определил, что у служб лицензирования были проблемы (идентификатор события 19, см. http://support.microsoft.com/kb/2021885 для подробностей) - это было исправлено путем установки исправления (http://support.microsoft.com/kb/983385) и повторная активация лицензий, чтобы ошибка больше не появлялась. Однако RDP-подключения из Интернета по-прежнему не работают.
Подключенное сетевое оборудование представляет собой модем DSL к устройству SonicWALL TZ170, который подключен к коммутатору с 24 портами, который обеспечивает проводной доступ к одному ПК и 10 или 11 тонким клиентам (Neoware).
Просто чтобы просмотреть то, на что смотрели:
1. Порт 3389 прослушивает сервер (netstat -a -o показывает, что ms-wbt-server прослушивает 3389)
2. Portqry (из удаленной системы Win7) показывает, что 3389 TCP прослушивает, но 3389 UDP прослушивает или фильтрует (UDP определяет только звук, не так ли?)
3. Я могу подключиться к системе по telnet с удаленной системы Win7 на имя хоста / IP-адрес порта 3389 и нормально подключиться.
4. RDP работает локально (т. Е. Подключите портативный компьютер к локальной сети, mstsc отлично подключается к серверу с портативным компьютером, имеющим внутренний адрес 192.168.0.x)
5. Сканирование портов с помощью nmap в удаленной системе показывает, что 3389 открыт.
6. Я не заметил антивируса в системе Win2k3 (не уверен, работает ли он на устройстве SonicWALL, хотя я не могу это проверить, поскольку они забыли пароль администратора, и мне бы очень хотелось избежать сброса настроек до заводских на Это). Локальный брандмауэр Windows на сервере Win2k3 не включен.
При подключении к серверу удаленно появляется это сообщение:
This computer can't connect to the remote computer.
Try connecting again. If the problem continues, contact the owner of the remote
computer or your network administrator.
Тем не менее, сервер Win2k3 хорошо поддерживает исправления / патчи из Центра обновления Windows, но почему это могло вызвать проблемы, когда он работал до того, как проблема с лицензией была вне меня ... поскольку в системе никогда не было полной резервной копии (только резервные копии пользовательские данные) перед запуском хотфикса я сделал образ дисков (на всякий случай).
Какие-либо предложения? Я сделал все, что мог придумать, что касается лицензирования, портов и т. Д. Поскольку он работает локально, но не через Интернет, единственное, о чем я мог думать, это то, что Sonicwall что-то делал (хотя переадресация портов, похоже, работает нормально на внутренний IP-адрес сервера win2k3, так как он может видеть службу как прослушивающую).
Просто в конце моей веревки (и терпения).
Спасибо.
Редактировать:
На данный момент я больше не нахожусь на удаленном сайте, поэтому я не могу проверить w / Wireshark - однако удаленная проверка w / Wireshark показывает, что сервер действительно отвечает (SYN / ACK выполнен), но соединение просто не кажется подойти.
Как видите, я не очень хорошо разбираюсь в Win2k3; Я в основном работаю с UNIX. / ухмылка
Порт 443 также открыт в SonicWALL, поэтому мне интересно, используется ли шлюз TS.
Изменение настроек RDP для использования шлюза удаленных рабочих столов (RD / TS, что угодно!) Вызывает у меня ошибку сертификата от Sonicwall - экспорт этого сертификата и импорт его в корневые сертификаты работают, но при попытке повторного подключения указано имя (например, CN ) не совпадает - что имеет смысл, поскольку полное доменное имя, к которому я подключаюсь, не соответствует имени сертификата (сертификат, который я получил от Sonicwall, показывает внутренний IP-адрес Sonicwall 192.168.0.1, но не полное имя) .
Правильно! Еще больше запутались. / ухмылка
Обнаружил проблему:
Хотя 'netstat -a' действительно показывает прослушивание служб терминалов, он показывает это по имени, а не по порту (т. Е. Показывает ms-wbt-server, а не порт 3389). Я вернулся после использования Wireshark / etc. для проверки информации, поступающей на сервер, передаваемой по сети (что и было - я бы оценил два предложения выше, но у меня пока нет представителя для этого!).
Оказывается, кто-то настроил RDP на сервере для работы на нестандартном порту.
Ключ реестра, который содержит это:
HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ Terminal Server \ WinStations \ RDP-Tcp
Я изменил его на 3389 (десятичный), сохранил его и перезагрузил сервер.
После этого Терминальные службы работали.
Обратите внимание, что мое предыдущее рассмотрение порта 443 / TS Gateway не было применимо, поскольку TS Gateways / 443 используется только для Windows Server 2008 (согласно MS Technet).
Вы можете использовать NetMon или Wireshark на сервере Windows 2003, чтобы убедиться, что удаленное системное соединение действительно подключается к серверу на 3389.
«Я могу подключиться к системе по telnet с удаленной системы Win7, используя имя хоста / IP-адрес порта 3389, и подключиться нормально»
Сравните баннеры telnet-соединения между фразами «через Интернет» и «локально в сети», чтобы увидеть, совпадают ли они.