Ошибка невозможно подключиться к серверу rdp

  • Печать

Страницы: 1 [2] 3  Все   Вниз

Тема: remmina ошибка «Невозможно подключиться к серверу RDP» при подключении к windows  (Прочитано 55084 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн
Leo_87

1) грохнуть ~/.freerdp
2) проверить под другим пользователем

Грохнул.
Под другим пользователем заходит, а как под тем который нужен зайти?

Оффлайн
ArcFi

Leo_87, удаление ~/.freerdp помогло?

Оффлайн
Leo_87

Leo_87, удаление ~/.freerdp помогло?

Помогло на одной машине.
На других удалил, под другим пользователем пускает. Но под тем который нужен не хочет.
Что ещё можно посмотреть?

Оффлайн
ArcFi

Leo_87, там, где не работает, показывайте:

cat /etc/issue
nmap -Pn -sV -p PORT IPPORT — RDP-порт, обычно 3389
IP — адрес RDP-сервера

Оффлайн
Leo_87

Leo_87, там, где не работает, показывайте:

Starting Nmap 5.21 ( http://nmap.org ) at 2013-07-18 11:13 MSK
Nmap scan report for 192.168.0.9
Host is up (0.00066s latency).
PORT     STATE SERVICE       VERSION
3389/tcp open  ms-term-serv?

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 99.19 seconds

Оффлайн
Leo_87

Проблему решил.
Помимо папки ~/.freerdp , нужно удалить все файлы из папки ~/.remmina
Спасибо за помощь.

Оффлайн
ArcFi

В ~/.remmina лежит конфиг и настройки всех подключений, с этим надо аккуратнее, а то можно наудалять лишнего.

Оффлайн
sergicus

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP

Оффлайн
Ods

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP

Огромная благодарность автору поста! Несколько дней была лишена доступа к работе, куча нервов и времени, нигде и ничего толкового, все удаляла, чистила, грузила заново — эффекта 0 и только ваша подсказка за секунду решила все проблемы!!! Спасибо форуму и автору sergicus!

Оффлайн
vadimvolodin

как то давно ремина начала глючить, не когда было разбираться поставил KRDC и забыл про ремину.

Оффлайн
Storke

у меня была похожая проблема.
Решил — помогло — в настройках профиля подключения -> дополнительные -> безопасность , в этом пункте установить вместо автосогласования RDP

Благодарю за помощь! Тоже мучился полдня. Remmina без проблем подключалась из Ubuntu 14.04 к Windows Server 2008 R2 в роли сервера терминалов. Как только создал домен, убрав сервер терминалов, возникла та же байда. После выбора вместо Согласование RDP снова смог подключиться.

Оффлайн
serp53

Всё опробовал что указано выше в топике и не помогло.
Предыстория. У меня раньше терминальный сервер (Windows server 2008 R2) был не в домене и всё работало, по производственной необходимости пришлось терминальный сервер подключить к домену. После подключения «Remmina» отказалась подключаться к терминальному серверу (Windows server 2008 R2).
В моём случае, после того как поставил галочку «Прикрепить к консоли (windows 2003 / 2003 R2)» «Remmina» стала подключаться.

Оффлайн
kac

Кстати очень много проблем решает remmina ppa. Каждую неделю есть обновления.много проблем решилось.

Оффлайн
jenkidu

Была точно такая же проблема. На сервер с винды по RDP зайти могу, с Ubuntu 14.04 не могу (невозможно подключиться к серверу RDP).
Удаление папки .freerdp помогло.
Заново выдался сертификат, все заработало.

Оффлайн
guertauli

Заново выдался сертификат, все заработало.

Что-бы сертификат не прописывался никогда:
1. Удалить все содержимое внутри папки .freerdp
2. chmod u-w .freerdp

« Последнее редактирование: 08 Марта 2016, 18:59:34 от guertauli »

  • Печать

Страницы: 1 [2] 3  Все   Вверх

Источник

  • Главная

  • Инструкции

  • Windows

  • Не подключается RDP клиент: возможные проблемы и исправление ошибок

Подключение к удаленному рабочему столу с помощью протокола RDP является распространенной задачей. Пользователи могут в дистанционном формате выполнять свои рабочие задачи на корпоративном компьютере и в корпоративной сети. Особенно это актуально в случаях, когда для работы требуется большой объем вычислительных ресурсов, которые могут быть недоступны на домашнем ПК. 

В этой статье мы рассмотрим несколько типовых проблем с RDP и пути их решения.

Две типовые проблемы при подключении

Первая стандартная ошибка при подключении выглядит следующим образом:

Image4

Перед возникновением такой ошибки обычно пользователь видит сообщение «Инициализация удаленного подключения», после которого компьютер выдаёт ошибку.

Вторая типовая ошибка — это ошибка «Удаленному рабочему столу не удалось подключиться к удаленному компьютеру». 

Image2

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

Вот какие причины могут привести к проблемам с подключением по RDP:

  • неправильные настройки подключения;
  • проблема соответствия доменного имени и IP-адреса удаленного компьютера;
  • кэш DNS-сервера;
  • кэш RDP;
  • использование порта RDP другим приложением;
  • брандмауэр блокирует подключение;
  • обновление Windows.

Давайте рассмотрим эти причины и пути их устранения.

Проверьте настройки подключения

Одна из причин, по которой может возникнуть проблема с подключением по RDP — неправильные настройки самого подключения. Ниже перечислены несколько настроек, которые могут повлиять на возможность подключения по RDP:

Неправильные учетные данные

Если вы вводите неправильные данные для авторизации на удаленном компьютере, подключение по RDP будет невозможно. Убедитесь, что вы вводите правильные учетные данные, и что они имеют достаточные права для подключения.

Неправильный адрес удаленного компьютера

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

  1. Откройте «Проводник» на удаленном компьютере и перейдите на вкладку «Этот компьютер».
  2. Кликните правой кнопкой мыши в рабочей зоне и нажмите «Свойства».
  3. После этого откроется страница «Система». В разделе «Имя компьютера, имя домена и параметры рабочей группы» вы найдете нужные данные для подключения.

Если проблема не решена, переходите к следующему разделу.

Подключение к удаленному компьютеру по IP-адресу

В качестве адреса при подключении к удаленному компьютеру обычно указывается его доменное имя. Доменное имя — это символьный адрес сервера. Ему сопоставляется определенный IP-адрес. Доменные имена нужны для удобства пользователей, чтобы им не приходилось каждый раз при посещении google.com вбивать в браузерную строку адрес ближайшего сервера Google. Доменные имена и соответствующие им IP-адреса хранятся на DNS-сервере. Иногда доменному имени в DNS-сервере присваивается неправильный адрес — в таком случае пользователь не сможет подключиться к серверу по домену. Чтобы исключить или, наоборот, исправить эту проблему, давайте попробуем подключиться к удаленному компьютеру по IP-адресу.

Чтобы узнать IP-адрес удаленного компьютера, откройте на нём командную строку: нажмите Win+R и введите в окне cmd. В командной строке выполните команду ipconfig. Так вы узнаете IP-адрес компьютера:

Image1

Теперь при подключении к удаленному компьютеру через RDP используйте IP, а не доменное имя.

Попробуйте очистить кэш DNS

Иногда помогает очистка кэша DNS. Для этого откройте командную строку и выполните в ней команду ipconfig / flushdns:

Image3

Добавьте IP-адрес RDP-сервера в файл hosts

Файл hosts в Windows — это текстовый файл, который содержит ассоциации доменных имен с IP-адресами. Этот файл используется компьютером как первичный источник информации об именах хостов для компьютера, перед тем, как он обращается к DNS-серверу за информацией. Чтобы исправить ошибку в DNS-сервере, вы можете добавить в hosts запись с доменным именем и IP-адресом удаленного компьютера.

Для этого откройте файл hosts с помощью Блокнота. Файл находится в каталоге C:\Windows\System32\drivers\etc\. Добавьте в него новую строку с IP-адресом удаленного компьютера и его доменным именем и сохраните изменения.

По умолчанию для подключения по RDP используется порт 3389. Если какое-то другое приложение на компьютере использует такой же порт, то при подключении возникнет ошибка. Давайте попробуем изменить порт на 3388 и проверим, получится ли подключиться по RDP с другим портом. Для этого:

  1. Откройте редактор реестра и перейдите в каталог RDP-Tcp.
  2. Найдите запись PortNumber.
  3. Нажмите ПКМ на неё и выберите «Изменить».
  4. Введите любой другой номер порта в поле данных значения. 

Попробуйте воспользоваться альтернативным клиентом RDP

Если у вас не получилось устранить проблему с подключением по RDP через клиент от Microsoft, то вы можете воспользоваться аналогами. Например, AnyDesk или Remote Utilities.

Откатите или установите обновления Windows

Во многих случаях функциональность удаленного рабочего стола (RDP) может быть нарушена после обновления Windows, поскольку один из вновь установленных файлов может нарушить работу RDP. Также существует проблема с шифрованием CredSSP, которая лечится установкой обновления.

Таким образом, если ваша операционная система недавно обновлялась, попробуйте осуществить откат.

Измените настройки брандмауэра

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

Чтобы настроить брандмауэр:

  1. Откройте Брандмауэр Защитника Windows и нажмите в левом меню «Разрешение взаимодействия с приложением или компонентом в брандмауэре Защитника Windows».
  2. Нажмите «Изменить параметры».
  3. В перечне программ найдите «Удаленный рабочий стол» и установите напротив него флажки «Частная» и «Публичная».

Закройте окно и попробуйте подключиться. Если проблема была в брандмауэре, теперь вы сможете подключиться к удаленному компьютеру.

Заключение

В этом материале мы рассмотрели две типовые проблемы при подключении к удаленному рабочему столу по RDP. RDP-протокол позволяет организовать удаленное взаимодействие с рабочими станциями. От пользователя потребуется обеспечить лишь стабильное подключение.

Источник

Ubuntu 3

Remmina is a highly popular Remote Desktop Client written in GTK+, aiming to be useful for system administrators and travelers who need to work with lots of remote computers. However, users may occasionally encounter the error message “Cannot connect to RDP server localhost.” This article will guide you through several methods to resolve this issue.

  1. Change the Security Protocol
  2. Delete the known_hosts File
  3. Recreate the Connection
  4. Check Network Security
  5. Verify Certificate Verification
  6. Check Permissions
  7. Switch Security Protocol Negotiation
  8. Use SSH Tunneling

Change the Security Protocol

One of the first steps you can take is to change the security protocol in Remmina’s connection properties.

  1. Open Remmina and navigate to the connection properties.
  2. Go to the “Advanced” tab.
  3. Change the security protocol from “Negotiate” to “TLS” or “RDP.”

The security protocol is responsible for establishing a secure connection between your client and the server. By changing it, you may resolve any issues causing the error.

Delete the known_hosts File

If the keys on the tunnel server have changed, you may encounter connection issues. To resolve this, you can delete the known_hosts file. The file location may vary depending on your setup.

To delete the file, open your terminal and input the following command:

rm ~/.freerdp/known_hosts

or

rm ~/.config/freerdp/known_hosts

The rm command is used to remove files or directories in Linux. The ~ symbol represents your home directory, and the .freerdp/known_hosts is the path to the file you want to delete.

Recreate the Connection

If you’ve copied your Remmina configuration from one machine to another, it may cause compatibility issues. In this case, deleting and recreating the connection can resolve the problem.

Check Network Security

Ensure that you are connected to a secure Wi-Fi network. Connecting through an open, unencrypted network may cause connection problems. Switching to a secure network can help resolve the issue.

Verify Certificate Verification

In Remmina’s connection properties, go to the “Advanced” tab and check the “Ignore certificate” option. This can help if there are certificate verification issues. However, be cautious as disabling certificate verification can expose you to potential security risks.

Check Permissions

If you are using the snap version of Remmina and encounter permission denied errors, it may indicate a permissions issue. Uninstalling and reinstalling Remmina from the snap store or installing it from the repository can help resolve the problem.

Switch Security Protocol Negotiation

In Remmina’s connection properties, go to the “Advanced” tab and change the “Security protocol negotiation” from “TLS protocol security” to “RDP protocol security.” This solution has worked for some users.

Use SSH Tunneling

If all else fails, you can try establishing an SSH tunnel manually using the command:

ssh -L 2000:<ip of windows machine>:3389 bastion

And configure Remmina to connect to localhost:2000 using RDP. The -L option specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

Remember, it’s important to carefully follow the instructions and consider the security implications of the solutions provided. With these steps, you should be able to resolve the “Cannot connect to RDP server localhost” error in Remmina.

Remmina is a Remote Desktop Client written in GTK+ that allows users to connect and work with remote computers.

To change the security protocol in Remmina, open the connection properties, go to the «Advanced» tab, and select the desired security protocol from the dropdown menu.

The location of the known_hosts file may vary depending on your setup. In most cases, it can be found in either ~/.freerdp/known_hosts or ~/.config/freerdp/known_hosts.

To delete the known_hosts file, open your terminal and use the rm command followed by the path to the file. For example, rm ~/.freerdp/known_hosts or rm ~/.config/freerdp/known_hosts.

If you experience compatibility issues after copying your Remmina configuration, it is recommended to delete and recreate the connection on the new machine to resolve any problems.

Open, unencrypted Wi-Fi networks are less secure and can pose potential risks. It is advised to connect to a secure Wi-Fi network to avoid connection problems.

In Remmina’s connection properties, go to the «Advanced» tab and check or uncheck the «Ignore certificate» option to enable or disable certificate verification.

Permission denied errors in the snap version of Remmina may indicate a permissions issue. Try uninstalling and reinstalling Remmina from the snap store or installing it from the repository to resolve the problem.

Источник

До прошлой ночи у меня была Реммина, работающая нормально. Я мог запустить RDP через туннель SSH, и все было хорошо.

Тогда это перестало работать. Я могу добраться до диалогового окна пароля для моей рабочей машины, но тогда он просто говорит Cannot connect to RDP server localhost,

Я даже не могу найти журналы, которые выглядят интересно. Я восстановил Remmina, очистил мой .remmina каталог, перезапустил мою машину и даже перезапустил мой шлюз.

Просто чтобы сделать это действительно странным, мой ноутбук (который имеет ту же настройку — последние версии Ubuntu и Remmina) может установить соединение просто отлично. Он даже проходит через тот же маршрутизатор, хотя и по беспроводной сети.

Какие-нибудь мысли?

2012-09-26 20:29

18
ответов

Решение

Я понятия не имею, почему это работает, но я начал менять настройки по одному. Когда я отредактировал свойства соединения, я посмотрел на вкладку «Дополнительно» и изменил безопасность с «согласовать» на «TLS», и вуаля, все работает.

Как ни странно, «вести переговоры» по-прежнему работает на ноутбуке, но, по крайней мере, я вернулся к бизнесу с моим большим монитором:)

2012-09-26 22:15

Это случилось со мной, и я нашел ответ, который решил проблему. Просто rm ~/.freerdp/known_hosts и попробуй еще раз.

Очевидно, это происходит, когда меняются ключи на туннельном сервере. Смотрите эту ошибку.

ОБНОВИТЬ

Первая ссылка теперь указывает на удаленный ответ, поэтому вот дополнительная информация по этой ссылке:

  • Кажется, что файл «known_hosts» содержит некоторые данные маршрутизации для каждого сервера, эти данные иногда устаревают, а когда Remmina пытается подключиться с использованием устаревших данных, происходит сбой. Удаление файла known_hosts решает эту проблему. — Эрель Сегал-Халеви 13 декабря 12:06

  • FWIW, моя проблема не имела никакого отношения к known_hosts (как объяснено ниже), но все, что связано с настройками безопасности: см. http://www.bauer-power.net/2013/10/unable-to-connect-to-rdp-server-in.html для деталей. — Томислав Накич-Альфиревич 24 апреля ’14 в 10:58

  • Полностью сработало, мне было интересно, где хранятся сертификаты. У меня была та же проблема по большей части: я использовал Remmina для RDP на определенную машину, затем однажды он перестал работать (ничего на удаленной машине не изменилось). Другие RDP-соединения, которые я сохранил, все еще работали, за исключением этой машины. Это случилось с использованием аутентификации NLA, которая, кажется, является частью проблемы с новейшей Remmina, не сохраняющей сертификаты. — Николи 26 апреля ’13 в 20:26

  • спасибо, раньше он отлично соединялся, затем я переформатировал сервер, и он перестал работать, удалив строку для этого хоста. — Bor691 15 января 14 года в 8:50

  • Мне нужно использовать две службы на одном и том же адресе, но на разных портах, и повторное использование — единственный способ подключиться к обоим. — Гринго Суаве 13 октября 14 года в 18:55


itsadok

08 авг ’13 в 08:33
2013-08-08 08:33

2013-08-08 08:33

Это случилось со мной, когда я скопировал мою конфигурацию remmina (под ~/.remmina) с одной машины на другую. Возможно версии remmina были другими; изменение безопасности не помогло, но удаление и воссоздание соединения сделали.

2013-02-12 22:25

Вероятно, глупый ответ, но проблема для меня заключалась в том, что я пытался подключиться через открытую сеть Wi-Fi (незашифрованную), а remmina этого не допустила. Как только я подключился к защищенной сети, все снова заработало, как и планировалось.

2017-06-15 22:38

Сегодня была такая же проблема с remmina 1.4.8, которую я установил с флетпака. Я пробовал все решения, упомянутые выше, и ни одно из них не работало. У меня два ноутбука, и на одном remmina работала, но на новом ноутбуке с новой установкой не работала. Итак, единственное решение, которое работало для меня, — это удаление версии Flatpak и установка версии deb 1.4.2. И это работает без проблем.


DMG

09 окт ’20 в 14:07
2020-10-09 14:07

2020-10-09 14:07

Просто чтобы добавить к ответу itsadok

Была такая же проблема при попытке RDP на сервер Windows. Чтобы убедиться, что проблема не связана с неправильным паролем, я попытался подключиться по SSH к серверу Ubuntu, и он работал нормально.

Вот как я это исправил:

Во-первых, нам нужно удалить // файл, который использует Remmina:

Если вы установили Remmina как snap -пакет, выполните приведенную ниже команду, чтобы удалить
known_host/
known_hosts/
known_hosts2файл:

      sudo rm -rf ~/snap/remmina/current/.config/freerdp/known_hosts2

ИЛИ ЖЕ

      sudo rm -rf ~/snap/remmina/current/.config/freerdp/known_hosts

ИЛИ ЖЕ

      sudo rm -rf ~/snap/remmina/current/.config/freerdp/known_host

Если вы установили Remmina как подходящий пакет, запустите:

      sudo rm -rf ~/.config/freerdp/known_host

Затем полностью остановите Реммину. Для этого откройте приложение Remmina, а затем выполните приведенную ниже команду, чтобы остановить процесс Reminna из командной строки:

      pgrep remmina | xargs sudo kill -9

Затем вы можете снова запустить приложение Remmina, на этот раз все должно работать нормально.

Это все.

надеюсь, это поможет

2021-04-06 10:30

Это сработало для меня, изменив безопасность на NLA по неизвестной причине.

2017-05-03 08:38

В моем случае я получал ошибку:

Не удалось подключиться к RDP-серверу «192.168.XX» через TLS. Для получения дополнительной информации см. трассировки DEBUG с терминала.

Произошло после последнего обновления remmina в snap store 19 мая 2022 года (сегодня), оно работало 17 мая, за два дня до обновления.

Оказалось, что я видел много ошибок «отказано в доступе» внутри каталога.

Я удалил и переустановил remmina из магазина снап, и все снова заработало. Ничего о TLS или безопасности или что-то еще.

Похоже, разрешения перепутались в
/home/username/snap/remminaпапка.

Обновление: повторилось через 15 дней.

Решение :

Я удалил версию snap и установил ее из репозитория, и все хорошо.


Wadih M.

19 май ’22 в 23:06
2022-05-19 23:06

2022-05-19 23:06

Похоже, проблема с разрешением. Пытаться:

      sudo chattr -i ~/.local/share/remmina/RDP/known_hosts2

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


anakha

03 июн ’21 в 07:18
2021-06-03 07:18

2021-06-03 07:18

Это также может быть проблема с проверкой сертификата. Чтобы проверить, является ли это проблемой, перейдите по ссылке:

Дополнительно -> проверить «Игнорировать сертификат»

Будьте осторожны, если эта проверка отключена, вы можете быть открытыми для человека в середине атаки. Но должно быть нормально подключаться по внутренним сетям.

2018-10-01 14:39

я должен был изменитьSecurity protocol negociationкRDP protocol securityвAdvancedвкладку, чтобы иметь возможность подключаться к Windows Server R2 из Ubuntu 22.04 с Remmina 1.4.25 .

2022-10-31 11:07

Примечание. Служба xrdp могла быть остановлена ​​в вашей удаленной службе. Как корень:

  1. Подтвердите, что RDP-порт 3389 в удаленной системе прослушивается. используйте: { $ netstat -tulpn }
  2. Если порт 3389 закрыт, убедитесь, что xdrp активен, используйте: { $ service xdrp status }
  3. Если неактивен… запустите его, используя: {$ service xdrp start}
  4. Чтобы служба xrdp запускалась автоматически при каждом выключении системы, используйте: { $ systemctl enable xdrp }


Femi Fawe

24 фев ’22 в 17:29
2022-02-24 17:29

2022-02-24 17:29

Пока соединение через бастион работает когда хочет с Remmina. В итоге я открыл SSH-туннель с терминала, например:

      ssh -L 2000:<ip of windows machine>:3389 bastion

Затем я настраиваю Remmina для подключения к RDP только на локальном хосте:2000.

Я знаю, что это выглядит уродливо, но это так же прочно. И если ни один из трюков, объясненных в этом посте (например, TLS, NLA, RDP в расширенном режиме), этот при запуске SSH-туннеля обойдет все проблемы, связанные с Remmina и libssh.


jmary

19 окт ’22 в 12:03
2022-10-19 12:03

2022-10-19 12:03

Проблема в настройке viewmode=1 в сохраненном файле conf. Если вы измените размер окна, оно должно обновиться и начать показывать сеанс. Изменение этого логического значения на 0 заставит окно по умолчанию и оно будет обновляться при загрузке. Проблема в том, что если вы измените размер окна после начала сеанса, remmina вернет этот параметр обратно.

A work around would be to set the window_maximize=0 to true and then just click/press the maximize button/shortcut to bring it back to your settings. 
window_maximize=1 
window_height=960 
viewmode=1 
Window_width=1440


JayMcB74

27 фев ’13 в 14:21
2013-02-27 14:21

2013-02-27 14:21

Я изменил «Согласование протокола безопасности» с «Безопасность протокола TLS» на «Безопасность протокола RDP» в «Дополнительных» свойствах «Профиля удаленного подключения», и это работает.


Jan Vavra

01 сен ’22 в 06:19
2022-09-01 06:19

2022-09-01 06:19

Есть 2 связи. После обновления до Ubuntu 22.04 одно соединение работает, другое нет. Попытка удалить known_host: при первом подключении спрашивает о сертификате, при втором не спрашивает — выдает ошибку. Решено переключение безопасности на RDP.

2022-04-28 09:06

Удалить
known_host файл в
~/.config.

Выполните эту команду:

rm ~/.config/freerdp/known_host



21 сен ’20 в 08:58
2020-09-21 08:58

2020-09-21 08:58

Была такая же проблема с использованием RDP-соединения с туннелем SSH. Решение состояло в том, чтобы переключиться на «Туннель через петлевой адрес» в настройках туннеля SSH.

Попытки всех вариантов «Согласование протокола безопасности» и «Тип транспорта шлюза» не увенчались успехом.

2021-06-04 21:39

Источник

А бывает ли у вас такое, что не работает RDP? Ну, то есть, может и работает, но подключиться к виртуалке не получается. Скорее всего, для многих это не будет никакой проблемой, и у каждого прямо с сейчас с ходу найдётся пара советов, куда зайти и что проверить. Но вдруг, кто-то о чём-то всё же не знает. Здесь собрали несколько рецептов решения, начиная с самых банальных. Ну, на всякий случай…

Начнём с того, что иногда люди сами себе отрубают RDP, после чего обращаются в техподдержку, надеясь, что проблема не на стороне клиента. В таких случаях специалисты техподдержки только и могут, что предложить переустановку.

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

Во-первых, необходимо убедиться, что на виртуальном сервере достаточное для штатного функционирования службы RDP количество оперативной памяти. Возможна, например, ситуация, когда на виртуалке нагружено большое количество торговых ботов и сервер под такой нагрузкой не может толком раскрутить даже RDP.

Во-вторых, пользователь мог сам закрыть порт 3389 на сервере, который и используется по умолчанию службой RDP. Правила для входящих подключений по этому порту так и называются – “Удаленный рабочий стол – пользовательский режим”. Ну, вот, всякое же бывает. Допустим, неудачно настроил брандмауэр. Ну, или, скажем, скачал “супер безопасный софт для супер безопасного интернета”.

Иногда что-то может пойти не так с самой рабочей станции, с которой производится подключение. Тогда имеет смысл очистить историю RDP-подключений. Делается это следующим образом:

  • откройте редактор реестра regedit.exe и перейдите в ветку HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client;
  • разверните ветку реестра HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default, и чтобы очистить историю последних RDP-соединений, выделите все ключи с именами MRU0-MRU9, щелкните правой клавишей и выберите пункт Delete или Удалить.
Очистка истории последних RDP-соединений в реестре

Чтобы очистить историю всех RDP-подключений и сохранённых имён пользователей, нужно очистить содержимое ветки реестра Servers. Так как выделять все вложенные ветки не очень удобно, проще всего удалить ветку Servers целиком, а затем пересоздать ее вручную.

Полная очистка истории RDP-соединений в реестре

Те же операции можно сделать и через Powershell. Для получения информации о правилах брандмауэра приложение должно быть запущено с правами администратора.

Запуск Powershell от имени администратора

Далее, необходимо проверить, запущена ли служба:

Get-Service TermService

Из полученного результата следует убедиться, что поле Status установлено в значение Running:

Get-Service TermService

Также, это можно посмотреть в диспетчере задач на вкладке Services (Службы) или в оснастке services.msc:

Службы удалённых рабочих столов

Ещё необходимо проверить, слушается ли порт 3389 на стороне сервера. Сделать это можно так же через Powershell:

Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 3389

Порт должен быть в выведенном списке. Поле State должно иметь значение Listen.

Get-NetTCPConnection -State Listen | Where-Object LocalPort -EQ 3389

На виртуальном сервере проверить порт 3389 можно и через монитор ресурсов (resmon.exe). Активность порта видна на вкладке Network (Сеть) в разделе TCP Connections (TCP-подключения):

Монитор ресурсов

Туда же можно попасть через Диспетчер задач, перейдя на вкладку Performance (Производительность) и далее на Open Resource Monitor (Открыть монитор ресурсов):

Диспетчер задач

Также, данный функционал доступен через Панель управления → Администрирование → Монитор ресурсов:

Монитор ресурсов в Панели управления

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

Итак, для брандмауэра Windows проверьте, существует ли правило, разрешающее входящие подключения RDP:

Get-NetFirewallPortFilter | Where-Object LocalPort -EQ 3389 | Get-NetFirewallRule

Поле Enabled должно иметь значение True, поле Action – значение Allow.

Get-NetFirewallPortFilter | Where-Object LocalPort -EQ 3389 | Get-NetFirewallRule

Также, эти данные доступны в оснастке wf.msc:

Оснастка wf.msc

Перейти к настройкам брандмауэра можно также через Windows Administrative Tools в меню Пуск.

Брандмауэр Windows в Панели управления - настройка RDP

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

Запуск аварийного режима если не работает RDP

Ну, и наконец в крайнем случае, если на сервере нет важных данных, можно переустановить систему или написать в техническую поддержку.

Источник

Понравилась статья? Поделить с друзьями:
  • Ошибка неисправность тормозной системы аутлендер хл
  • Ошибка неизвестный сервер minecraft
  • Ошибка неисправность свечей зажигания
  • Ошибка невозможно подключиться к серверам rockstar
  • Ошибка неизвестный репозиторий powertools