LINUX.ORG.RU

Подключение по RDP к Win2008R2 через Linux.

 , ,


0

1

Доброго дня, Господа!

Столкнулся с некой непоняткой в работе различных RDP-клиентов под Debian и Ubuntu. Нужна Ваша помощь.

На объекте есть 2 подсети: 10.0.0.0/23 (1) и 192.168.0.0/16 (2). В 1-ой подсети распологаются Linux.desktop-машины, в другой - Windows-машины и терминальный сервер Win2008R2 по адресу 192.168.0.1

2 подсети разделяет файерволл Vipnet HW, который сейчас пропускает Весь трафик по протоколам tcp, udp, icmp с любых IP и портов.

Файервол пропускат нормально: пинги, телнеты на 3389 порт - всё пропускает нормально.

[L]----(1)----[V]----(2)----[T] L- линукс декстоп V- файрвол Vipnet T- терминальный сервер Win2008R2

На линукс.декстоп установил krdc, remmina, rdesktop.

А теперь про непонятку: ни одна программа под Linux не коннектится к RDP-серверу. Либо долго весит «Соединение с...», либо в случае с krdc - просто «синий» экран. В общем я не получаю даже картинки ввода пароля.

В remmina я подключаюсь с Безопасность - RDP. В KRDC - с ключём --sec rdp.

Если я Линукс-машину в подсеть (2) - оба RDP-клиента подключаются без проблем.

По логике я начал проверять настройки файерволла, но после обнаружил это: я подключил Линукс-машину в подсеть (1) и поднял на ней виртуалку с WinXP с мостом в подсеть (1). К моему удивлению - штатная подключалка RDP XP-шки без проблем выдала картинку с терминального сервера. То есть файервол пропускает соединения нормально. Однако с linux ни один RDP-клиент так и не установил соединение из подсети (1).

В IPTABLES правил нет.

Подскажите, в чем может быть разница linux-ориентированных RDP-клиентов в сравнении со штатной RDP-подключалки WinXP?

Ответ на: комментарий от Ja-Ja-Hey-Ho
$ xfreerdp -u user -p "password" -g 1280x720 --sec rdp --plugin cliprdr 192.168.0.1
--plugin cliprdr -> +clipboard
WARNING: Using deprecated command-line interface!
--plugin cliprdr -> +clipboard
-g 1280x720 -> /size:1280x720 or /w:1280 /h:720
-p ****** -> /p:******
-u user -> /u:user
--sec rdp -> /sec:rdp
192.168.0.1 -> /v:192.168.0.1
loading channel cliprdr
unable to connect to 192.168.0.1:3389
Error: protocol security negotiation or connection failure
PIKNIK ()
Ответ на: комментарий от PIKNIK

Это не будет работать, смотри виндовый брандмауэр, по умолчанию разрешено только тачкам той же подсети, винда в виртуалке с мостом какой ip получила?

anonymous ()
Ответ на: комментарий от anonymous

В смысле работать то будет, только настроить исключения надо

anonymous ()
Ответ на: комментарий от PIKNIK

Шаманство...

Попробовал прописать явный маршрут на клиенте в подсеть (2). Чем его общий шлюз на тот же IP не устраивал - не знаю. xfreerdp радостно подключился к серверу и вывел мне картинку. При тех же условиях и krdc, и remmina стопорятся на том же самом этапе, что и раньше.

PIKNIK ()
Ответ на: комментарий от anonymous

роверил брандмауэр еще давно. Там правило открыто. К тому-же виндовая машина без проблем подключается из (1) подсети, не забывайте. Она и получила адрес из (1) подсети - 10.0.0.156

PIKNIK ()

В настройках на сервере rdp разрешите подключаться с любой версией клиента

Belen ★★ ()

В общем двоякая ситуация получилась:

На момент когда я писал первую статью - я пробовал входить с логина/пароля AD-пользователя который мне выдал другой админ. Как выяснилось - он забыл «включить» учётную запись.

При этом krdc из подсети (2) мне вывел сообщение, что учётка отключена (я когда проверял работу linux-машиной из подсети (2) я просто дошел до приглашения ввода логина/пароля и закрыл соединение), а вот из подсети (1) данное сообщение не выводилось, а просто висел «синий» экран как при подключении. Стоило только включить УЗ и войти под ней с первого раза - подключается всё отлично.

Ситуация с явным маршрутом мне пока не ясна, но скорее всего это единичный «плавающий» случай.

С подключением разобрались.

За отображение Windows-приглашения_ввода_пароля отвечает ключ "... --sec rdp ...". Если его нет - то пользователю необходимо с первого раза правильно ввести логин и пароль в интерфейсе krdc. Иначе - он будет висеть на «синем» экране. Если есть - то можно ошибиться на этом этапе и получить ошибку уже на терминальном сервере. Правда на ubuntu (в отличие от Debian) ключ --sec rdp у меня не сработал вышеуказанным образом. Попробую еще потыкать, но пока что так.

Думаю, что тема пока не нужна т.к. основной функционал и ответы на все непонятные вопросы я получил.

Если будет что еще интересного - отпишу.

Благодарю всех Вас за помощь!

PIKNIK ()
Ответ на: комментарий от PIKNIK

На Ubuntu версия KRDC - 4.14.6 На Debian - 4.14.1

При этом на убунте у меня xfce4, а на дебиане KDE

PIKNIK ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.