Схемы взаимодействия компонентов Termidesk


Схема взаимодействия компонентов и приложений

Схема взаимодействия компонентов Termidesk и приложений представлена на рисунке.

Схема взаимодействия компонентов и приложений

«Универсальный диспетчер»

Компонент, отвечающий за идентификацию пользователей, назначение и контроля доставки им ВРМ, приложений и рабочих столов. 

Поскольку основная задача «Универсального диспетчера» - предоставить ВРМ пользователю, в нем реализованы следующие функции:

  • взаимодействие с поставщиком услуг, на котором размещается ВРМ;
  • взаимодействие с терминальными серверами, к которым предоставляется доступ;
  • взаимодействие с серверами каталогов для обеспечения процедур идентификации и аутентификации.

«Агрегатор»

«Агрегатор» - это тип роли, доступный при установке Termidesk. «Агрегатор» предоставляет пользователям объединенный список приложений с нескольких ферм Termidesk, с возможностью объединения одинаковых приложений или ВРМ.

«Агрегатор» доступен в продукте Termidesk VDI.

Агрегатор может быть установлен со следующими типами веб-интерфейса:

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

Основная задача «Агрегатора» – предоставить пользователю объединенный набор ресурсов, поэтому в нем реализованы следующие функции:

  • объединение ресурсов нескольких ферм Termidesk. При этом пользователю отображается только один из дублирующихся экземпляров ресурсов, если такие есть;
  • сквозная аутентификация на серверах каталогов. После авторизации в «Агрегаторе» и запросе ресурсов с «Универсального диспетчера» учетная запись пользователя будет автоматически зарегистрирована на «Универсальном диспетчере» фермы Termidesk, если пользователь состоит в группах, существующих на нем.

«Шлюз»

Компонент, отвечающий за туннелирование протоколов доставки, использующих транспортный протокол TCP. Может быть установлен совместно с «Универсальным диспетчером», либо отдельно.

«Шлюз» обеспечивает изоляцию инфраструктуры VDI и терминальных серверов, находящихся во внутренней локальной сети, от внешних локальных или глобальных сетей.

 Рекомендуется использовать «Шлюз» при работе через недоверенные сети, поскольку это способствует не только защищенному взаимодействию (применяется протокол SSL), но и сокрытию инфраструктуры рабочих мест.

 «Шлюз» использует технологию websockets (WS) для туннелирования протоколов доставки. «Универсальный диспетчер» передает на «Клиент» информацию о «Шлюзе», через который будет осуществляться доставка рабочего места. «Клиент» устанавливает со «Шлюзом» защищенное соединение. Схема работы представлена на рисунке.

Схема работы компонента «Шлюз»

Termidesk может взаимодействовать со множеством «Шлюзов», настроенных в режиме балансировки нагрузки.

«Менеджер рабочих мест»

Компонент, отвечающий за взаимодействие с поставщиком ресурсов и управления жизненным циклом рабочих мест. Является обработчиком фоновых задач, взаимодействует с поставщиком ресурсов, на котором размещаются рабочие места. Может быть установлен совместно с «Универсальным диспетчером», либо отдельно. 

Работа «Менеджера рабочих мест» основывается на следующих службах:

  • termidesk-celery-beat – отслеживает очереди брокера сообщений RabbitMQ на предмет наличия заданий для выполнения (например, публикации фонда, удаления ВМ и др.). Обеспечивает передачу заданий службе termidesk-celery-worker;
  • termidesk-celery-worker – обеспечивает управление питанием ВРМ и сбор информации о терминальных сессиях. Выполняет задачи, размещенные в очереди брокера сообщений RabbitMQ.

«Менеджер рабочих мест» задействуется при публикации фонда рабочих мест и взаимодействует с БД для определения задачи на публикацию (создать ВМ, дождаться инициализации, клонировать и т.п) и ее исполнение. Компонент используется, в том числе, для отслеживания состояния уже созданных ВМ.

«Агент»

Без установленного на соответствующем узле «Агента» сервер Termidesk не сможет корректно взаимодействовать с этим узлом. По среде установки эти «Агенты» распределяются следующим образом:

  • устанавливаются в гостевую ОС ВМ или автономной машины: «Агент виртуального рабочего места», «Видеоагент», «Агент виртуальных смарт-карт»;
  • устанавливается на узел виртуализации ПК СВ Брест: «Агент узла виртуализации»;
  • устанавливается на узел терминального сервера: «Сессионный агент».

«Клиент»

Компонент, отвечающий за доставку ВРМ на пользовательскую рабочую станцию с возможностью перенаправления периферии, каталогов, а также оптимизацию их использования в протоколе доставки. 

Для отображения экрана рабочего места «Клиент» открывает соответствующую программу:

  • при использовании протоколов SPICE, TERA будет запущено ПО Termidesk Viewer;
  • при использовании протокола RDP будет запущено одно из приложений в зависимости от используемой ОС: wfreerdp.exe, mstsc.exe, xfreerdp, ПО Termidesk Viewer (если в настройках «Клиента» активирован экспериментальный функционал).

При подключении через «Шлюз» «Клиент» использует программу vdi-proxy (входит в состав «Клиента») для создания WS-туннеля между запускаемой программой и опубликованным ресурсом (ВРМ или приложением). В качестве аргумента для vdi-proxy передается путь к конфигурационному файлу, который содержит параметры подключения. vdi-proxy подключается по URL к «Шлюзу» и создает WS-туннель (по сути протокол HTTPS с шифрованием). Далее от «Шлюза» до «Агента» создаётся TCP-соединение.

Схема работы представлена на рисунке.

Схема работы компонента «Клиент»

«Оркестратор»

Компонент, отвечающий за автоматизацию развертывания Termidesk в облачных структурах.

В текущей реализации выполняет роль API-шлюза и обеспечивает обработку запросов внутри управляемого контура и передачу результата обработки облачным компонентам.

Схема работы «Оркестратора» представлена на рисунке.

Схема работы компонента «Оркестратор»

STAL

«Сервер терминалов Astra Linux» или STAL – компонент, отвечающий за организацию терминального доступа в ОС Astra Linux Special Edition (Server). Компонент STAL может использоваться как в Termidesk VDI, так и в Termidesk Terminal.

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

Общая схема взаимодействия Termidesk и компонента STAL приведена на рисунке.

Процесс PROXY – внутренний сервис, прослушивающий сетевой сокет на порте 3389 и транслирующий подключения в unix-сокеты, с которыми связан терминальный сервер.

Для того чтобы пользователь после запуска «Клиента» получил приложение или терминальный доступ к STAL, происходит следующее:

  • на сервере с установленным STAL сервис PROXY выполняется с правами служебного пользователя stal-proxy;
  • пользователь подключается к серверу Termidesk через «Клиент», получает список доступных ему приложений и терминалов и выбирает необходимое подключение;
  • от компонента сессионного агента на сервис STAL поступает запрос на создание сессии. Взаимодействие между компонентами выполняется посредством dbus;
  • сервис STAL создает X (первую, вторую и так далее) сессию пользователя (в зависимости от количества подключившихся пользователей);
  • сервис STAL отправляет сигнал на открытие порта на сервис PROXY;
  • сервис PROXY открывает порт 3389 (по умолчанию) на прием соединений и ожидает подключения от «Клиента»;
  • при подключении «Клиента» сервис PROXY принимает соединение, затем выполняет следующее:
    • закрывает сокет приема соединений;
    • запускает протокол RDP на локальный unix-сокет;
    • создает асинхронную задачу на передачу данных с сокета принятого соединения «Клиента» на unix-сокет;
    • отправляет на сервис STAL информацию о соединении «Клиента»;
  • «Клиент» получает доступ в X-сессию;
  • сервис PROXY отслеживает состояние подключения «Клиента» и останавливает передачу данных, если поступил сигнал на отключение от STAL.

Схема взаимодействия Termidesk и STAL

Для того чтобы пользователь со своего АРМ смог перенаправить подключенный диск в терминальную сессию, происходит следующее:

  • «Cессионный агент» устанавливает политику разрешения перенаправления дисков для терминальной сессии;
  • STAL выполняет запуск сервера freerdp-shadow с каналом RDPDR (клиент шины DBus ru.uveon.stal.rdpdr);
  • при первом обращении в шину запускается STAL-RDPDR (менеджер сессионной шины DBus ru.uveon.stal.rdpdr);
  • служба xfreerdp (или другие программы доставки, использующиеся у пользователя - например, mstsc или ПО Termidesk Viewer) передает служебную информацию через протокол MS-RDPEFS;
  • расширение RDPDR транслирует команды протокола RDPDR в шину DBus ru.uveon.stal.rdpdr;
  • STAL-FUSE (менеджер службы fuse) запускается на каждую точку монтирования и транслирует команды RDPDR в FUSE API;
  • пользователь получает подключенный к точке монтирования ресурс.

Схема работы STAL при перенаправлении диска

Для того чтобы пользователь со своего АРМ смог перенаправить печать из терминальной сессии, происходит следующее:

Печать пользователей изолирована и выполняется в отдельных сессиях при подключении разных пользователей с разных АРМ.

  • «Cессионный агент» устанавливает политику разрешения печати для терминальной сессии;
  • STAL выполняет запуск сервера freerdp-shadow с каналом RDPDR (клиент шины DBus ru.uveon.stal.rdpdr);
  • при первом обращении в шину запускается STAL-RDPDR (менеджер сессионной шины DBus ru.uveon.stal.rdpdr);
  • при старте системы запускается STAL-RDPEPC (менеджер системной шины DBus ru.uveon.stal.rdpepc);
  • служба xfreerdp (или другие программы доставки, использующиеся у пользователя - например, mstsc или ПО Termidesk Viewer) передает служебную информацию через протокол RDPEPC (базируется на операциях протокола RDPDR);
  • расширение RDPDR транслирует команды протокола RDPEPC в шину DBus ru.uveon.stal.rdpdr и далее в шину DBus ru.uveon.stal.rdpepc;
  • STAL-RDPEPC транслирует команды в CUPS API;
  • пользователь автоматически получает виртуальные принтеры во всех своих сессиях;
  • пользователь инициирует печать документа на виртуальный принтер;
  • CUPS запускает печать через VPRINT (драйвер виртуального принтера);
  • VPRINT сохраняет задание в каталоге JOBS SPOOL и как клиент DBus отправляет в STAL-RDPEPC информацию о завершении печати документа, количества копий, страницы и т.д.;
  • STAL-RDPEPC передает данные печати через DBus в сессию пользователя в STAL-RDPDR;
  • RDPDR отправляет данные печати через RDPEPC.

Схема работы STAL при перенаправлении печати