Virtual Network Computing

Virtual Network Computing (VNC) — система удалённого доступа к рабочему столу компьютера, использующая протокол RFB (англ. Remote FrameBuffer, удалённый кадровый буфер). Управление осуществляется путём передачи нажатий клавиш на клавиатуре и движений мыши с одного компьютера на другой и ретрансляции содержимого экрана через компьютерную сеть.

Система VNC платформонезависима: VNC-клиент, называемый VNC viewer, запущенный на одной операционной системе, может подключаться к VNC-серверу, работающему на любой другой ОС. Существуют реализации клиентской и серверной части практически для всех операционных систем, в том числе и для Java (включая мобильную платформу J2ME). К одному VNC-серверу одновременно могут подключаться множественные клиенты. Наиболее популярные способы использования VNC — удалённая техническая поддержка и доступ к рабочему компьютеру из дома.

История

VNC была создана в Olivetti & Oracle Research Lab, которая в то время принадлежала Olivetti и Oracle Corporation. В 1999 году лаборатория была приобретена компанией AT&T, которая закрыла отдел разработок в 2002 году. Оригинальные исходные коды доступны на условиях лицензии GPL, как и многие варианты VNC, существующие на данный момент.

Название возникло из компьютерной сети тонких клиентов Videotile, которая представляла из себя ЖК-дисплей с вводом пером и быстрым ATM-подключением к сети. По существу, VNC — программная реализация «ATM Network Computer».

Разработчики, работавшие над VNC в AT&T Research Lab:

• Tristan Richardson
• Квентин Стаффорд-Фрейзер (англ.)
• James Weatherall
• Ken Wood
• Энди Хоппер (англ.)
• Charlie McLachlan
• Paul Webster

Устройство

VNC состоит из двух частей: клиента и сервера. Сервер — программа, предоставляющая доступ к экрану компьютера, на котором она запущена. Клиент (или viewer) — программа, получающая изображение экрана с сервера и взаимодействующая с ним по протоколу RFB.

Протокол RFB

RFB (англ. remote framebuffer) — простой клиент-серверный сетевой протокол прикладного уровня для удалённого доступа к графическому рабочему столу компьютера, используемый в VNC. Так как он работает на уровне кадрового буфера, то его можно применять для графических оконных систем, например X Window System, Windows, Quartz Compositor.

В начале своего развития RFB был относительно простым протоколом, основанным на графических примитивах: «положить прямоугольник пиксельных данных на заданную координатами позицию». Сервер посылает небольшие прямоугольники клиенту. Такая схема в своей примитивной форме потребляет значительный трафик. Для снижения нагрузки на канал используются различные методы. Существуют различные кодировки — методы определения наиболее эффективного способа передачи этих прямоугольников. Протокол RFB позволяет клиенту и серверу «договориться» о том, какая кодировка будет использована. Самый простой метод кодирования, поддерживаемый всеми клиентами и серверами — «raw encoding» (рус. сырое кодирование), при котором пиксели передаются в порядке слева-направо, сверху-вниз, и после передачи первоначального состояния экрана передаются только изменившиеся пиксели. Этот метод работает очень хорошо при незначительных изменениях изображения на экране (движения указателя мыши по рабочему столу, набор текста под курсором), но загрузка канала становится очень высокой при одновременном изменении большого количества пикселей, например, при просмотре видео в полноэкранном режиме. За время своего развития протокол оброс различными дополнительными функциями и опциями, такими как передача файлов, сжатие, безопасность.

По умолчанию RFB использует диапазон TCP-портов с 5900 до 5906. Каждый порт представляет собой соответствующий экран X-сервера (порты с 5900 по 5906 ассоциированы с экранами с :0 по :6). Java-клиенты, доступные во многих реализациях, использующих встроенный веб-сервер для этой цели, например, в RealVNC, связаны с экранами таким же образом, но на диапазоне портов с 5800 до 5806. Многие компьютеры под управлением ОС Windows могут использовать лишь один порт из-за отсутствия многопользовательских свойств, присущих UNIX-системам. Для Windows-систем экран по умолчанию — :0, что соответствует порту 5900.

Также существует возможность обратного подключения от сервера к клиенту. В этом случае клиент переводится в слушающий (англ. listening) режим и соединение инициируется сервером на 5500 TCP-порт клиента.

Порты могут быть изменены.

Методы кодирования и расширения, опубликованные из проекта TigerVNC:

0x00000000 — Сырой (Raw) 0x00000001 — Копирование прямоугольников (CopyRect) 0x00000002 — Увеличение прямоугольника (Rising Rectangle) 0x00000004 — CoRRE (Compact Rising Rectangle) 0x00000005 — Hextile 0x00000006 — Сжатие Zlib 0x00000007 — Версия клиента Tight 0x00000008 — ZlibHex 0x00000009 — Версия клиента Ultra 0x00000010 — Сжатие ZRLE 0x00000011 — Сжатие ZYWRLE (ZLib YUV Wavelet Run Length Encoding) 0xFFFF0001 — Флаг кэширования (CacheEnable)

0xFFFF0006 — Флаг побитового XOR (XOREnable) 0xFFFF8000 — ServerState (UltraVNC) 0xFFFF8001 — EnableKeepAlive (UltraVNC) 0xFFFF8002 — Передача файлов (FTProtocolVersion — UltraVNC) 0xFFFFFF00 — 0xFFFFFF09 — CompressLevel (Tight) 0xFFFFFF10 — XCursor 0xFFFFFF11 — RichCursor 0xFFFFFF18 — PointerPos 0xFFFFFF20 — LastRect 0xFFFFFF21 — NewFBSize 0xFFFFFFE0 — 0xFFFFFFE9 — QualityLevel (Tight)

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

Изначально VNC не использует шифрование трафика, однако в процедуре аутентификации пароль не передается в открытом виде, а используется алгоритм «вызов-ответ» с DES-шифрованием (эффективная длина ключа составляет 56-бит). Во многих реализациях существует ограничение в 8 символов на длину пароля и если его длина превосходит 8 символов, то пароль урезается, а лишние символы игнорируются.

При необходимости надежного шифрования всей VNC-сессии, она может быть установлена через SSL, SSH или VPN-туннель, а также поверх IPsec. Технология IPsec поддерживается подавляющим большинством современных ОС и используется как при соединении через Интернет, так и в локальных сетях. SSH-клиенты позволяют создавать SSH-туннели как со всех основных платформ (UNIX, Windows, Macintosh и др.), так и для менее популярных.

Также многие современные версии VNC поддерживают расширения стандартного протокола, которые реализуют шифрование и/или сжатие VNC-трафика, разграничения по спискам доступа ACL и различные методы аутентификации.

EchoVNC использует OpenSSL для шифрования соединений, причем шифруется сессия VNC, включая аутентификацию и передачу данных. Также поддерживает передачу файлов и чат. Если клиент не поддерживает OpenSSL шифрование, то шифрование автоматически отключается.

UltraVNC позволяет использовать специальный плагин, распространяемый с открытым исходным кодом, который шифрует всю сессию VNC используя алгоритмы AES или RC4, включая аутентификацию и передачу данных. Также существуют варианты аутентификации на основе NTLM и учётных записей пользователей в Active Directory. UltraVNC позволяет передавать файлы между сервером и клиентом в любых направлениях.

RealVNC в коммерческой версии продукта использует алгоритм AES для шифрования соединения и алгоритм RSA для аутентификации.

Workspot выпустила патч для VNC, реализующий алгоритм шифрования AES.

См. также

• UltraVNC
• TightVNC
• Программы удалённого администрирования
• Remote Desktop Protocol

Литература

• Tristan Richardson, Quentin Stafford-Fraser, Kenneth R. Wood & Andy Hopper. Virtual Network Computing IEEE Internet Computing, Vol.2, No.1, Jan/Feb 1998. P. 33-38

Ссылки

• RealVNC (англ.) — официальная версия, поддерживаемая командой AT&T Laboratories
• Стандарт протокола RFB 3.8

Для улучшения этой статьи желательно?: Проставить шаблон-карточку, который существует для предмета статьи. Пример использования шаблона есть в статьях на похожую тематику. Проставив сноски, внести более точные указания на источники.