Сервер VNC или удаленный рабочий стол на Ubuntu. Некоторые распространенные методы устранения проблем

Сегодня я расскажу про установку и настройку vnc сервера tightvnc в ubuntu 14.04 и 16.04. Сначала поговорим о том почему я выбрал именно tightvnc. Когда я первый раз ставил vnc сервер, я сначала поставил x11vnc, его описывали как легкий в установке и удобный vnc сервер. Так и есть, все работает «из коробки», но вот незадача — этот vnc сервер работает с уже существующей сессией пользователя, а не создает новую. То есть он подключается к текущему рабочему столу пользователя. Многим это подойдет, но мне нужен был такой vnc сервер, который бы при запуске создавал новую сессию. Тут на помощь мне и пришел tightvnc сервер. При запуске tightvnc сервер создает новую сессию для пользователя. Плюсы такого сервера в том, что можно задать произвольное разрешение создаваемого рабочего стола, в независимости от ограничений, наложенных системой компьютера. Например, если удаленный компьютер позволяет выставить максимальное разрешение 1280х1024, это никак не помешает создать с помощью tightvnc сервера рабочий стол с разрешением еще больше. Так же с помощью tightvnc сервера можно создать несколько рабочих столов. Это очень удобно когда необходимо организовать работу для нескольких пользователей на одном компьютере.

И так, давайте приступим к установке tightvnc server в ubuntu 16.04 и 14.04 :

Sudo apt-get install tightvncserver

Запуск tightvnc : в терминале набираем (запуск от текущего пользователя, sudo не нужен)

Vncserver

При первом запуске нужно будет ввести пароль доступа к vnc серверу (минимум 6 символов), и по желанию пароль доступа в режиме «только просмотр».

По умолчанию порт tightvnc сервера 5901. Можно указать другой порт так:

Vncserver:2

При этом tightvnc сервер будет запущен на порту 5902.

Запуск tightvnc server с заданным разрешением экрана осуществляется с параметром geometry, например:

Vncserver -geometry 1280x1024

То есть, если в терминале набрать:

Vncserver -geometry 1280x1024:3

то на порту 5903 будет запущен vnc сервер с разрешением рабочего стола 1280×1024 пикселей. Есть еще куча параметров — глубина цвета и много чего еще, в этой статье рассматриваются только основные.

Остановка tightvnc server :

Vncserver -kill:1

Будет остановлен vncserver на порту 5901.

Настройка tightvnc server

При установке tightvnc server в каталоге /home/пользователь/.vnc создается скрипт запуска, который называется xstartup. Дело в том, что при создании новой сессии tightvnc server запускает обычные иксы, а xstartup — конфигурационный файл для создаваемой x-сессии, в котором нужно указывать все программы, которые должны загружаться при старте x-сессии, вплоть до таких, как оконный менеджер, например. Вот почему, если не редактировать скрипт запуска и подключится к tightvnc серверу, то вы увидите просто серый экран. Чтобы это исправить, давайте отредактируем файл /home/пользователь/.vnc/xstartup. Первое, что нам понадобится — это добавить туда оконный менеджер. Я рекомендую оконный менеджер «metacity». Установим его:

Sudo apt-get install metacity

После установки добавим строку «metacity &» в файл xstartup:

#!/bin/sh xrdb $HOME/.Xresources #xsetroot -solid grey metacity &

Далее нужно запустить одно приложение, хотя бы терминал. В зависимости от версии дистрибутива linux команды для запуска терминала могут различаться. У меня установлен gnome-terminal. В вашем случае он может не быть установлен, а установлен xterm например. Вообщем, смотрите логи, если у вас ничего не запустится. Логи находятся в той же папке, что и xstartup.

Добавьте строку терминала следующей строкой после «metacity &»:

Gnome-terminal &

В принципе, это минимально возможная конфигурация, так как из терминала можно запустить любое приложение, но мы, чтобы до конца понять суть xstartup, добавим туда еще и браузер firefox. Все вместе получится приблизительно так:

#!/bin/sh xrdb $HOME/.Xresources #xsetroot -solid grey metacity & gnome-terminal & firefox # Fix to make GNOME work export XKL_XMODMAP_DISABLE=1 /etc/X11/Xsession

После внесения изменений в xstartup обязательно перезапустите tightvnc server, если он был запущен. Сейчас после подключения к tightvnc серверу на рабочем столе должен появится открытый терминал и браузер firefox. Но это еще не все. При желании вы можете добавить туда множество приложений, nautilus например, ну вообщем по вашему усмотрению. Я бы рекомендовал добавить док панель вместо них, например gnome-panel, чтобы каждый раз не лезть в терминал для запуска того или иного приложения. Давайте установим ее:

Sudo apt-get install gnome-panel

И добавим ее в файл xstartup вместо приложений terminal и firefox:

#!/bin/sh xrdb $HOME/.Xresources #xsetroot -solid grey metacity & gnome-panel # Fix to make GNOME work export XKL_XMODMAP_DISABLE=1 /etc/X11/Xsession

Теперь при старте x-сессии будет запускаться панель gnome.

Вот и все, настройку tightvnc server на этом можно завершить. Но для прожженных гномоводов у меня еще кое что есть, при старте x-сессии можно запустить gnome сессию. Вот скрипт запуска для gnome сессии:

#!/bin/sh gnome-session & gnome-panel & gnome-settings-daemon & metacity export XKL_XMODMAP_DISABLE=1 #/etc/X11/Xsession

Хочу предупредить, что у меня в gnome сессии возникали глюки с браузерами: раскладка не переключалась, некоторые клавиши срабатывали неправильно. Вообщем смотрите что для вас лучше — иксы или gnome сессия.

В статье рассказано о настройке возможности подключения к Ubuntu по удаленному рабочему столу (аналогично RDP в Windows). Примеры команд выполнены на Linux Ubuntu 18.04.

Установка и настройка VNC сервера

Рассмотрим два варианта использования графической оболочки — xfce и gnome.

Если используется брандмауэр, добавляем правило:

iptables -A INPUT -p tcp --dport 5901 -j ACCEPT

* в данном примере, мы разрешаем входящие соединения на порту 5901 . Для работы с несколькими портами, добавляем их по аналогии.

XFCE

Установка

apt install xfce4 xfce4-goodies tightvncserver

y n ).

Настройка

vncserver -kill:1

* экземпляр :1

Настраиваем VNC сервер:

vi ~/.vnc/xstartup

#!/bin/bash
xrdb $HOME/.Xresources
startxfce4

Снова запускаем vncserver:

Gnome

Установка

Установку выполняем следующей командой:

apt install ubuntu-desktop gnome-panel gnome-settings-daemon metacity nautilus gnome-terminal vnc4server

Задаем пароль для доступа по удаленному рабочему столу. Для этого вводим команду:

На запрос пароля вводим его дважды. После будет предложено ввод пароля для гостевого доступа — можно согласиться (y ) и ввести пароль или отказаться (n ).

Настройка

Для начала, останавливаем экземпляр VNC сервера:

vncserver -kill:1

* экземпляр :1 , по умолчанию, слушает на порту 5900+1 (5901).

Настраиваем VNC сервер для текущего пользователя:

vi ~/.vnc/xstartup

#!/bin/sh
# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
x-window-manager &

Gnome-panel &
gnome-settings-daemon &
metacity &

Снова запускаем vncserver:

Подключаемся к удаленному рабочему столу

Запускаем клиент VNC. Например, в Linux — Remmina, в Windows — TightVNC Viewer или RealVNC . Вводим IP-адрес компьютера с VNC и номер порта:

Будет запрошен пароль — вводим тот, что устанавливали при настройке.

Автозапуск сервиса

Чтобы VNC сервер запускался после перезагрузки, создаем новый юнит в systemd:

vi /etc/systemd/system/vncserver.service

Description=VNC server
After=syslog.target network.target

Type=forking
User=root
PAMName=login
PIDFile=/root/.vnc/%H:%i.pid
ExecStartPre=-/usr/bin/vncserver -kill:1 > /dev/null 2>&1
ExecStart=/usr/bin/vncserver
ExecStop=/usr/bin/vncserver -kill:1

WantedBy=multi-user.target

Обновляем systemd:

systemctl daemon-reload

Разрешаем автозапуск сервиса.

• Tutorial

Это руководство о том, как настроить noVNC для удалённого доступа к компьютерам на Windows.

Почему noVNC?

Насколько я знаю, noVNC - единственное средство, которое позволяет подключиться к удалённому компьютеру без установки какого-либо клиента - используется лишь браузер.
Ещё есть SPICE , но для него я не нашёл сервера под Windows.

В результате этого руководства, мы сможем просто открыть линк в браузере, ввести пароль и пользоваться удалённой системой.

Необходимым условием является проброс портов, или белый IP удалённого компьютера. Также можно воспользоваться VNC repeater. Но это уже выходит за рамки этой статьи.

Общая схема

Затем поставим noVNC и WebSockify на порт 5901.

Цель, чтобы получилось приблизительно вот так:

C:\> cd c:\noVNC\websockify c:\noVNC\websockify> websockify.exe 5901 127.0.0.1:5900 --web c:\noVNC\noVNC-master WARNING: no "resource" module, daemonizing support disabled WebSocket server settings: - Listen on:5901 - Flash security policy server - Web server. Web root: c:\noVNC\noVNC-master - No SSL/TLS support (no cert file) - proxying from:5901 to 127.0.0.1:5900
Первый параметр выше - порт на котором noVNC будет слушать: 5901 . Этот порт нужно сделать доступным для клиентов.

Второй параметр - IP и порт, где стоит VNC сервер: 127.0.0.1:5900

Третий параметр --web инструктирует noVNC, чтобы он отдавал содержимое директории c:\noVNC\noVNC-master по HTTP(s). По умолчанию noVNC отдаёт только VNC вебсокет, но этот параметр позволяет иметь и HTTP сервер на этом же порту.

В директории c:\noVNC\noVNC-master переименуйте файл vnc.html в index.html , чтобы он отдавался по умолчанию.

Теперь noVNC клиент должен быть доступен на порту 5901:

Что у вас Windows Firewall не блокирует внешние подключения на этот порт,
- что ваш роутер правильно перенаправляет запросы на этот порт на нужный компьютер; если надо гуглите «проброс портов».

Соединяемся (Connect), вводим VNC пароль и видим рабочий стол удалённого компьютера!

Если что-то пошло не так, то ошибки должны показаться в нашей консоли.

Остановить noVNC сервер можно нажав Ctrl-C в консоли. Описанная выше конфигурация работает по HTTP (и по WS).

Добавляем SSL с самоподписанным сертификатом

Openssl req -new -x509 -days 365 -nodes -out self.pem -keyout self.pem
Для Windows openssl можно взять .

В результате получаем файл self.pem, на который надо указать при старте noVNC:

C:\noVNC\websockify> websockify.exe 5901 127.0.0.1:5900 --web c:\noVNC\noVNC-master --cert=c:\noVNC\self.pem
Теперь у нас работает HTTPS и WSS (WebSocket Secure). Для WSS в настройках (Settings) нужно указать Encrypt. Интересно, что noVNC использует один и тот же порт для HTTP и HTTPS - он «умеет» различать запросы и правильно отвечать.

Так как сертификат самоподписанный, то в браузере нужно будет принять этот сертификат.

Let"s Encrypt

В моём случае, у меня уже есть домашний сервачок с NGINX и DDNS именем, который настроен автоматически получать сертификат от Lets Encrypt.

Вы можете запустить что-то похожее у себя. есть инструкции о настройке Let"s Encrypt для Linux и Windows.

Поэтому для noVNC я просто использую уже существующие pem -файлы, сгенерированные для nginx .

Let"s Encrypt создаёт следующие файлы:

Cert.pem: Your domain"s certificate chain.pem: The Let"s Encrypt chain certificate fullchain.pem: cert.pem and chain.pem combined privkey.pem: Your certificate"s private key
На Ubuntu их можно найте по вот такому пути: /etc/letsencrypt/live/your_domain_name

Нужно скопировать (объединить) fullchain.pem и privkey.pem в один файл, например назовём его encrypt.pem , и этот файл мы будем использовать для noVNC .

Конечно, работать это будет только если nginx сервер и noVNC - на одном домене. Порты могут быть разными.

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

Добавляем noVNC, как Windows-сервис

При запуске, сервис будет использовать параметры из файла noVNCConfig.ini . Вот пример моего конфига:

5901 127.0.0.1:5900 --web C:\noVNC\noVNC-master --cert=c:\noVNC\encrypt.pem
В консоли, запущенной с администраторскими привилегиями создаём новый сервис:

Sc create "noVNC Websocket Server" binPath= "c:\noVNC\websockify\noVNC Websocket Service.exe" DisplayName= "noVNC Websocket Server"
Если нужно будет удалить сервис, то вот так:

Sc delete "noVNC Websocket Server"
Открываем сервисы (Control Panel → Administrative Tools → Services) и запускаем noVNC Websocket Server. Также здесь можно настроить, чтобы сервис стартовал каждый раз вместе с Windows:

Известные недоработки

Раскладка клавиатуры

Работа с VNC-клиентом. Материал ориентирован на неопытного пользователя.

1. Установка VNC-клиента
2. Подключение VNC-клиента к удаленному компьютеру
3. Отключение VNC-клиента от удаленного компьютера
4. Тюнинг VNC-клиента
5. Частые проблемы

Для работы с удаленным компьютером по VNC на компьютере пользователя нужно запустить программу-клиент (VNC viewer, VNC client). Эта программа передает на удаленный компьютер данные о нажатиях на клавиши и о движениях мыши, сделанных пользователем, и показывает информацию, предназначенную к выводу на экран.

1. Установка VNC-клиента

Mac OS X начиная с версии 10.5 имеет поддержку VNC-клиента в RemoteDesktop . Для предыдущих версий можно использовать VNC-клиенты JollysFastVNC и .

Для Linux ветви Debian (Ubuntu) VNC-клиент устанавливается из репозитория командой:

Apt-get install vncviewer

Для ветви RedHat (CentOS, Fedora) - командой:

Yum install vnc

Для FreeBSD VNC-клиент (TightVNC) устанавливается из пакетов командой:

Pkg_add -r tightvnc

2. Подключение VNC-клиента к удаленному компьютеру

После установки соединения и открытия экрана, в зависимости от настроек VNC-сервера может потребоваться авторизация пользователя на виртуальном сервере или может быть открыта уже запущенная рабочая сессия какого-либо пользователя.

Так как на компьютере одновременно могут работать несколько VNC-серверов, для их разделения используют параметр номер дисплея . Например, один VNC-сервер может быть запущен на дисплее:0, другой - на дисплее:1. Каждому номеру дисплея соответствует номер TCP-порта, на котором VNC-сервер принимает соединения. Номер порта для дисплея получается прибавлением номера дисплея к базовому номеру порта - 5900. Дисплею:0 соответствует TCP-порт 5900, дисплею:1 - порт 5901.

3. Отключение VNC-клиента от удаленного компьютера

4. Тюнинг VNC-клиента

Главный параметр, который влияет на объем передаваемых данных - алгоритм кодирования передаваемой графики. Для уменьшения объема и, соответственно, ускорения работы, рекомендуется использовать алгоритмы Tight, ZLib, ZRLE - по сравнению с несжатыми данными (Raw), они обеспечивают сжатие в десятки раз, заметно нагружая процессор. Эти алгоритмы кодирования обеспечивают комфортную работу даже на каналах со скоростью 256-512 Кбит/сек.

Для сокращения объема передаваемой по сети информации также можно устанавливать высокий уровень сжатия (Compression Level, Compression Value), низкий уровень качества JPEG (JPEG Quality) и включать режим уменьшения количества цветов (-bgr233, Restricted colors). Самый большой эффект из них при заметном снижении качества изображения дает режим уменьшения количества цветов - объем передаваемой информации уменьшается в 1.5-3 раза, соответственно, в 1.5-3 раза ускоряется отображение на экране.

JPEG применяется алгоритмом кодирования Tight для сжатия участков экрана, содержащих фотографии и другие сложные изображения с большим числом цветов. Использование Tight+JPEG сокращает в 2-5 раз объем передаваемых при этом данных. Другие алгоритмы кодирования JPEG не поддерживают.

1. Выпадающего меню «Система -> Параметры»

Объем передаваемых данных и скорость отображения на канале 1 Мбит/сек при открытии выпадающего меню «Система -> Параметры» (на рисунке меню выделено зеленым пунктиром):

5. Частые проблемы

Не удается подключиться к VNC-серверу

1. есть ли доступ к интернету;
2. отвечает ли виртуальный сервер на пинги;
3. запущен ли на виртуальном сервере VNC-сервер;
4. нет ли по пути файервола, закрывающего доступ к TCP-порту VNC-сервера;
5. правльно ли указан номер дисплея или TCP-порт VNC-сервера (номер порта = 5900 + номер дисплея).

Медленная работа через достаточно быстрый канал

Однако, для некоторых сочетаний клиента и сервера такое решение может быть бесполезным из-за ошибок в согласовании алгоритма кодирования. Например, клиент TightVNC с сервером RealVNC часто могут работать только с кодировкой Raw. Решением в этом случае будет смена VNC-клиента или VNC-сервера.

Как помочь своим пользователям получить доступ к многопользовательской Linux-системе из любого места

Архитектура VNC и X server

В качестве графического интерфейса пользователя (GUI) в Linux®применяется X Window System (сокращенно X ). X - это необычный GUI в нескольких отношениях, в частности, это изначально сетевой интерфейс. X-сервер , по сути, представляет собой программу сетевого сервера. Программы сетевого сервера предоставляют клиентским программам доступ к локальным ресурсам, и это верно также для X-сервера. Особенность заключается в том, что в случае Х-сервера "локальные ресурсы" – это дисплей, клавиатура и мышь, с которыми работает пользователь. В самой распространенной конфигурации программы Х-клиента работают на том же компьютере, что и сервер. Таким образом, LibreOffice, GNU Image Manipulation Program (GIMP) или другие программы являются X-клиентами, использующими сетевые протоколы Х для приема данных от пользователя и отображения результатов на том же компьютере.

Однако когда X используется в сети, пользователь сидит за компьютером X-сервера, а X-клиентами служат программы, которые нужно запускать на другом компьютере. Для этой конфигурации требуется второй сетевой протокол, устанавливающий соединение. Таким вторым протоколом может быть telnet, Secure Shell (SSH) или X Display Manager Control Protocol (XDMCP). Сервер этого протокола удаленного входа работает на компьютере X-клиента, а клиент удаленного входа ― на компьютере X-сервера. Сервер удаленного входа запускает X-клиенты, которые, в свою очередь, устанавливают соединение с X-сервером. иллюстрирует это взаимодействие. Пунктирными стрелками обозначено начало сеанса. (В случае XDMCP XDMCP-клиент встроен в программу X-сервера.)

Рисунок 1. Для удаленного доступа X требуется клиент и сервер на обоих компьютерах

Эта конфигурация прекрасно работает во многих локальных сетях, но не лишена недостатков. Например, для нее нужно инициировать двусторонний сетевой протокол, а этому может помешать межсетевой экран или маршрутизатор Network Address Translation (NAT). (SSH устраняет это препятствие, позволяя туннелировать X-сеансы.) Кроме того, хотя существуют X-серверы для большинства платформ, они обычно не устанавливаются на компьютерах под управлением Windows®. По этим и иным причинам многие предпочитают использовать другой протокол, Remote Frame Buffer (RFB), который реализован в семействе программ Virtual Network Computing (VNC).

VNC - это кроссплатформенный инструмент, который обеспечивает удаленный доступ к Linux, UNIX®, Mac OS X, Windows и другим системам из клиента любого типа. Пользователь сидит за клиентским компьютером и обращается к удаленному серверному компьютеру. В Linux VNC-сервер либо зеркально отражает содержимое локального экрана Х-сервера на удаленный компьютер, либо содержит свой собственный X-сервер, способный работать независимо от того, что управляет локальным экраном. Результат показан на рисунке 2. Опять же, пунктирная стрелка указывает начало сеанса. Эта конфигурация устраняет необходимость в обратном сетевом соединении, а так как клиенты и серверы VNC имеются для многих операционных систем, одна и та же клиентская программа обеспечивает доступ к любому серверу.

Рисунок 2. В состав VNC-сервера входит X-сервер, способный взаимодействовать с локальными программами через X-клиент

Недостаток VNC заключается в том, что аутентификация RFB основана на паролях без имен пользователей. Таким образом, каждый пользователь должен запускать независимый сеанс VNC-сервера и устанавливать соединение с этим экземпляром VNC, указав правильный номер порта. Это требование терпимо для однопользовательской системы, но вызывает крайние неудобства при работе на многопользовательском компьютере.

Для решения этой проблемы можно объединить эти два подхода: перенастроить локальный XDMCP-сервер так, чтобы он помогал X-серверу, встроенному в VNC, обеспечить недостающую многопользовательскую аутентификацию. (Результирующая конфигурация иллюстрируется на рисунке 3. Пунктирная стрелка указывает начало сеанса.) Теперь, когда удаленные пользователи VNC обращаются к компьютеру VNC-сервера, они могут вводить имена пользователей и пароли доступа к своим собственным уникальным сеансам VNC, так что с компьютером могут работать сколько угодно пользователей.

Рисунок 3. Добавление XDMCP к конфигурации VNC обеспечивает повышенную гибкость

Настройка VNC-сервера

Существует несколько способов запуска VNC, включая использование сценариев, привязку VNC к среде рабочего стола с помощью настольных инструментов и использование xinetd для прослушивания VNC-соединений. Этот последний подход и описывается здесь, так как он позволяет запускать VNC так, что тот может использовать XDMCP-сервер. Прежде чем перейти к инструкциям по настройке VNC для запуска посредством xinetd , необходимо выбрать VNC-сервер.

Выбор VNC-сервера

Существует несколько программ VNC-сервера. (См. раздел ). Некоторые из наиболее популярных: TightVNC, TigerVNC и RealVNC. В этой статье в качестве примера используется TightVNC. К сожалению, детали конфигурации зависят как от сервера, так и от дистрибутива, поэтому приведенные здесь инструкции нужно будет адаптировать к своему программному обеспечению.

Установка xinetd

Многие дистрибутивы устанавливают суперсервер xinetd по умолчанию, но не все. Так как описанный здесь метод предполагает использование xinetd , необходимо установить xinetd , если он еще не установлен. В большинстве дистрибутивов xinetd можно установить с помощью менеджера пакетов, например, вызывав apt-get install xinetd в дистрибутивах на основе Debian или zypper install xinetd в openSUSE.

Может также потребоваться настройка процесса запуска xinetd . Обычно для одноразового запуска можно использовать сценарий запуска System V (SysV):

Для настройки автоматического запуска xinetd при загрузке компьютера требуется знание методов работы сценариев запуска своего дистрибутива. Как правило, это делается с помощью утилиты, такой как chkconfig (используется в Fedora, openSUSE и родственных дистрибутивах), update-rc.d (используется в Debian и родственных дистрибутивах) или rc-update (используется в Gentoo), примерно так:

Введите только одну из этих команд или найдите эквивалент для своего дистрибутива.

Заметим, что xinetd может не запускаться, если он не настроен на выполнение каких-либо служб. Так что, возможно, придется отложить его запуск до тех пор, пока вы не настроете xinetd для управления своим VNC-сервером.

Настройка xinetd

Серверы, которыми должен управлять xinetd , помещают файлы конфигурации в каталог /etc/xinetd.d. Таким образом, чтобы настроить xinetd на управление VNC, нужно создать или отредактировать файл с именем типа /etc/xinetd.d/vnc. (В некоторых дистрибутивах, таких как openSUSE, пакет VNC-сервера устанавливает такой файл.) В листинге 1 приведен пример.

Листинг 1. Пример настройки VNC для xinetd

Эта запись задает несколько параметров xinetd , большинство из которых нужно оставить как есть. Ниже перечислены те параметры, которые могут потребовать настройки.

• service . VNC с разными параметрами можно запустить через несколько портов, но в этом случае в первой строке листинга 1 нужно присвоить VNC отдельное имя службы для каждого порта.
• server . Этот параметр нужно изменить так, чтобы он указывал на главный двоичный файл VNC-сервера, который обычно называется Xvnc.
• server_args . Некоторые из этих значений вы почти наверняка захотите изменить, как описано ниже.
• port . VNC использует порты с номерами 5900 и выше. Можно запустить сервер с разными значениями параметров через разные порты. В этом случае каждому экземпляру нужно назначить свой номер порта.

Самая каверзная часть настройки xinetd - это настройка аргументов сервера. В качестве модели можно использовать аргументы, приведенные в листинге 1, изменив некоторые из них.

• -query localhost . Этот параметр указывает, что сервер VNC X должен проверять систему localhost на аутентификацию XDMCP. Его можно изменить, если вы хотите использовать один компьютер в качестве транслятора для доступа к программам другого.
• -geometry 1024x768 . Этот параметр устанавливает виртуальное разрешение сеанса VNC. Заметим, что это разрешение не обязательно должно соответствовать разрешению обычного X-сервера, работающего на компьютере сервера. Можно создать несколько записей, работающих с разным разрешением, чтобы пользователи могли входить в VNC-сервер с тем разрешением, которое удобно для их локальных систем.
• -depth 16 . Этот параметр задает глубину цвета. Чем ниже значение, тем быстрее обновляется дисплей, но на экране с большим количеством цветов могут появиться искажения. Диапазон допустимых значений от 2 до 32.

Имеются многие другие параметры, и некоторые из них зависят от VNC-сервера. Обращайтесь к документации по своему серверу VNC.

Настройка XDMCP-сервера

Большинство дистрибутивов Linux настраивают свои XDMCP-серверы только для управления локальным дисплеем. Чтобы обеспечить удаленный доступ, нужно перенастроить XDMCP-сервер так, чтобы принимать запросы на доступ с VNC-сервера, работающего на том же компьютере. Детали зависят от XDMCP-сервера. Три наиболее часто используемых в Linux ― это GNOME Display Manager (GDM), Light Display Manager (LightDM) и KDE Display Manager (KDM). Для других XDMCP-серверов, таких как XDM, требуются настройки, отличные от описанных здесь. В любом случае после перенастройки XDMCP-сервера его придется перезапустить.

Редактирование файла конфигурации XDMCP

Если вы не уверены, какой XDMCP-сервер используется в вашей системе, это можно определить, просмотрев листинг процесса с помощью строки dm , например:

В первой строке этой распечатки указано, что работает KDM, поэтому для того чтобы VNC мог использовать XDMCP, нужно отредактировать файл конфигурации этого сервера. Файлы конфигурации большинства программ XDMCP имеют один и тот же формат. Они содержат разделы с именами, указанными в квадратных скобках, например . Строки, следующие за именем раздела, задают параметры через знак равенства, например: enable=true . В таблице 1 перечислены имена файлов конфигурации, имена разделов и параметры, которые необходимо определить, чтобы XDMCP работал на нескольких распространенных XDMCP-серверах Linux.

Таблица 1. Параметры, позволяющие XDMCP поддерживать VNC для разных XDMCP-серверов

Раздел XDMCP в файле конфигурации может полностью отсутствовать. Если он присутствует, он может явно отключать поддержку XMDCP, содержать закомментированные параметры или быть пустым. Независимо от исходного состояния файла необходимо сделать так, чтобы раздел XDMCP присутствовал и чтобы поддержка была включена. В качестве примера рассмотрим настройку KDM для включения XDMCP:

Некоторые дистрибутивы позволяют включить дополнительные меры безопасности, которые потребуется ослабить. Одна из них ― межсетевой экран. Сценарии межсетевых экранов обычно зависят от дистрибутивов, поэтому за инструкциями по настройке межсетевого экрана обращайтесь к документации на свою систему. Нужно, чтобы localhost имел доступ к порту 177, а VNC-клиенты - к порту 5900 (или любым другим портам, которые используются для VNC).

В OpenSUSE есть дополнительный файл конфигурации, который управляет некоторыми типами доступа, включая XDMCP-доступ: /etc/sysconfig/displaymanager. Откройте этот файл в текстовом редакторе и найдите следующую строку:

Измените значение этого параметра на "yes" . Если оставить "no" , окно входа XDMCP-сервера при подключении к VNC-серверу отображаться не будет. В большинстве дистрибутивов такое изменение не требуется: этот файл использует только openSUSE.

Перезапуск XDMCP-сервера

Когда XDMCP-сервер настроен на поддержку удаленных соединений, его необходимо перезапустить. В дистрибутивах, которые запускают X посредством файла инициализации SysV, таких как Debian и Gentoo, это можно сделать с помощью параметра restart:

В системе, которая для запуска X использует уровень runlevel, такой как Fedora или openSUSE, нужно перейти на уровень текстового режима (обычно 3), а затем вернуться на уровень GUI (обычно 5):

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

Тестирование и отладка

Теперь можно входить в систему с удаленного компьютера с помощью VNC-клиента. Большинство дистрибутивов Linux содержат команду vncviewer , так что можно ввести:

Чтобы войти в систему remotename через VNC. Если VNC настроена и работает правильно, результат будет примерно таким, как показано на рисунке 4. Если настроить несколько сеансов VNC через разные порты, можно указать номер сеанса VNC, передав его как часть имени хоста. Введите:

Чтобы войти в сеанс 3 (через порт 5903).

Рисунок 4. При настройке на работу с XDMCP VNC обеспечивает обычное приглашение Linux

Если при выполнении этого теста вы не видите экран входа в систему XDMCP, придется произвести отладку. Ниже приведены некоторые рекомендации.

• Если vncviewer сообщает, что в соединении было отказано, это, скорее всего, означает, что суперсервер на компьютере сервера VNC не настроен должным образом. Проверьте конфигурацию xinetd и попробуйте перезапустить суперсервер. Возможно также, что межсетевой экран блокирует доступ к компьютеру VNC-сервера.
• Если VNC-клиент запускается и подключается к серверу, но вы видите только серый экран с курсором, который можно перемещать, проблема, скорее всего, в настройке XDMCP-сервера. Проверьте описанные выше параметры и перезапустите XDMCP-сервер.
• Просмотрите файлы журнала событий, как это обычно делается при отладке. Может потребоваться поиск всех файлов журнала в каталоге /var/log по ссылкам на ваши xinetd , XDMCP-сервер и VNC-сервер.

Вопросы безопасности VNC

RFB не является безопасным протоколом; большинство VNC-клиентов и серверов не шифруют свои данные. (VNC шифрует свои собственные пароли, но при описанном здесь подходе эти пароли не используются.) Будьте осторожны при выборе способа и места установки VNC. Если вы хотите использовать VNC в незащищенной сети, возможны три варианта:

• использовать виртуальную частную сеть (VPN);
• туннелировать протокол через SSH;
• использовать вариант VNC, поддерживающий шифрование, такой как TigerVNC с возможностью шифрования Transport Layer Security.

При включении окон входа VNC, как описано в этой статье, во внешний мир открываются, по крайней мере, два порта (VNC и XDMCP). Оба порта можно ограничить правилами межсетевого экрана, чтобы свести к минимуму риск злоупотреблений. Заметим, что порт XDMCP (UDP 177) должен быть открыт только для localhost, поэтому правило межсетевого экрана для него может быть весьма ограничивающим.

Заключение

В целом соединение VNC и XDMCP ― полезный метод обеспечения удаленного входа с графическим интерфейсом пользователя для многопользовательских Linux компьютеров. Этот метод имеет преимущества по сравнению с прямым применением XDMCP в кроссплатформенной среде или при наличии проблем, вызванных межсетевым экраном или NAT. На многопользовательских компьютерах он предпочтительнее более распространенных способов прямого подключения VNC. При использовании этого метода необходимо рассмотреть вопросы безопасности. Будьте готовы настроить правила межсетевого экрана для ограничения нежелательного доступа извне и используйте шифрование, если данные передаются по ненадежной сети.