Немного о дизайне VDI. Часть 10. Организация подключения и безопасность

10.1 Варианты подключения к виртуальным десктопам

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам:
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
...
Часть 6. Лицензирование VDI

Подключение к виртуальным десктопам может осуществляться одним из трех способов:

• Подключение через брокер или прокси-сервер с использованием механизма туннелирования сессионного трафика.
• Подключение через брокер или прокси-сервер без использования механизма туннелирования.
• Прямое подключение с клиентского устройства к виртуальному десктопу.

Первые два варианта требуют для своей работы функционирующего брокера подключений (в случае Horizon – View Connection Server), а при доступе из Интернет и пограничного сервера (View Security Server, Unified Access Gateway, либо стороннее устройство). Брокер является единой точкой подключения, выполняет аутентификацию пользователя и выдает перечень десктопов доступных для подключения. Дальнейшая схема различается в зависимости от того используется режим туннелирования или нет. При туннелировании трафика клиентское устройство устанавливает вторичное подключение к брокеру (или прокси-серверу), который, в свою очередь, подключается к десктопу. Весь трафик сессии от клиента до виртуального десктопа идет через брокер. Это позволяет легко реализовать сценарии подключения пользователей из сети Интернет, без необходимости использования VPN или настройки публичных IP-адресов для виртуальных десктопов.

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

Последний вариант (Direct connection agent) позволяет клиенту напрямую подключаться к десктопу без использования брокера. Данный режим в основном используется в небольших тестовых инсталляциях или при недоступности брокера.

Выбор протокола для подключения также влияет на архитектуру VDI. На текущий момент Horizon поддерживает следующие протоколы для подключения к виртуальным десктопам.

Функции	RDP	PCoIP	Blast (Extreme)	HTML5 (Blast)
Способ подключения	Клиент Horizon Client	Клиент Horizon Client	Клиент Horizon Client	Веб-браузер
Транспорт	TCP	UDP	TCP или UDP	TCP
Туннелирование через View Security Server, UAG	Да	Да	Да	Да
Возможность прямого подключения к десктопу	Да, (Direct connection agent или клиент RDP)	Да, (Direct connection agent)	Да, (Direct connection agent)	Да, View HTML Access)
Многомониторные конфигурации	Да	Да	Да	Да
Передача буфера обмена (Clipboard Redirection)	Да	Да	Да	Да
USB Redirection	Да	Да	Да	Нет
Serial Port Redirection	Нет	Да	Да	Нет
Virtual Printing / проброс принтера	Да	Да	Да	Нет
Воспроизведение звука	Да	Да	Да	Да
Проброс микрофона	Да	Да	Да	Да
Проброс сканеров	Нет	Да	Да	Нет
Проброс локальных дисков	Да	Да	Да	Нет
Flash Redirection	Нет	Да	Да	Нет
Поддержка Multimedia Redirection	Да	Да	Да	Нет
Поддержка RTAV	Нет	Да	Да	Да
Поддержка Skype for Business	Нет	Да	Да	Нет
Аппаратное кодирование протокола	Да, зависит от ОС	Да, Teradici PCoIP Hardware Accelerator	Да, графические адаптеры NVIDIA GRID/Tesla	Да, графические адаптеры NVIDIA GRID/Tesla
Аппаратное декодирование протокола	Да, зависит от клиента	Только на нулевых клиентах Teradici	Да, графические адаптеры	Только в веб-браузере Chrome, графические адаптеры
Поддержка Lossless режима	Да, зависит от ОС	Да	Да	Да

При выборе протокола следует учитывать, что поддержка многих функций зависит также от используемого клиентского устройства и версии ОС, установленной на виртуальном десктопе.

Протоколы PCoIP или Blast являются более оптимальным выбором, поскольку помимо более широких функциональных возможностей, обеспечивают лучшее качество изображения, меньшие задержки и утилизацию канала, чем RDP, хотя большую роль здесь играет версия ОС (Windows 10 обеспечивает гораздо лучшие показатели сжатия и качества в сравнении с Windows 7 или Windows 8: https://cloudblogs.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview/).

HTML5 клиент может применяться в качестве вспомогательного варианта, в тех случаях, когда пользователь подключается с специализированных клиентских устройств и не имеет возможности установить полнофункциональный клиент Horizon Client. Несмотря на свою "платформонезависимость", ряд функций, такие как аппаратное декодирование и многомониторные конфигурации поддерживаются только для браузера Google Chrome.

Еще один немаловажный показатель – это приспособленность протокола к работе на нестабильных, медленных каналах. Согласно документу Blast Extreme Display Protocol in Horizon 7 (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-view-blast-extreme-display-protocol.pdf) протокол PCoIP способен работать на каналах с потерями пакетов, достигающих 15%, в то время как Blast может «пережить» до 20% потерь.

Последний фактор – это простота публикации протокола на межсетевых экранах. Лидером здесь является RDP, поскольку для его работы при использовании режима туннелирования требуется открыть только один порт – TCP 443. Для Blast помимо TCP 443 требуется открыть TCP 8443 и опционально UDP 8443, хотя в случае использования Unified Access Gateway есть возможность туннелирования трафика только через TCP 443. Для PCoIP помимо TCP 443 требуется открыть доступ по портам TCP 4172 и UDP 4172. В большинстве случаев, когда не работает подключение по PCoIP, и пользователь видит перед собой черный экран, это означает, что администраторы забыли открыть доступ по порту UDP 4172.

10.2 Клиентские устройства

Выбор протокола связан с используемыми клиентскими устройствами. Horizon поддерживает следующие типы клиентских устройств:

• Стационарные компьютеры и ноутбуки с ОС Windows, MAC OS X, Linux или Chrome OS.
• Тонкие клиенты под управлением Windows Embedded / IoT, Linux или иных ОС, например, тонкие клиенты Dell Wyse, HP, Lenovo, Atrust, Igel, Fujitsu и других производителей.
• Нулевые клиенты с аппаратной поддержкой PCoIP на базе чипов Teradici.
• Мобильные устройства – планшеты и смартфоны с ОС iOS, Android, Windows Phone.
• Устройства, оснащенные HTML5 совместимым браузером.

Критериями выбора клиентского устройства (помимо стоимости) являются: производительность, функциональные возможности, удобство эксплуатации, надежность и защищенность.

Производительность тонкого клиента напрямую влияет на частоту прорисовки и качество изображения, а, следовательно, на удобство и комфорт работы пользователя. В большинстве случаев производительности процессоров уровня Core i3 или Pentium достаточно для обеспечения работы в большинстве приложений, а вот процессоры Intel Atom или AMD G-series, не говоря уже о процессорах с архитектурой ARM, могут не справиться с обработкой изображения в высоком разрешении с частой перерисовкой экрана (воспроизведение видео, работа графикой, многомониторные конфигурации).

Решить проблему с недостаточно производительными процессорами позволяют тонкие клиенты, поддерживающие VMware Blast. Данный протокол использует кодек H.264 и для декодирования изображения может задействовать графический адаптер клиентского устройства, тем самым снижая нагрузку на процессор и ускоряя процесс обработки изображения, что позволяет обеспечивать приемлемый уровень производительности даже на ТК начального уровня. На текущий момент далеко не все клиенты, поддерживающие VMware Blast, поддерживают аппаратное декодирование (например, ТК Dell Wyse с ОС ThinOS версии 8.4.110 и ниже), кроме того следует помнить о некоторых нюансах работы (http://blog.vmpress.org/2017/05/vmware-blast-h264.html).

Альтернативой ТК с аппаратной поддержкой Blast являются нулевые клиенты на базе процессоров Teradici (TERA2 2321 и 2220). Данные ТК обеспечивают высокий уровень производительности, сопоставимый со стационарными компьютерами, экономичны, просты в настройке и эксплуатации, однако из-за ограничений Teradici OS не поддерживают многие функции Horizon.

Если говорить о функциональных возможностях, то здесь лидерами являются компьютеры с ОС Windows и клиентами Horizon Client. Версии Horizon Client под MAC OS X или Linux не поддерживают проброс сканеров или последовательных портов, а у нулевых клиентов Teradici также отсутствует поддержка протоколов RDP и Blast, функций Flash Redirection, MMR, RTAV, Virtual Printing и пр.

Linux является крайне популярной ОС для установки на тонкие клиенты (у каждого производителя найдется пара-другая моделей ТК с Linux). Некоторые вендоры предоставляют оптимизированную версию ОС Linux, которая может быть установлена на существующие компьютеры, превращая их в ТК. Среди популярных решений можно отметить:

• Thinstation.
• Dell Wyse PC Extender.
• Igel Universal Desktop Converter.
• Stratodesk NoTouch Desktop.

Важный нюанс, хотя большинство современных тонких клиентов с Linux базируются на процессорах с архитектурой Intel x86, до сих пор остается некоторое количество устаревших моделей на базе процессоров ARM. Horizon Client для ARM процессоров имеет функциональные ограничения (отсутствие RTAV и Flash URL Redirection) по сравнению с Horizon Client для Linux на x86 процессорах. Клиенты для платформ iOS, Android, Windows Phone и HTML5 клиент функционально крайне ограничены, однако представляют интерес благодаря мобильности, имея доступ к Интернет, пользователь всегда может подключиться к своему виртуальному десктопу.

Пару слов следует сказать о ТК Dell Wyse с ОС ThinOS. Данные клиенты интересны как альтернатива нулевым клиентам благодаря простоте настройки, поддержке нескольких брокеров и протоколов подключения, небольшому размеру образа ОС и возможности установки дополнительных пакетов. Функционально ТК с ThinOS находятся где-то между нулевыми клиентами и клиентами под ОС Linux.

Большинство моделей ТК также обладают возможностью централизованной настройки и обновления при помощи сервера управления (Dell Wyse Device Manager или Wyse Management Suite, HP Device Manager, Atrust Device Manager, PCoIP Management Console и другие). ТК с ОС Windows могут также управляться стандартными инструментами вроде групповых политик или Microsoft SCCM.

При выборе модели следует учитывать политику производителя в отношении выпуска обновлений. Некоторые производители требуют действующей поддержки или приобретения подписки для получения доступа к обновлениям прошивок ТК.

Что касается безопасности, на ТК с ThinOS и нулевых клиентах Teradici у пользователей отсутствует доступ к файловой системе, поддерживается экспорт логов на внешнее хранилище или сервер управления, а также имеется разграничение пользовательского и административного режима. На многих Windows и Linux ТК может быть активирован режим защиты от записи, который позволяет после перезагрузки автоматически откатывает все изменения, сделанные на ТК. Такой режим помимо повышения безопасности может усложнить установку дополнительных приложений и обновлений на ТК, т.к. потребует предварительного отключения защиты. Показателен размер установочного образа ОС (прошивки) для ТК разных типов:

• Нулевой клиент Teradici: 5 – 10 МБ.
• Тонкий клиент с ThinOS: 20 – 30 МБ.
• Тонкий клиент с Linux: 600 – 1200 МБ.
• Тонкий клиент с Windows: 2 – 8 ГБ.

В таблице представлено сравнение функциональных возможностей клиентов по платформам. В качестве специализированных клиентских устройств рассматриваются только нулевые клиенты Teradici и ТК Dell Wyse с ОС Thin OS. Большинство оставшихся ТК на рынке в качестве ОС используют ОС Windows или Linux.

Ознакомиться со всеми функциональными возможностями клиентов под различные платформы можно на странице документации по клиентам (https://www.vmware.com/support/viewclients/doc/viewclients_pubs.html).

10.3 Удаленный доступ

Для организации удаленного доступа используются пограничные серверы, в качестве которых могут выступать VMware Security Server, VMware Unified Access Gateway (UAG) или решения от сторонних производителей (F5 Big-IP, Citrix Netscaler Gateway и др.).

Основные отличия Security Server от UAG приведены в таблице:

Описание	Security Server	Unified Access Gateway
Тип установки	На Windows Server 2008 R2 и выше	Linux Virtual Appliance
Интеграция с View Connection Server	1 к 1 Один Security Server связывается (pairing) только с одним Connection Server, использование балансировщика между security server и connection server не поддерживается	Многие к 1 или многие ко многим К одному и тому же Connection Server могут подключаться несколько UAG. При балансировании Connection Server несколько UAG могут подключаться к нескольким Connection Server
Порты/протоколы для интеграции с Connection Server	IPSEC при использовании режима (IPSec security) или TCP 4001, TCP 4002 и т.д.	HTTPS (TCP 443)
Поддерживаемые функции	MMR USB Redirection Two-factor Authentication (RSA SecurID или Radius) Smart-Card Authentification USB Redirection	MMR USB Redirection Two-factor Authentication (RSA SecurID или Radius) Smart-Card Authentification USB Redirection
Настройки	Настройки туннелирования и аутентификации задаются на уровне парного Connection Server	Настройки туннелирования и аутентификация задаются на уровне UAG
Максимумы	Максимальное кол-во одновременных подключений: 2000	​• PCoIP Sessions = 2,000 • Blast Extreme Sessions – UDP = 1,000 • Blast Extreme Sessions – TCP = 2,000

Основное отличие Security Server от UAG заключается в том, что UAG представляет собой предустановленный виртуальный апплайнс на базе ОС Linux и не требует лицензии Windows.

UAG гораздо проще в установке и настройке, он использует только HTTPS протокол для интеграции с Connection Server и не требует открытия большого кол-ва портов между Security Server и Connection Server.

Security Server поддерживает режим развертывания по схеме 1 к 1, для каждого Connection Server’а создается один парный Security Server, варианты, когда к одному Connection Server’у подключаются два Security Server или, наоборот, когда один Security Server подключается к двум Connection, не поддерживается. Для обеспечения безопасности передаваемых данных между Security Server и Connection Server может быть настроен IPSec.

Использование Security Server’ов на больших инсталляциях связано с определенными ограничениями в случаях, когда вам необходимо сделать разные настройки туннелирования и аутентификации для разных пользователей, подключающихся из внутренних и внешних сетей. Например, вы хотите, чтобы для внутренних пользователей аутентификация по смарт-картам была опциональна и не использовалось туннелирование, а для внешних пользователей использовалось туннелирование и была бы обязательна аутентификация по смарт-картам или SAML аутентификация при интеграции с Identity Manager (…и еще там тэги разные для разных пулов и Connection Server’ов).

Так как данные настройки задаются на парном Connection Server и не могут быть переопределены на Security Server, все варианты комбинаций не получится задать в рамках одного POD’а и обеспечить при этом отказоустойчивость подключений.

UAG поддерживает больше сценариев развертывания по сравнению с Security Server, помимо варианта один Connection Server – один UAG, несколько UAG могут подключаться к одному и тому же Connection Server, или один UAG может подключаться к нескольким Connection Server через балансировщик нагрузки.

Также UAG позволяет настроить проксирование трафика BLAST Extreme через единый порт (TCP 443), в отличие от Security Server, который требует открыть и TCP 443, и TCP 8443. Помимо предоставления доступа к VDI инфраструктуре Horizon, UAG также может использоваться для публикации Identity Manager и AirWatch, и все через один IP адрес.

Решения от сторонних производителей (Citrix и F5) предоставляют функции PCoIP Proxy сервера и могут заменить собой Security Server или UAG. Кроме проксирования PCoIP трафика, сторонние решения также могут осуществлять балансирование нагрузки, выступать в качестве серверов публикации приложений, выполнять SSL Offload и т.д.

Обычно серверы Security Server или UAG размещаются в DMZ сети, однако следует помнить, что клиент устанавливает туннелированное подключение через Security Server/UAG, минуя Connection Server, соответственно, между ними и виртуальными десктопами должна быть настроена маршрутизация трафика и открыт доступ по соответствующим протоколам.

Более подробно о портах и протоколах, необходимых для работы Horizon, вы можете узнать из документа: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-7-end-user-computing-network-ports.pdf.

10.4 Балансирование нагрузки

Настройка балансировщика подключений между несколькими Connection Server или пограничными серверами преследует собой две цели:

• Распределение нагрузки в больших инсталляциях, когда производительности одного сервера недостаточно.
• Обеспечение отказоустойчивости на случай выхода из строя одного из серверов.

Конечно, всегда есть вариант сообщить пользователям адреса нескольких Connection Server или пограничных серверов и выдать простую инструкцию вида: "–Если не удается подключиться к одному серверу, попробуйте подключиться к другому.", однако такой вариант с ручным переключением подходит только для небольших инсталляций и для терпеливых пользователей.

Самым простым в настройке вариантом балансировки является DNS Round Robin. Для каждого IP-адреса сервера Connection Server (или пограничного сервера) создается A-запись с одним и тем же именем (например, vdi.company.local), которое используется клиентами для подключения. При запросе клиентом адреса у DNS сервера, сервер возвращает список IP адресов. Для каждого запроса порядок адресов меняется, таким образом, один клиент подключиться к серверу Connection Server, который в списке адресов находится на первом месте, второй клиент подключится ко второму серверу, и так далее. DNS Round Robin позволяет равномерно распределить входящие подключения по серверам, однако имеет несколько недостатков. Во-первых, DNS Round Robin не выполняет проверку доступности серверов, поэтому при отказе сервера продолжает возвращать список, включающий его IP адрес, что может привести к тому, что клиент предпримет попытку подключиться к нерабочему серверу.

Во-вторых, отсутствие persistence, одному и тому же клиенту, при каждом запросе выдается список, в котором меняется порядок IP-адресов, из-за чего могут возникать различные проблемы с подключением.

В-третьих, при использовании DNS Round Robin не отслеживается количество активных подключений к каждому серверу и уровень его загрузки.

Другой вариант предполагает использование балансировщика сетевой нагрузки: встроенного (Windows Network Load Balancer), либо внешних (Citrix NetScaler, F5 BIG-IP, KEMP Loadmaster, NSX Edge, HAProxy и др.). Среди преимущества использования внешних балансировщиков:

• Упрощение сетевой конфигурации серверов View Connection Server по сравнению с NLB.
• Поддержка различных алгоритмов балансировки (failover, round-robin, балансировка по числу активных соединений, балансирование по загрузке серверов).
• Проверка здоровья балансируемого сервиса (health check).
• SSL offloading – позволяет выполнять шифрование соединения только на стороне клиента-балансировщика, и передавать трафик между балансировщиком и Connection Server в незашифрованном виде, что снижает нагрузку на серверы View.
• Глобальная балансировка (Global Load Balancing) для территориально-распределенных инсталляций VMware Horizon.

Для Horizon внешние балансировщики могут быть настроены в одном из двух режимов:

• Балансирование только первоначального HTTPS соединения.
• Балансирование всего трафика (включая PCoIP или Blast).

Балансирование только служебного трафика создает существенно меньшую нагрузку на балансировщики, но требует прямого доступа с клиентов до Connection Server или пограничных серверов по протоколам PCoIP / Blast, что потребует дополнительных IP-адресов в случае публикации из Интернет и настройки межсетевого экрана. Первичное соединение по HTTPS выполняется через балансировщик (например, balancer.company.local), который перенаправляет трафик на один из Connection Server. После выбора десктопа клиент устанавливает туннелированное подключение с соответствующим сервером View Connection или пограничным сервером (например, view01.company.local).

В случае балансирования всего трафика через балансировщик идет не только служебный трафик, но также трафик удаленной сессии PCoIP/Blast. Это приводит к большей нагрузке на балансировщик, а также требует настройки дополнительных правил балансирования для сессионного трафика (по портам TCP/UDP 4172 для PCoIP, и TCP/UDP 8443/443 для Blast, зато позволит упростит публикацию из Интернет, т.к. публичный IP адрес потребуется только для балансировщика. Кроме того, при использовании балансировщика с функциями L7 (application) firewall, такое устройство может использоваться для защиты серверов View от различных сетевых атак.

Если вы планируете балансировать весь траффик, а не только первоначальное подключение по HTTPS, то на балансировщиках требуется включить sticky sessions/affinity, чтобы трафик PCoIP/Blast перенаправлялся на тот же Connection Server, через который было установлено первоначальное соединение.

Еще одна важная функция, которую предоставляют внешние балансировщики, это проверка здоровья балансируемого сервиса (health check). Балансировщик периодически выполняет подключение к балансируемому серверу для проверки его состояния. В случае если проверка завершается неудачно, балансировщик может временно исключить сервер из списка и перенаправлять подключения на оставшиеся серверы. Для HTTPS трафика предпочтительно использовать проверку здоровья на уровне приложения. Например, при публикации Connection Server балансировщик может выполнять проверку здоровья путем выполнения HTTP GET запроса для получения файла иконки сайта ("/favicon.ico"). Этот вариант позволит избежать у пользователей проблем с подключением, возникающих при использовании менее строгих вариантов проверки здоровья, например, при помощи ping’а или telnet’а на определенный порт.

Если к VDI инфраструктуре не предъявляются повышенные требования к безопасности, и нет необходимости использования application firewall на балансировщике, то вариант с балансированием только HTTPS является предпочтительным. Для балансирования HTTPS трафика будет достаточно балансировщика начального уровня, это позволит снизить затраты на развертывание (многие балансировщики лицензируются по функциональным возможностям и пиковой полосе пропускания).

10.5 Двухфакторная аутентификация

Двухфакторная аутентификация предоставляет дополнительный уровень защиты при подключении и позволяет снизить риски при утечке или подборе логина и пароля учетных записей пользователей. Horizon поддерживает следующие механизмы двухфакторной аутентификации:

• RSA SecurID
• RADIUS
• Смарт-карты

Аутентификация RSA SecurID работает в связке с RSA Authentication Manager и требует наличия у пользователя программного или аппаратного генератора временных паролей SecurID. При подключении к Connection Server у пользователя будет запрошен логин и временный пароль, и в случае успешной аутентификации на RSA пользователю потребуется ввести логин и пароль своей учетной записи (второй фактор).

При интеграции Horizon с VMware Identity Manager и настройке SAML аутентификации может быть задействован механизм True SSO, позволяющий избавиться от необходимости ввода логина и пароля при аутентификации через RSA SecurID на портале Identity Manager.

Принцип работы механизма True SSO основан на генерировании и использовании одноразовых цифровых сертификатов пользователей. В инфраструктуре развертывается дополнительный сервер Horizon Enrollment Server, который отвечает за запрос сертификатов от имени пользователя и передачу сертификата серверу View для дальнейшей аутентификации пользователей.

Интеграция Horizon с RADIUS серверами позволяет обеспечить работу различных механизмов двухфакторной аутентификации, например, JaCarta Authentication Server – аналог RSA SecurID.

При аутентификации при помощи смарт-карт пользователь предоставляет сертификат (первый фактор) и пин-код для доступа к сертификату, хранящемуся на смарт-карте (второй фактор), при этом пользователю не требуется вводить логин и пароль учетной записи при входе на виртуальный десктоп благодаря использованию сквозной аутентификации.

Поскольку двухфакторная аутентификация настраивается на уровне отдельных Connection Server, то для реализации разных способов аутентификации для различных категорий пользователей (например, для обычных и защищенных пользователей) требуется развернуть несколько экземпляров Connection Server и настроить несколько адресов для подключения.

Продолжение доступно по ссылкам:
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление