Apache Guacamole или RustDesk: что выгоднее и когда

MAATRIX

Нужен удалённый доступ к десятку серверов или рабочих станций, а TeamViewer и AnyDesk либо просят корпоративную лицензию, либо блокируют IP из России. Дальше — выбор между двумя принципиально разными подходами: браузерным шлюзом Apache Guacamole и P2P-инструментом RustDesk. Оба open source, оба развёртываются на своём VPS, но решают разные задачи, и путаница между ними — частая причина, почему выбранный инструмент через месяц не подходит.

В чём принципиальная разница

Guacamole — это clientless-шлюз. Он не устанавливает агента на удалённую машину: подключается к ней по уже существующим протоколам RDP, VNC или SSH, а пользователю отдаёт картинку через браузер по HTML5. Сама Guacamole — это Java-сервлет (guacd + guacamole-client), который проксирует трафик и рендерит его в веб-интерфейс.

RustDesk работает иначе — по модели агент-агент, как TeamViewer. На управляемой машине стоит клиент RustDesk, который регистрируется на relay/ID-сервере (hbbs) и устанавливает соединение — по возможности напрямую (P2P через NAT traversal), а если не получается — через relay-сервер (hbbr), который просто перегоняет зашифрованный трафик между двумя клиентами.

Из этого различия вытекает всё остальное:

Когда выгоднее Guacamole

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

• Команда из 5-20 человек, которым нужен доступ к разным серверам компании (dev, staging, Windows-машины бухгалтерии) через единый портал с логином/паролем и правами.
• Нужен аудит: кто, когда и к какой машине подключался, запись сессий.
• Клиенты подключаются с разных устройств (планшет, чужой компьютер, тонкий клиент), где ставить агент неудобно или невозможно.
• Уже есть RDP/VNC/SSH-доступ к машинам, просто нужен удобный веб-фронт вместо голых портов наружу.

Минус Guacamole в том, что сервер — это единая точка отказа и единая точка нагрузки: весь видеопоток каждой активной сессии проходит через него, перекодируется и отдаётся клиенту как последовательность кадров. На 3-5 одновременных сессий с активной работой (не просто открытое окно) 2 vCPU / 4 GB RAM работают, но уже с заметной нагрузкой — мы разбирали это подробнее в статье сколько RAM нужно для Apache Guacamole. Установка тоже не тривиальна: нужны guacd, Tomcat, база для пользователей и настройка каждого подключения — пошагово это описано в установке Guacamole на Ubuntu 24.04, а если не хочется руками собирать зависимости — в Guacamole через Docker Compose.

Когда выгоднее RustDesk

RustDesk выигрывает там, где нужен быстрый прямой доступ одного человека к одной машине — классический сценарий техподдержки или личного удалённого доступа:

• Разово подключиться к чьему-то компьютеру для помощи (родственнику, клиенту, коллеге).
• Постоянный личный доступ к 1-3 машинам (домашний ПК, рабочая станция в офисе) с телефона или ноутбука.
• Важна низкая задержка и живой интерактив (не просто "посмотреть", а активно работать мышью — например, при удалённом дизайне или монтаже).
• Не хочется тратить ресурсы сервера на декодирование видео — при удачном P2P-соединении сервер почти не нагружен, он только помогает договориться о прямом канале.

Минус: RustDesk требует установки клиента на каждую управляемую машину и на управляющее устройство (хотя есть web-клиент, он менее удобен, чем нативный). Централизованный контроль доступа для команды из self-hosted версии собирается вручную — своего Guacamole-подобного портала с ролями "из коробки" тут нет, только ID/пароль и опционально permanent password с ACL на уровне отдельных клиентов. Установка сервера (hbbs + hbbr) описана в установке RustDesk на VPS и в отдельной пошаговой инструкции для RustDesk на Ubuntu 24.04.

Требования к серверу и разница в стоимости

Практический вопрос — сколько сервера реально нужно под каждый вариант.

Для Guacamole ресурсы масштабируются с числом одновременных активных сессий, потому что сервер физически кодирует картинку для каждой:

1-2 активные RDP-сессии:  2 vCPU, 4 GB RAM
3-6 активных сессий:      4 vCPU, 8 GB RAM
8-10 активных сессий:     8 vCPU, 16 GB RAM (и SSD обязательно)

Для RustDesk-сервера (hbbs + hbbr) требования куда скромнее, потому что relay включается не всегда, а сигналинг — лёгкая операция:

До 20-30 клиентов, редкий relay:   1 vCPU, 1-2 GB RAM
Много клиентов за симметричным NAT
(relay работает постоянно):        зависит от числа одновременных
                                    relay-сессий — тут нагрузка
                                    приближается к Guacamole,
                                    т.к. relay тоже гоняет видеопоток

Ключевая ловушка: если у большинства ваших клиентов "закрытый" NAT (офисные сети с жёсткой фильтрацией, мобильные операторы), P2P часто не устанавливается, и RustDesk постоянно падает в relay-режим. В этом случае разница в нагрузке с Guacamole исчезает — relay-сервер точно так же перекачивает весь видеопоток, просто без перекодирования кадров (более лёгкая операция, чем рендеринг RDP, но не бесплатная). Проверить это заранее сложно — реальную долю P2P/relay вы увидите только на своём трафике, поэтому для непредсказуемой аудитории закладывайте запас по CPU и трафику так же, как под Guacamole.

Безопасность и то, что часто упускают

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

• Guacamole — пароли к RDP/VNC-подключениям хранятся в базе (MySQL/PostgreSQL) сервера, вместе с логинами пользователей портала. Обязательно: TLS на веб-интерфейсе (через nginx-прокси), смена пароля администратора guacadmin сразу после установки, и по возможности — вынос за VPN или ограничение доступа по IP на уровне firewall.
• RustDesk self-hosted — по умолчанию relay-сервер не шифрует канал сам по себе так же строго, как облачный сервис RustDesk (там есть готовый TLS-контур); при самостоятельном развёртывании нужно явно поднимать hbbs/hbbr за TLS-терминацией и генерировать собственный ключевой пары для сервера, иначе клиенты будут ругаться на непроверенный сертификат сервера или, что хуже, кто-то поднимет поддельный relay.

Для обоих вариантов разумно не открывать сервер голым портом в интернет, а завести доступ через WireGuard — подход и типовая схема разобраны в статье VPN для удалённой команды: типовая схема, а для конкретно RDP-доступа — в RDP через WireGuard: безопасный доступ.

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

На практике многие команды не выбирают одно решение навсегда, а комбинируют:

• Guacamole — как централизованный портал для команды: доступ к серверам компании, аудит, единая точка входа для всех "штатных" подключений.
• RustDesk — как быстрый инструмент для разовой помощи внешним людям (клиентам, подрядчикам), которым не хочется давать доступ в общий портал с правами и логинами.

Технически это два независимых сервиса, которые прекрасно живут на одном VPS с 4-8 GB RAM, если суммарная нагрузка не пиковая одновременно — guacd и hbbs/hbbr не конфликтуют по портам (Guacamole слушает 8080/4822, RustDesk — 21115-21119). Единственное, за чем стоит следить — совокупное потребление CPU при одновременных активных сессиях обоих типов, иначе оба начнут "тормозить" по очереди.

Частые вопросы