This is an old revision of the document!
Всем привет!
Сегодня хочу рассказать о двух случайно обнаруженных “фичах” известных протоколов, которые позволили сложиться пазлу, из темы статьи.
И так, у сотрудника техподдержки есть необходимость подключаться к рабочему столу пользователя, что бы совместно что-то сделать. Раз нет TeamViewer, значить надо использовать что-то похожее, например VNC. Тут же “выплывают” проблемы:
Эти проблемы решает первая “фича” - оказалось, что VNC позволяет организовать подключение “наоборот”, не с клиента на сервер, а с сервера на клиент. В системе Windows пользователь может установить, например, пакет TightVNC оставляя все опции, “по умолчанию”, и, не меняя и не выясняя случайно сгенерированный пароль, который теперь никому не понадобится.
Здесь можно представить картинку:)
Этот же пакет нужно будет установить сотруднику техподдержки, серверная часть ему не нужна, можно убрать ее из автозагрузки, а понадобится TightVNC Viewer запущенный в Listening mode
Здесь можно представить картинку:)
Теперь, по просьбе сотрудника техподдержки, пользователю будет достаточно выбрать меню Attach Listening Viewer
Здесь можно представить картинку:)
Если пользователи работают в Linux, то необходимой функциональностью обладает пакет x11vnc, который в debian ориентированных дистрибутивах может быть установлен командой:
$ sudo apt install x11vnc
Для предоставления своего рабочего стола сотруднику техподдержки пользователю будет достаточно набрать в терминале
$ x11vnc -connect ip_адрес_компьютера_сотрудника_техподдержки
Если и сотрудник техподдержки работает в Linux, он может установить пакет tigervnc-viewer
$ sudo apt install tigervnc-viewer
и, перед оказанием помощи пользователю, запустить в терминале команду:
$ vncviewer -listen
СТОП! Как это ip_адрес_компьютера_сотрудника_техподдержки? А если (даже наверняка) это такой же “серый” адрес в локальной сети за роутером, как и у сотрудника?
Эту проблему решает вторая “фича” - оказалось что сервис SSH не только позволяет, благодаря опции GatewayPorts yes, установить подключение с компьютера сотрудника к SSH серверу и назначить внешний TCP порт для встречных соединений, которые можно “направить” в VNC viewer, но и назначить номер порта динамически
Команда будет выглядеть вот так (обратите внимание на 0, там где указывается номер внешнего порта):
ssh -R 0:localhost:5500 логин_сотрудника_техподдержки@ip_адрес_ssh_сервера
И да, VNC viewer, в режиме listen, ожидает, по умолчанию, подключения на порту 5500, и теперь его можно ограничить только интерфейсом localhost
Теперь, если ip_адрес_ssh_сервера публичный, пользователи смогут предоставить свой рабочий стол, указав вместо ip_адреса_компьютера_сотрудника_техподдержки - ip_адрес_ssh_сервера:сгенерированный_номер_порта
Некоторой проблемой оказалось “выяснение” назначенного динамического порта