Сбой подключения к удаленному серверу


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

Невозможно подключиться к удаленному ПК

Проблема, о которой пойдет речь, возникает при попытке получить доступ к другому ПК или серверу с помощью встроенного в Windows RDP-клиента. Мы его знаем под именем «Подключение к удаленному рабочему столу».

Данная ошибка возникает по нескольким причинам. Далее мы подробнее поговорим о каждой и приведем способы решения.

Причина 1: Отключение удаленного управления

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

Локальные групповые политики

На обоих компьютерах также необходимо проверить, не отключен ли компонент RDP в настройках локальных групповых политик. Данная оснастка присутствует только в профессиональных, максимальных и корпоративных редакциях ОС Windows, а также в серверных версиях.

    Для доступа к оснастке вызываем строку «Выполнить» комбинацией клавиш Windows+R и прописываем команду


В разделе «Конфигурация компьютера» открываем ветку с административными шаблонами, а затем «Компоненты Windows».


Далее по очереди раскрываем папки «Службы удаленных рабочих столов», «Узел сеансов удаленных рабочих столов» и кликаем по подпапке с настройками подключений.


В правой части окна дважды кликаем по пункту, разрешающему удаленное подключение с использованием служб удаленных рабочих столов.


Если параметр имеет значение «Не задано» или «Включить», то ничего не предпринимаем, в противном случае ставим переключатель в нужное положение и жмем «Применить».

  • Перезагружаем машину и пробуем получить удаленный доступ.
  • Причина 2: Отсутствие пароля

    Если на целевом компьютере, а точнее, на учетной записи того пользователя, по которым мы входим в удаленную систему, не установлена защита по паролю, то подключение выполнить не удастся. Для того чтобы исправить ситуацию, необходимо создать пароль.

    Причина 3: Спящий режим

    Спящий режим, включенный на удаленном ПК, может воспрепятствовать нормальному соединению. Решение здесь простое: необходимо отключить данный режим.

    Подробнее: Как отключить спящий режим на Windows 10, Windows 8, Windows 7

    Причина 4: Антивирус

    Еще одной причиной невозможности подключения может стать антивирусное программное обеспечение и входящий в его состав брандмауэр (файервол). Если такой софт установлен на целевом ПК, то его необходимо временно отключить.

    Читайте также  Почему человек при разговоре закатывает глаза

    Причина 5: Обновление безопасности

    Данное обновление под номером KB2992611 призвано закрыть одну из уязвимостей Windows, связанную с шифрованием. Варианта исправления ситуации два:

    • Полное обновление системы.
    • Удаление этого апдейта.

    Причина 6: Сторонние программы для шифрования

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

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

    Альтернативное решение: Программы для удаленного подключения

    Если инструкции, приведенные выше, не помогли решить проблему, то обратите внимание на сторонние программы для удаленного управления компьютерами, например, TeamViewer. Его бесплатная версия обладает достаточным функционалом для полноценной работы.

    Заключение

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

    Отблагодарите автора, поделитесь статьей в социальных сетях.

    При настройке WinRM на серверах в домене Active Directory столкнулся со странной проблемой. После того как служба WinRM была настроена и включена на сервере, к ней разрешено удалённое подключение через Windows PowerShell Remoting, при попытке удаленного подключения к данному серверу с помощью команды Enter-PSSession msk-dp01 в консоли PowerShell появляется следующая ошибка WinRM:

    + CategoryInfo : InvalidArgument: (msk-dp01:String) [Enter-PSSession], PSRemotingTransportException

    В английской версии Windows ошибка выглядит так:

    Enter-PSSession : Connecting to remote server msk-dp01 failed with the following error message : The WinRM client received an HTTP bad request status (400), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic.

    + CategoryInfo : InvalidArgument: (msk-dp01:String) [Enter-PSSession], PSRemotingTransportException

    При этом на сервере порты WinRm (5985/HTTP, 5986/HTTPS) отвечают и принимают соединения. Проверить доступность TCP портов WinRM можно с помощью утилиты PortQryV2 или командлета PowerShell Test-NetConnection:

    TNC msk-dp01 –port 5985

    Как оказалось, проблема оказалась связана с большим размером токена Kerberos у пользователя, за счет того, что пользователь состоит в слишком большом количестве доменных групп. Ошибка возникает при превышении размера токена 16 Кб (см статью MaxTokenSize — размер токена Kerberos). В нашей ситуации происходит все тоже самое, сервер WinRm сбрасывает запрос от клиента, т.к. размер заголовка пакета аутентификации превышает 16 Кб. В статье по ссылке мы упоминали, что по-умолчанию в IIS используется размер HTTP заголовка не более 16 Кб, и в случае проблем с HTTP аутентификацией из за большого токена пользователя, его нужно увеличить до 64 Кб

    Читайте также  Ремонт канди трио посудомойка

    Чтобы исправить проблему, нужно уменьшить размер токена (уменьшить количество групп безопасности, в которых состоит пользователь), а если это невозможно, тогда в редакторе реестра на сервере нужно изменить значение следующих DWORD параметров реестра в ветке HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesHTTPParameters

    • MaxFieldLength увеличить до 0000ffff (65535)
    • MaxRequestBytes увеличить до 0000ffff (65535)

    Осталось перезагрузить сервер и проверить подключение WinRm через Enter-PSSession с клиента.

    Удаленный пользователь не может подключиться к RDS ферме

    Удаленный пользователь не может подключиться к RDS ферме

    Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов России Pyatilistnik.org. В прошлый раз мы с вами успешно научились решать ошибку "pfn list corrupt" в операционной системе Windows 10. Движемся дальше, в данной публикации я бы хотел с вами поделиться небольшим опытом поиска проблемы с подключением по RDP. В данной публикации мы рассмотрим вопрос, почему удаленный пользователь не может подключиться к RDS ферме Windows Server 2012 R2.

    Описание проблемы

    И так, есть RDS ферма построенная на базе Windows Server 2012 R2, состоящая из 15 хостов. В нее было добавлено еще 5 RDSH хостов. В компании люди работают с терминальным столом, как локально, так и удаленно, посредством подключения через VPN в корпоративную сеть и дальше уже к ферме. Вот как раз у таких VPN пользователей и стали возникать непонятные ситуации. При попытке подключения по RDP у них появлялась ошибка:

    1. Не включен удаленный рабочий стол
    2. Удаленный компьютер выключен
    3. Удаленный компьютер не подключен к сети

    Удостоверьтесь, что удаленный компьютер включен, подключен к сети и удаленный доступ к нему включен

    Решение проблемы

    Ошибка вроде очевидная, что не включен RDP доступ, если бы это был рядовой сервер я бы понял, но тут служба удаленного доступа точно работала и была включена, так как на данный сервер так же распространялась групповая политика делающая, это автоматически, я проверил применение GPO, все было хорошо. Первым делом я полез смотреть логи Windows, это можно сделать классическим методом или через модный Windows Admin Center.

    Журналы которые нас будут интересовать находятся в таких расположениях:

    • Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
    • Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
    • Microsoft-Windows-TerminalServices-SessionBroker/Admin
    • Microsoft-Windows-TerminalServices-SessionBroker/Operational
    • Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational

    Строим алгоритм обычного пользователя работающего удаленно. Сотрудник подключается к VPN серверу, после успешного подключения, он запускает клиента удаленного рабочего стола и производит подключение к RDS ферме. Далее сотрудник проходит успешно аутентификацию, его логин и пароль принимается брокерами RDS, далее идет процесс подключения, который заканчивается представленной выше ошибкой.

    Первое, что мне бросилось в глаза, это предупреждение с кодом ID 101:

    Далее было такое предупреждение:

    Далее нужно посмотреть, как RDCB брокеры взаимодействовали с сессией пользователя. В журнале "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" я обнаружил событие с кодом ID 1149, в котором я вижу, что определенный пользователь был успешно аутентифицирован на RDS ферме, он получил некий IP адрес.

    Читайте также  Проигрыватель с поддержкой mkv

    Далее я стал изучать информацию из журнала "Microsoft-Windows-TerminalServices-SessionBroker/Operational". Тут я так же обнаружил, что брокер успешно ответил и отправил пользователя на определенный RDSH хост. Тут есть событие с кодом ID 787.

    За ним я видел событие с кодом ID 801, которое имело вот такое сообщение:

    тут видно, что брокер даже смог обнаружить предыдущую сессию на данном терминале, о чем говорит строка Disconnected Session Found = 0x0

    И вы увидите событие с кодом ID 800:

    тут видно, что определенный брокер успешно направил пользователя на определенную коллекцию.

    Далее переходим в журнал "Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational" тут будет два события,об успешном общении RDS брокера и клиента.

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

    Что стоит проверить

    Первым делом проверьте не пытается ли по какой-то причине ваш RDSH брокер, направить пользователя на хост находящийся в режиме стока (Drain Mode). По идее туда могут попадать, только те пользователи, у кого там была сессия, так как режим стока обрубает новые. Если такая старая сессия есть, то попробуйте ее завершить, это можно сделать из консоли управления RDS фермой, или же специализированными утилитами rwinsta и ее аналогами.

    После завершения сессии дайте минут 5, чтобы брокеры забыли, что пользователь был на данном терминале. Пробуем войти на RDS ферму. Если ситуация обратная, брокер по логам перенаправляет на известный вам терминальный сервер, но пользователь все так же видит ошибку "Удаленному рабочему столу не удалось подключиться к удаленному компьютеру по одной из следующих причин", то попробуйте перевести данный хост в режим стока и повторить попытку. Еще в настройках терминальной фермы проверьте нет ли явных ограничений по приоритетам балансировки нагрузки, убедитесь, что хватает сеансов.

    Далее если у вас есть оборудование фильтрующее трафик и ограничивающее порты при подключении к VPN, убедитесь, что они пропускают порт 3389. У меня как раз не хватало в правиле новой подсети. Проверить доступность порта можно через утилиту Telnet. Как выяснилось, все было банально просто. В результате чего у меня исчезла ошибка "Удаленному рабочему столу не удалось подключиться к удаленному компьютеру по одной из следующих причин". У вас не должно быть ошибок в виде "Не удалось открыть подключение к этому узлу, на порт 3389: Сбой подключения".

    Также в командной строке проверьте, что у вас правильно разрешаются имена, для этого есть команда nslookup, особенно актуально, кто балансирует подключения к брокеру по DNS, а не NLB. Если на RDSH сервере установлен антивирус, то так же посмотрите его монитор сетевой активности и логи, может быть он блокирует определенный вид трафика.

    Ссылка на основную публикацию
    Adblock
    detector