Комментарии 30
Сам VNC протокол стандартизован, поэтому теоретически можно использовать любой VNC сервер.
Не согласен.
NoVNC поддерживает только кодировки Tight, Hextile и совсем примитивные. Т.е. единственная, сносно работающая за пределами локальной сети — это Tight. А ее поддерживают не все VNC-сервера. Например, платный RealVNC ее не поддерживает, и будет работать медленно через noVNC (т.к. скатится на Hextile).
Пишут, что они не поддерживают tight, но поддерживают tightPNG и это самый быстрый режим для noVNC.
Теперь надо вот разобраться, какие VNC серверы поддерживают tightPNG.
В общем, noVNC работает заметно медленней RDP, но вполне терпимо.
Сам я TeamViewer QS не пробовал, но
— похоже его надо запускать на удалённом компьютере, тогда как noVNC может работать как сёрвис.
— да, Team Viewer (не QS) можно поставить, как сёрвис. Вот интересно в этом случае, — нужно ли инсталлировать что-то клиентской стороне? И будет ли это работать в организациях, где заблокировано всё, кроме HTTP?
1) Разовая помощь извне какому-то сотруднику внутри периметра — это слегка против корпоративной политики, но иногда ради сил добра можно так побаловаться ради хорошего человека поперёк тупого внутреннего саппорта. Для этого портативный .exe как раз, а TV QS умеет разные способы связи. Да и то, TV обычно старается не запускаться на компе, который является частью домена.
2) Постоянный доступ извне внутрь корпоративки вопреки корпоративке — тут я никак не могу придумать для чего такие хитрости.
Как админ организации могу сказать, что такое нужно, когда, например, нахожусь в отпуске или на выходных, при этом квалификации других специалистов, остающихся на работе может оказаться недостаточно, потому что мы — бюджетная организация, и не можем себе позволитьболее одного специалиста соответствующего профиля, то есть только один админ-сетевик, один админ баз данных и т.д., и, например, по правилам инфобезопасности, у админа сетевого нет доступа к базам данных, и наоборот.
В этом случае такие средства как TeamViewer и аналоги выручают как никогда, при этом не нужно пробрасывать доступ извне ко всем компам домена, достаточно доступа к компу админа, а с него по цепочке уже через RDP к любому другому в домене.
На клиентской стороне можно хоть веб-интерфейс использовать, достаточно знать ID и пароль серверной стороны.
Для SlavikF: TV может работать и по 80-му порту, если остальное закрыто, заблокировать можно только заблокировав на шлюзе сервера TeamViewer.com
Вот только бывает случаи, когда блокируются не порты, а протокол. Не знаю, как TV ведёт себя в этом случае. Знаю, что Chrome Remote Desktop «не пролазиет» через наш корпоративный прокси.
V может работать и по 80-му порту, если остальное закрыто, заблокировать можно только заблокировав на шлюзе сервера TeamViewer.com
Явная дыра, всё не заблокируешь. А вот SRP просто не дает запускать TV.
Извиняюсь, ответ адресован выше.
rdpwrap github
— У Windows есть «родное» средство для удалённого доступа — Remote Desktop Connection. Но оно есть не во всех версиях Windows — например нет в Home edition.
Я все равно не понял почему не RDP =\
Home редакция для домашнего использования — или у меня фантазия скудная, но я не смог придумать сценарий чтобы мне на домашний ПК был нужен протокол удаленного доступа, в редких случаях я юзаю TeamViewer…
Ещё есть SPICE, но для него я не нашёл сервера под Windows.
И правильно что не нашли, SPICE — это протокол доставки рабочего стола, используется в виртуальной среде и только, т.к. требует наличия виртуальной видеокарты (QXL) на клиенте, и поддержки со стороны Хозяина
Если ищете адекватную замену VNC, есть еще X2Go — но этот скорее для Linux. Из свободных решений для Windows ничего лучше VNC пока не придумали.
VNC — медленный, но позволяет подключаться к пользовательской сессии, в RDP это так же поддерживается, но только в серверных версиях Windows — называется shadow sessions. Упомянутый выше патч rdpwrap вроде может вернуть эту функцию и на клиентских Windows, но я не проверял, и кроме того это нарушает клиентскую лицензию.
В вашем случае думаю что вам будет крайне интересно попробовать проект Guacamole — это свободный RDP(и VNC)-gatevay, который позволит вам настроить список всех клиентов, и подключатся к ним по RDP или VNC прямо из браузера.
В случае успеха, обязательно пишите еще! — статей про Guacamole на хабрахабре раз-два и обчелся, народ должен знать :)
1. Я тогда использовал вируализацию на CentOS7, там идёт старая версия программы, в которой RDP поломан в принципе.
2. Со свежим Guacamole проблема была интереснее — он частично отваливался и переставал транслировать изменения на рабочем столе, при это Input обрабатывал (т.е. переподключаюсь и вижу результат клика мыши, к примеру). Но происходило это нечасто (скажем, раз в час в среднем) и решалось простым нажатием F5 в браузере.
Обе проблемы радикально решались переходом на VNC. Но данный переход закончился у меня невесело — письмом от службы безопасности, по гигантскому потреблению трафика.
Не могу не согласиться с вами на счет подобных сложностей при настройке.
Но есть достаточно безболезненый способ попробовать — это docker:
https://github.com/glyptodon/guacamole-docker
Этот образ позволяет развернуть готовое, а главное стабильное, окружение за считанные минуты и всего за пару команд.
Обычно недоадмины используют блокировку по портам.
А вы говорите что noVNC работает по нестандартному порту 5901. т.о. вероятность что трафик пройдет очень низка…
входит в противоречие с
>> Теперь запускаем command prompt с администраторскими правами:
т.е. без прав администратора этим решением воспользоваться проблематично или я ошибаюсь?
Во-вторых, если есть возможность развернуть apache/tomcat в локалке, то guacamole — отличная вещь!
По-поводу TigthtVNC - как сказал @Stkn по-умолчанию действительно loopback connections запрещены, поэтому либо поставить соответствующую галку в настройках сервера, либо просто запускать websockify.exe, используя адрес в LAN (т.е. lan_ip:5900). Плюс, у меня даже после этого постоянно возникала ошибка: "Client must support 'binary' or 'base64' protocol". Решил следующим образом:
Воспользовался рекомендациями отсюда - https://stackoverflow.com/questions/15962359/websockify-error-client-must-support-binary-or-base64-protocol и заменил в двух местах noVNC-master\core\rfb.js и noVNC-master\core\websock.js параметр this._wsProtocols и protocols на массив ['binary', 'base64'] .
Выбрал порт отличный от 5091 для websockify.
После этих двух изменений, все сразу запустилось. Использовавшая версия TightVNC - tightvnc-2.8.59-gpl-setup-64bit.
Настройка удалённого доступа к Windows с помощью noVNC