Привет, Хабр! Меня зовут Алексей Ватутин, я руководитель практики инфраструктуры рабочих мест в К2Тех. Ранее мы подробно разбирали предыдущие версии Termit (терминальный доступ для Linux и Windows) и то, как он взрослеет. Сейчас у Termit крупное обновление: к терминальной службе добавился VDI, а значит, «приложения и столы» теперь не только терминальные, но и полноценные виртуальные рабочие места. Если хочется освежить контекст, можно быстро пробежать наши прошлые обзоры: Termit 2.1 и ранний разбор Termit 2.0, а заодно вспомнить, что такое zVirt, где он уместен и почему мы его тестировали на равных с западными аналогами.

В последнее время Termit развивался по прямой: SSO на Kerberos, интеграция с 2FA по RADIUS, поддержка нескольких каталогов LDAP. В 2.4 поверх этого добавили новый пласт — VDI, и сделали это без параллельной вселенной: тот же брокер, та же логика доступа и отказоустойчивости, просто теперь у нас есть ещё и пул виртуальных машин, собранный по шаблону. Логика простая: всё, что работает и конфигурируется в терминальных сеансах, максимально переиспользовано для VDI. Админу это экономит время на обучение и снижает шанс увести систему от штатной конфигурации альтернативными путями.

Termit 2.4: основное

Начну с вещи, которую чаще всего спрашивали на пресейлах: веб-клиент. В ранних версиях его не было. В 2.4 он появился как разумный компромисс между удобством и безопасностью. Идея понятная: не везде у вас есть возможность быстро поставить нативный клиент, но «войти и работать» нужно. Разработчики ориентировались в том числе на пользователей планшетов — корпоративные сценарии с ними встречаются всё чаще, а разрабатывать ещё и отдельные мобильные клиенты под iOS/Android — долгий и дорогой путь. Поэтому первым делом сделали веб. Технически это классическая HTML5-прослойка, знакомая по решениям уровня Apache Guacamole. Ограничения ожидаемые: периферию и буфер обмена веб-клиент сейчас сознательно не пробрасывает. Пользователь где-то вздыхает, а специалист по ИБ ставит галочку в чек-листе и улыбается. Отмечу и практику: веб-сессии требуют заметных ресурсов — на брокере одна сессия может съедать до 1–1,5 vCPU. Вендор уже подтвердил, что в планах в 2.5 (предварительно выйдет в 1-м квартале 2026 года): вынести Apache Guacamole на отдельную роль, уже нашли, где можно будет оптимизироваться по ресурсам, падение по требованиям к vCPU на 1 сессию должно быть существенным. Если у вас массовый доступ через браузер, заранее заложите ресурсы на этот сценарий, не размещайте веб-компонент на том же узле, где и всё остальное.

Вторая важная добавка — хранение пользовательских профилей на сети. По сути это «почти перемещаемые профили» для Linux-сессий: пользователь уходит с одного терминального сервера и приходит на другой, а окружение остаётся с ним. В текущей реализации из коробки поддерживается хранение на NFS. Если у вас в окружении будет больше одного терминального сервера, а пользователи не имеют привычки хранить данные в сетевых папках, то эта опция точно будет востребована. Теперь хранение профилей стало прозрачнее и упрощает настройку рабочих окружений.

Третий кусок — централизованные политики по периферии. Это обычно реализовано у каждого вендора по-своему и часто страдает непоследовательностью. В Termit теперь можно централизованно определять, что пускать в сессию, а что нет: локальные диски, принтеры, аудио/видео, смарт-карты, буфер обмена. Гранулярность на старте базовая, но уже рабочая. Главное, что теперь это настраивается из консоли администрирования, а не имеет форму множества конфигов на ПК пользователей, как это было ранее.

Обновленный шлюз — разработчики начали постепенный отказ от SSH-туннеля в сторону полноценного TLS-шлюза. Пока что поддерживаются оба варианта, но в будущем останется только TLS. Такой ход связан с повышением требований по ИБ в части трафика между пользователем и сервисом. А еще, говорят, в следующей версии Termit шлюз TLS сможет реализовывать шифрование по ГОСТ.

Также в новом релизе появились:

• «липкие» сессии, т.е. если у пользователя есть запущенное приложение (открыта сессия), то запуск второго приложения автоматически произойдет на том же терминальном сервере и в той же сессии, при условии, что оба приложения доступны на этом сервере;

  

• поддержка механизма агрегации ресурсов для геораспределенных инсталляций — скажем «Нет» двум ярлыкам на одно приложение;

• доработана функциональность по взаимодействию с каталогами LDAP.

Windows-часть: про RDSH и лицензии без упрощений

В части доставки Windows-приложений у Termit всё остаётся предсказуемым и прозрачным: публикация приложений и рабочих столов идёт через RDSH, на сервер ставится агент Termit, а роль брокера исполняет Termit. RD Connection Broker из Windows не нужен. Версии серверной Windows из «зрелой линейки» — то, что и ожидали. Есть важная ремарка, которую я повторяю всем: лицензирование остаётся на вашей стороне. Серверные лицензии и RDS CAL нужны, иначе вы переходите в «серую зону», где нам вместе будет неуютно. Если вы переходите на отечественные решения и часть ПО тащите на Linux, Termit даёт вам единую точку входа и общие процессы для пользователей, а RDSH-часть — способ не ломать то, что пока рано переносить.

Зачем VDI, если терминал устраивал

Терминальный доступ прекрасен там, где у вас много типовых пользователей и приложений, общий пул ресурсов и простые требования к пользовательскому окружению. Бухгалтерии, фронт-офисы, филиальная сеть с ограниченным количеством пользователей — всё это эффективно обслуживается терминальным доступом при минимальных накладных расходах. Но есть классы задач, где появляются ограничения:

• Разработчики и инженеры с «непростыми» зависимостями, специфическими драйверами и требованием «чтобы окружение было моим, а не общим».

• Приложения с тяжёлой графикой и существенными требованиями по vCPU и ОЗУ — CAD/CAM.

• 3D-визуализация, тот же NanoCAD/КОМПАС и пр. 

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

Вот здесь VDI — естественное продолжение: вы сохраняете единый способ доставки рабочего места, но из общего пула переходите к индивидуальным ВМ.

Что умеет VDI в Termit 2.4

Сейчас в качестве платформы виртуализации официально поддерживается zVirt — решение от Orion soft, того же вендора, что делает Termit. Это сразу даёт совместимость на уровне API и обеспечивает корректную работу между брокером и виртуализацией. Настройка типовая: подключаете виртуализацию, на которой будут работать ВРМ, создаете пул и указываете «эталонный образ», описываете правила подготовки ВМ, настраиваете группы пользователей, и дальше Termit по требованию выдаёт виртуалку из пула. Машины могут быть сессионными (выданы из пула на время) или персональными (закреплены за пользователем). На сегодня доступны связанные клоны — лёгкие и быстрые. Полные клоны — в планах на 2.5 в первом квартале 2026 года. Это закрывает требования к полной независимости образов для особо чувствительных кейсов.

По протоколам картина такая: базовые сценарии закрывают RDP и X2Go. Для графических сценариев и vGPU доступен Loudplay — наследник облачного гейминга, оптимизированный под высокие FPS, агрессивную компрессию и работу на каналах связи с большими потерями. Он идёт отдельной лицензией и тянет за собой инфраструктурные требования (в том числе к лицензированию vGPU). Это не обязательный компонент, а инструмент для тех, кому действительно нужна хорошая картинка и производительность в 3D. На горизонте в Termit — собственный протокол без использования Open Source компонентов в основе. Логика здесь не в том, чтобы «закрыть код и брать деньги за воздух», а в том, чтобы реализовать оптимизации быстрее, чем они появятся в апстриме: гибкая компрессия аудио/видео, умное разделение потоков, адаптация под высокие RTT и потери, разумные виртуальные каналы.

На практике в лёгких офисных сценариях ориентируйтесь на условные 2 Мбит/с на пользователя. При использовании 3D-графики и высоких FPS, отдельный клиент может запросить до 20-25 Мбит/с. В общем, не забывайте про сеть с учётом таких нагрузок, в том числе и про клиентскую сторону: какой бы протокол ни был, плохой Wi-Fi превращает любую работу с виртуальной машиной в медленное слайд-шоу.

Управление и наблюдаемость

В версии 2.4 управление сессиями закрывает базовые потребности: видеть, отключать, завершать, задавать таймауты. Таймауты задаются на уровне групп серверов, чтобы избежать несогласованных политик — это дисциплинирует и экономит CPU/память на серверах. Для мониторинга компонентов появились шаблоны под Zabbix — это позволяет своевременно фиксировать проблемы с сервисом, а не работать по факту жалоб от пользователей. Пока отсутствуют расписания энергосбережения ВМ. Отключение инфраструктуры на ночь и выходные выполняется вручную или внешними средствами. Для многих инфраструктур это не критично, но упомянуть стоит: чтобы не рассчитывали на функцию, которой ещё нет.

Безопасность и вход

Единый вход по Kerberos (SSO) у Termit появился в 2.3 и туда же вернулся в 2.4. Пользователь один раз аутентифицируется в клиенте — дальше его данные прокатываются в сессии автоматически. На Windows возможны нюансы: в средах с жёсткими GPO-политиками это уже прекрасно знают. Второй фактор реализован через RADIUS — тоже с 2.3. Тут стандартная правда жизни: разные MFA-решения по-разному трактуют протокол и формирование токена, поэтому любую связку надо проверять на пилоте. Мы как интегратор пару раз ловили несовпадение ожиданий между продуктами — решается совместной настройкой, но лучше закладывать это в план работ, а не «потом как-нибудь». Кстати, можете использовать матрицу совместимости от вендора, но нюансы всё равно могут появиться.

Файлы подключений

Мелочь, а приятно. В Termit есть формат файлов подключений: кидаете пользователю файл, он его открывает, запускается клиент Termit, и подцепляется нужное приложение или рабочий стол. То, что обычно требует устного «зайди туда-то, нажми там-то», превращается в двойной клик. На следующем шаге вендор обещает генерацию таких файлов прямо из интерфейса — будет удобнее, чем руками вытаскивать идентификаторы.

Открытые вопросы, которые стоит проговорить на старте

RBAC (управление доступом на основе ролей) — доступ уже проработан логически, но команда готовит UI. Как только появится человекочитаемый интерфейс, станет проще раздавать права в соответствии с обязанностями. Базовые отчеты есть, но хочется полноформатные — по сессиям/пользователям/приложениям. Нативных мобильных клиентов OS/Android пока нет, и вендор не озвучивает планы по их разработке. Веб-клиент покрывает планшеты — и это осознанный выбор ради скорости выхода. Если говорить о ресурсах — закладывайте CPU на брокере, особенно если хотите массовый вход через браузер. 2FA/MFA — готовьте тест-план под вашу конкретную систему многофакторки. И, наконец, камеры. Проброс видеокамер пока отсутствует: если у вас есть кейсы с видео в сессии, не делайте на это ставку в 2.4.

Где Termit 2.4 особенно уместен

Если у вас уже есть терминальный доступ на Termit, а отдельные команды требуют персональных окружений. Версия 2.4 позволяет не разводить зоопарк из разных продуктов. Единый брокер, единая точка администрирования, общая безопасность и мониторинг — это ощутимо сокращает операционные риски. Если вы только выбираете между терминалками и VDI, то критерии выбора довольно очевидны. Массовые офисные сценарии — терминалки дадут лучшую плотность и меньше издержек. Разработчики, инженеры, чувствительные окружения, графика и vGPU — берите VDI-пул и не пытайтесь добиваться высокой графической производительности от RDP/X2Go. Плюс прагматичный: zVirt — платформа, которую многие уже крутят в проде; интеграция Termit с ней снижает риски совместимости, связанные с API и поддержкой.

Коротко про конкурентов, чтобы не строить иллюзий

Рынок не спит: есть продукты, которые также закрывают терминалки и VDI в одном флаконе, а скоро подъедут и новые игроки. Где-то будет шире поддержка гипервизоров, где-то — удобнее веб-клиент или отчётность. Сейчас сильная сторона Termit в том, что это действительно одна система с общим брокером и узнаваемой админской логикой, без отдельной консоли с отличающейся логикой. Плюс плотная связка со zVirt, которую легко показать на пилоте. Минус на текущем этапе — именно «моноподдержка» zVirt на стороне VDI: универсальность по гипервизорам важна для части заказчиков, и я ожидаю, что вендор это расширит.

Что брать в пилот

Если запускаете VDI с графикой, начните с базы: проверьте сеть, процессоры, память. Без этого Loudplay не покажет чудес — подключите его уже потом. Для офисных задач не усложняйте: RDP или X2Go закроют всё, что нужно.

Пилот живёт на мелочах. Таймауты и профили пользователей должны работать предсказуемо, веб-клиент не должен зажимать брокер по CPU, вход с MFA и SSO — проходить без усложнений. Политики по периферии тоже лучше проверить заранее: что пускаете в сессию, а что нет. Добавьте брокер в Zabbix — пусть он реагирует первым, а не пользователи.

С Windows всё по классике: RDSH, агент Termit, лицензии, домен, пути к приложениям. И не забудьте заранее решить, кто обновляет шлюзы и где они живут — в DMZ, с VPN или отдельно.

Чек-лист:

• сеть, CPU, память;

• таймауты и профили;

• веб-клиент и нагрузка на брокер;

• MFA и SSO;

• политики периферии;

• мониторинг брокера;

• RDSH и агент Termit;

• лицензии и домен;

• обновления шлюзов.

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

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