Виртуальные столы для линукс

Виртуальный рабочий стол Linux с использованием Citrix

Этот пример сценария применим к любой отрасли, для которой требуется инфраструктура виртуальных рабочих столов (VDI) для рабочих столов Linux. VDI — это процесс запуска рабочего стола пользователя в виртуальной машине, что на сервере центра данных. В этом сценарии клиент решил использовать для своих потребностей VDI решение на основе Citrix.

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

Ниже приведены некоторые преимущества такого сценария.

• С использованием общих виртуальных рабочих столов Linux рентабельность инвестиций будет выше, так как к одной и той же инфраструктуре будет предоставлен доступ большему количеству пользователей. Благодаря объединению ресурсов в централизованной среде VDI нет потребности в более мощных устройствах пользователя.
• Производительность будет согласованной независимо от устройства пользователя.
• Пользователи могут получить доступ к приложениям Linux с любого устройства (включая устройства не на ОС Linux).
• Конфиденциальные данные могут быть защищены в центре обработки данных Azure для всех распределенных сотрудников.

Варианты соответствующего использования

Рассмотрите этот сценарий для следующих вариантов использования:

• Обеспечение безопасного доступа к критически важным специализированным рабочим столам Linux VDI на устройствах с Linux или другой ОС

Architecture

Этот пример сценария демонстрирует возможность доступа корпоративной сети к виртуальным рабочим столам Linux:

• Между локальной средой и Azure устанавливается ExpressRoute для обеспечения быстрой и надежной связи с облаком.
• Решение Citrix XenDesktop развернуто для VDI.
• CitrixVDA работает на Ubuntu (или другом поддерживаемом дистрибутиве).
• Группы безопасности сети Azure будут применять правильные сетевые списки управления доступом.
• Citrix ADC (NetScaler) опубликует и загрузит все службы Citrix.
• Доменные службы Active Directory будут использоваться для присоединения к домену серверов Citrix. Серверы VDA не будут присоединены к домену.
• Синхронизация гибридных файлов Azure позволит совместное хранилище через решение. Например, это может использоваться в удаленных или домашних решениях.

В рамках данного сценария используются следующие номера SKU:

• Citrix ADC (NetScaler): 2 x D4sv3 с NetScaler 12.0 VPX Standard Edition 200 MBPS PAYG image
• Сервер лицензирования Citrix: 1 x D2s v3
• Citrix VDA: 4 x D8s v3
• Онлайн-магазин Citrix: 2 x D2s v3
• Контроллер доставки Citrix: 2 x D2s v3
• Контроллеры домена: 2 x D2sv3
• Файловые серверы Azure: 2 x D2sv3

Все лицензии (кроме NetScaler) с использованием собственной лицензии (BYOL)

Компоненты

• Виртуальная сеть Azure позволяет таким ресурсам, как виртуальные машины, безопасно взаимодействовать друг с другом, Интернетом и локальными сетями. Виртуальные сети обеспечивают изоляцию и сегментирование, фильтрацию и маршрутизацию трафика и позволяют устанавливать связь между расположениями. Для всех ресурсов этого сценария будет использоваться одна виртуальная сеть.
• Группы безопасности сети содержат список правил безопасности, который разрешает или запрещает входящий и исходящий трафик в зависимости от IP-адреса источника или назначения, порта и протокола. Виртуальные сети в этом сценарии защищены с помощью правил группы безопасности сети, которые ограничивают поток трафика между компонентами приложения.
• Azure Load Balancer распределяет входящий трафик в соответствии с правилами и зондами работоспособности. Подсистема балансировки нагрузки обеспечивает низкую задержку и высокую пропускную способность, а также увеличение масштаба до миллионов потоков для всех приложений, которые используют протоколы TCP и UDP. Внутренняя подсистема балансировки нагрузки используется в этом сценарии для распределения трафика в Citrix NetScaler.
• Синхронизация файлов Azure будут использоваться для всех общих хранилищ. Хранилище будет реплицироваться на два файловых сервера с помощью Синхронизация файлов Azure.
• База данных SQL Azure является управляемой службой реляционной базы данных на основе последней стабильной версии ядро СУБД Microsoft SQL Server. В этом примере он используется для размещения баз данных Citrix.
• ExpressRoute позволяет расширять локальные сети в облако Майкрософт по частному соединению, которое обеспечивается поставщиком услуг подключения.
• Домен Active Directory Services используются для проверки подлинности пользователей и служб каталогов.
• Группы доступности Azure гарантируют распределение виртуальных машин, развертываемых в Azure, между несколькими изолированными узлами оборудования в кластере. Таким образом, в случае сбоя оборудования или программного обеспечения в Azure затрагивается только подмножество виртуальных машин, а общее решение остается доступным для использования.
• Citrix ADC (NetScaler) — контроллер доставки приложений, который выполняет анализ трафика конкретного приложения для умного распространения, оптимизации и защиты сетевого трафика слоя 4 – слоя 7 (L4–L7) для веб-приложений.
• Онлайн-магазин Citrix — это хранилище корпоративного приложения, которое улучшает безопасность и упрощает развертывание, обеспечивая современный, непревзойденный, почти собственный пользовательский интерфейс в Citrix Receiver на любой платформе. Онлайн-магазин упрощает управление средами виртуальных приложений Citrix для нескольких местоположений и версий, а также настольных компьютеров.
• Сервер лицензирования Citrix будет управлять лицензиями на продукты Citrix.
• Citrix XenDesktops VDA позволяет подключаться к приложениям и рабочим столам. VDA устанавливается на машине, которая запускает для пользователя приложения или виртуальные рабочие столы. Он позволяет машинам регистрироваться с контроллерами доставки и управлять соединением высокой четкости (HDX) с пользовательским устройством.
• Контроллер доставки Citrix — это серверный компонент, отвечающий за управление доступом пользователя, а также брокерские подключения и подключения по оптимизации. Контроллеры также предоставляют службы создания машин, которые создают образы рабочего стола и сервера.

Альтернативные варианты

• Существует несколько участников с решениями VDI, которые поддерживаются в Azure, такие как VMware, Workspot и другие. Этот конкретный пример архитектуры основан на развернутом проекте, для которого использовался Citrix.
• Citrix предоставляет облачную службу, которая выделяет часть этой архитектуры. Это может быть альтернативой этого решения. Дополнительные сведения см. в Citrix Cloud (Облако Citrix).

Рекомендации

• Проверьте Citrix Linux Requirements (Требования к Citrix на ОС Linux).
• Задержка может оказать влияние на решение в целом. Проведите для рабочей среды соответствующее тестирование.
• В зависимости от сценария для решения может понадобиться виртуальная машина с GPU для VDA. Для этого решения предполагается, что GPU — необязательное требование.

Доступность, масштабируемость и безопасность

• Этот пример предназначен для высокой доступности для всех ролей, отличных от сервера лицензирования. Поскольку среда продолжает функционировать в течение 30-дневного периода отсрочки, если сервер лицензирования находится в автономном режиме, то на этом сервере не требуется дополнительная избыточность.
• Все серверы, предоставляющие аналогичные роли, должны развертываться в группах доступности.
• Этот пример сценария не включает возможности аварийного восстановления. Служба Azure Site Recovery может быть хорошей надстройкой для этой разработки.
• Рекомендуем развертывать экземпляры виртуальных машин в этом сценарии в Зонах доступности. Каждая зона доступности состоит из одного или нескольких центров обработки данных, оснащенных независимыми системами электроснабжения, охлаждения и сетевого взаимодействия. Каждый включенный регион имеет как минимум три зоны доступности. Такое распределение экземпляров виртуальной машины в разных зонах обеспечивает высокую степень доступности для уровней приложений. Дополнительные сведения см. в статье Что такое зоны доступности в Azure?. Вы также можете развернуть VPN-шлюзы и шлюзы ExpressRoute в Зонах доступности Azure.
• Для решения по управлению развертыванием продукта необходимо реализовать решение, например резервное копирование, мониторинг и управление обновлениями.
• Этот пример должен работать примерно для 250 многопоточных пользователей (около 50–60 на сервер VDA) со смешанным использованием. Но это будет сильно зависеть от типа используемых приложений. Для использования в производстве необходимо выполнить строгое нагрузочное тестирование.

Развертывание

Сведения о развертывании доступны в официальной документации Citrix.

Источник

VPS на Linux с графическим интерфейсом: запускаем сервер RDP на Ubuntu 18.04

В предыдущей статье мы разобрали запуск сервера VNC на виртуальной машине любого типа. У этого варианта масса недостатков, основным из которых являются высокие требования к пропускной способности каналов передачи данных. Сегодня мы попробуем подключиться к графическому рабочему столу на Linux по RDP (Remote Desktop Protocol). Система VNC основана на передаче массивов пикселей по протоколу RFB (Remote Framebuffer), а RDP позволяет отправлять более сложные графические примитивы и высокоуровневые команды. Обычно он используется для организации служб удаленных рабочих столов в Windows, но серверы для Linux также доступны.

Оглавление:

Установка графического окружения

Мы возьмем виртуальную машину с Ubuntu Server 18.04 LTS с двумя вычислительными ядрами, четырьмя гигабайтами оперативной памяти и жестким диском (HDD) на двадцать гигабайт. Более слабая конфигурация плохо подходит для графического десктопа, хотя это зависит от решаемых задач. Не забывайте использовать промокод Habrahabr10 для получения скидки в 10% при заказе.

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

Как и в предыдущем случае, мы выбрали XFCE из-за относительно невысоких требований к вычислительным ресурсам.

Русификация сервера и установка ПО

Часто виртуальные машины разворачиваются только с английской локализацией. На десктопе может потребоваться русская, настроить которую несложно. Сначала установим переводы для системных программ:

Того же эффекта можно достичь, отредактировав вручную файл /etc/default/locale.

Для локализации GNOME и KDE в репозитории есть пакеты language-pack-gnome-ru и language-pack-kde-ru — они понадобятся, если вы будете использовать программы из этих сред рабочего стола. В XFCE переводы устанавливаются вместе с приложениями. Дальше можно инсталлировать словари:

Кроме того, инсталляция переводов может потребоваться для некоторых прикладных программ:

На этом подготовка окружения рабочего стола завершена, осталось настроить сервер RDP.

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

В репозиториях Ubuntu есть распространяемый свободно сервер Xrdp, которым мы и воспользуемся:

Если все прошло нормально, сервер должен запуститься автоматически:

Сервер Xrdp запускается с правами пользователя xrdp и по умолчанию берет cертификат /etc/ssl/private/ssl-cert-snakeoil.key, который можно заменить собственным. Для доступа на чтение файла нужно добавить пользователя в группу ssl-cert:

Настройки по умолчанию можно найти в файле /etc/default/xrdp, а все прочие конфигурационные файлы сервера лежат в каталоге /etc/xrdp. Основные параметры находятся в файле xrdp.ini, который можно не менять. Конфиг хорошо документирован, к тому же в комплекте имеется соответствующие manpages:

Осталось только отредактировать скрипт /etc/xrdp/startwm.sh, который исполняется при инициализации пользовательской сессии. Предварительно сделаем резервную копию скрипта из дистрибутива:

Чтобы запустить окружение рабочего стола XFCE, потребуется сценарий примерно такого содержания:

Обратите внимание: в скриптах лучше прописывать полный путь к исполняемым файлам — это хорошая привычка. Сделаем скрипт исполняемым и на этом настройку сервера Xrdp можно считать законченной:

Настройка межсетевого экрана

По умолчанию Xrdp слушает TCP-порт 3389 на всех интерфейсах. В зависимости от конфигурации виртуального сервера может потребоваться настройка межсетевого экрана Netfilter. В Linux это обычно делается с помощью утилиты iptables, но в Ubuntu лучше использовать ufw. Если IP-адрес клиента известен, настройка осуществляется следующей командой:

Разрешить соединения с любого IP можно так:

Протокол RDP поддерживает шифрование, но открывать доступ к серверу Xrdp из сетей общего пользования — плохая идея. Если у клиента нет фиксированного IP, для повышения уровня безопасности сервер должен слушать только localhost. Доступ к нему лучше настроить через туннель SSH, который безопасно перенаправит трафик с клиентского компьютера. Аналогичный подход мы использовали в предыдущей статье для сервера VNC.

Подключение к серверу RDP

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

Добавим пользователя в группу sudo, чтобы он мог решать связанные с администрированием задачи. Если такой потребности нет, этот шаг можно пропустить:

Подключиться к серверу можно с помощью любого клиента RDP, включая встроенный клиент службы удаленных рабочих столов Windows. Если Xrdp слушает внешний интерфейс, никаких дополнительных телодвижений не понадобится. Достаточно указать в настройках соединения IP-адрес VPS, имя пользователя и пароль. После подключения мы увидим примерно такую картину:

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

Если сервер Xrdp слушает только localhost, на клиентском компьютере трафик придется упаковать в туннель SSH (на VPS должен быть запущен sshd). Под Windows можно использовать графический клиент SSH (например, PuTTY), а в UNIX-системах нужна утилита ssh:

После инициализации туннеля клиент RDP будет подключаться уже не к удаленному серверу, а к локальному хосту.

С мобильными устройствами сложнее: способные поднять туннель клиенты SSH придется покупать, к тому же в iOS и iPadOS фоновая работа сторонних приложений затруднена из-за слишком хорошей оптимизации энергопотребления. На iPhone и iPad поднять туннель в отдельном приложении не получится — потребуется приложение-комбайн, которое само умеет устанавливать соединение RDP через SSH. Такое, например, как Remoter Pro.

Менеджер сессий и сеансы пользователей

Возможность многопользовательской работы реализована непосредственно в сервере Xrdp и не требует дополнительной настройки. После запуска сервиса через systemd один процесс работает в режиме демона, слушает порт 3389 и взаимодействует через localhost с менеджером сессий.

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

Автоматический запуск менеджера сессий прописан в файле /etc/default/xrdp, а конфигурация хранится в /etc/xrdp/sesman.ini. По умолчанию выглядит она примерно так:

Здесь можно ничего не менять, стоит только запретить вход с правами root (AllowRootLogin=false). Для каждого авторизовавшегося в системе пользователя запускается отдельный процесс xrdp: если отсоединиться не завершив сеанс, пользовательские процессы по умолчанию продолжат работать, а к сеансу можно будет подключиться заново. Настройки можно изменить в файле /etc/xrdp/sesman.ini (секция [Sessions]).

Переключение раскладок клавиатуры

С двухсторонним буфером обмена проблем обычно не возникает, а вот с русской раскладкой клавиатуры придется немного пошаманить (русская локаль должна быть уже установлена). Отредактируем клавиатурные настройки сервера Xrdp:

В конец конфигурационного файла нужно добавить следующие строки:

Остается сохранить файл и перезапустить Xrdp:

Как видите, поднять сервер RDP на линуксовом VPS несложно, а в предыдущей статье мы уже разобрали настройку VNC. Помимо этих технологий, есть еще один интересный вариант: использующая модифицированный протокол NX 3 система X2Go. С ней мы разберемся в следующей публикации.

Источник