Запуск удалённых приложений, часть 3

XDMCP является довольно древним методом, SSH — защищённым, однако наиболее полно интегрированным в окружение рабочего стола методом является Virtual Network Computing (VNC). В основе VNC лежит протокол Remote Frame Buffer, разработанныйOlivetti Research Labs и доступный к реализации всем желающим. Этот протокол не основан на X11, он находится на нижнем уровне слоя Infrastructure (см. Запуск удалённых приложений, часть 1). Благодаря этому программное обеспечение VNC может позволить себе быть платформо-независимым и успешно работать под Linux, Windows иMac OS/X. Иными словами, вы можете с успехом получить доступ к удалённому рабочему столу Linux-хоста, например, из-под Mac OS/X.

По существу, VNC — это лишь определение протокола, то есть он описывает что и как должно работать. Для Linux существует большое количество реализаций. Клиентом в реализации VNC называется приложение, предназначенное для просмотра удалённого рабочего стола. Одной из реализаций VNC с открытым исходным кодом являетсяTigerVNC — ответвление от популярной TightVNC. TigerVNC включает в себя клиент и сервер и создан с целью увеличить активность разработчиков проекта.

Пользователи GNOME обнаружат у себя Vino в качестве VNC-сервера по умолчанию, аVinagre — VNC клиентом. Оба приложения тесно интегрированы в GNOME, и вы без труда должны найти их в стандартом меню приложений.

Конфигурирование VNC

В отличие от XDMCP/GDM и SSH, VNC не предназначен для отображения экранов удалённых приложений локально, а создан для того, чтобы пользователь мог удалённо просматривать и управлять содержимым всего рабочего стола. Таким образом, рабочий стол удалённой системы должен быть доступен к тому моменту, когда выполняется подключение к серверу VNC. К тому же, VNC обычно не может быть использован для работы с headless-системами, хотя пакет xvnc может решить и эту задачу. Xvnc предоставляет удалённый «виртуальный» X-сервер, к которому можно подключиться с помощью VNC-клиента. Поскольку удалённый рабочий стол является виртуальным, то имеется возможность организовать множественные подключения к дополнительным рабочим столам на удалённой системе, при чём все рабочие столы могут иметь различное разрешение.

Прежде, чем можно будет подключиться к VNC-серверу, он должен быть запущен на удалённой системе. В GNOME это можно сделать, выбрав опцию стандартного менюSystem→Preferences→Remote Desktop. В окне конфигурации необходимо включить опцию удалённого рабочего стола, выбрать параметры безопасности и метод уведомления о входящих подключениях:

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

В случае, если ваша система, в которой вы настраиваете VNC-сервер, находится в домашней сети, то в разделе Security обязательным для определения является лишь пароль. В Vino и TigerVNC этот пароль не шифруется! Имейте это ввиду, когда будете подключаться к вашей системе из-за пределов сети. Если вы отметите опцию «You must confirm each access to this machine», то прежде, чем удалённый пользователь получит доступ к локальному рабочему столу, необходимо будет подтвердить. Сделать это возможно будет, естественно, только находясь физически перед локальным рабочим столом. В домашней сети это, обычно, не имеет смысла.

При настройке уведомлений (Notification Area) лучше оставить ту опцию, которая изображена на снимке экрана выше. Дело в том, что иногда может случиться так, что вы можете забыть отключиться от вашей локальной системы с удалённого рабочего стола, а кто-то не упустит шанса воспользоваться этим. Но при наличии иконки в области уведомлений будет хоть какая-то вероятность заметить это.

Со удалённой стороны VNC-клиент в GNOME запускается из менюApplications→Internet→Remote Desktop Viewer. Vinagre выглядит как обычное приложение:

Также, при помощи Vinagre можно одновременно устанавливать несколько подключений к различным удалённым рабочим столам, переключаясь между ними, используя вкладки боковой панели.

VNC: «многоголовость» из двух компьютеров

Одной из «фишек» использования VNC является «подключение» локальных клавиатуры и мыши к удалённому рабочему столу. При помощи этого можно эмулировать «многоголовую» систему, то есть, когда один экран разделяется между двумя мониторами. Используя x2vnc, можно сделать так, чтобы экран локального компьютера выступал в роли первого монитора, а экран удалённого — в кастве второго. Перемещая указатель мыши за правый край локального монитора, вы оказываетесь на экране второго, удалённого компьютера. Таким хитрым способом вы можете, например, управлять MythTV-клиентом с вашего лэптопа, не прибегая к использованию ИК-пульта дистанционного управления. Формат команды запускаx2vnc таков:

x2vnc <remote host> -east (or -west, -north, -south)

Опция -east настраивает расположение удалённого экрана справа от локального. Если хотите наоборот — используйте опцию -west, сверху — -north, снизу — -south.

Расширения VNC предоставляют различные опции сжатия и безопасности. Однако, чтобы ими пользоваться, расширения должны быть по обе стороны соединения. Если, например, на сервере у вас установлено какое-то расширение, но клиент их не поддерживает, то воспользоваться возможностями расширения не получится и VNC будет работать в «стандартном» режиме.

VNC: «за» и «против»

«За»:

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

«Против»:

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

Производительность

С точки зрения нагрузки на канал передачи данных, использование SSH является наиболее производительным методом из всех трёх описанных. GDM-соединения в этом отношении ведут себя примерно так же, хотя многое зависит от методов сжатия трафика, используемых при SSH и GDM-подключениях.

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

Безопасность

XDMCP использует порт 177, а X-сервер использует порт, начиная с номера 6000, плюс номер экрана. XDMCP восприимчив к DoS-атакам. GDM располагает некоторыми опциями, при помощи которых можно изменить эту ситуацию, тем не менее, XDMCP должен рассматриваться, как небезопасный. Таким образом, XDMCP и GDM должны быть закрыты сетевым экраном от внешнего мира и не должны использоваться через Интернет.

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

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

Выбор подходящего метода

Ни один из рассмотренных методов не позволяет воспроизводить медиафайлы, будь то музыка или видеоклипы. Я говорил, что можно управлять медиа-серверами удалённо, и я не отказываюсь от своих слов. Управление такими серверами заключается лишь в запуске/остановке сервисов и выполнении каких-то иных административных задач, которые легко решаются, используя любой из рассмотренных методов удалённого запуска приложений. Однако использовать сервисы, предоставляемые медиа-серверами, лучше всего при помощи предназначенных для этого приложений, запускаемых локально.

Пользователям «домашних» сетей, находящихся за правильно настроенным сетевым экраном, VNC предлагает наиболее функциональный и простой в настройке метод удалённого управления приложениями. Некоторым пользователям лучше подойдёт вариант использования форвардинга X-протокола через SSH. XDMCP/GDM я бы рекомендовал использовать в последнюю очередь, поскольку зачастую VNC и SSH могут целиком удовлетворить потребности пользователя, делая это быстрее и безопаснее. ОднакоXDMCP/GDM остаётся единственным методом, при помощи которого можно запускать новую X-сессию на удалённой машине.