RustDesk в Docker Compose: готовый файл

MAATRIX

Если вы подключаетесь через публичный relay RustDesk (rustdesk.com), рано или поздно упрётесь в его лимиты: скорость проседает в часы пик, соединение рвётся без объяснений, а трафик с чужого рабочего стола идёт через сервер, который вам не принадлежит. Решение простое — поднять собственный RustDesk-сервер (hbbs + hbbr) на своём VPS через Docker Compose. Ниже — рабочий файл, который можно скопировать и запустить за пять минут, плюс всё, что вокруг него обычно ломается.

Что такое hbbs и hbbr и зачем свой relay

RustDesk — open-source аналог TeamViewer/AnyDesk с end-to-end шифрованием. У него две логически разные роли на сервере, и обе реализованы одним и тем же бинарником rustdesk-server, просто с разными командами запуска:

• hbbs (host & broker server) — сервер идентификации и рандеву. Он не видит содержимое сессии: клиенты регистрируются с уникальным ID, hbbs помогает им найти друг друга и по возможности установить прямое P2P-соединение (через NAT-холпанчинг).
• hbbr (relay server) — сервер-ретранслятор. Включается, когда прямое P2P-соединение не удалось (симметричный NAT, жёсткий корпоративный firewall) — тогда весь трафик экрана и управления идёт транзитом через него.

По умолчанию клиент RustDesk использует публичные hbbs/hbbr от разработчиков. Это удобно для разового подключения к знакомому, но для рабочего парка машин — плохая идея: скорость relay зависит от загрузки чужого сервера, есть неявные лимиты на объём трафика при бесплатном использовании, а весь ключевой обмен идёт через инфраструктуру, которую вы не контролируете. Свой сервер снимает все три проблемы разом: скорость упирается в канал вашего VPS, а не в чужую очередь, а метаданные о том, кто и когда подключался, остаются у вас.

Оговорка: даже с собственным hbbs/hbbr трафик между двумя P2P-клиентами остаётся end-to-end зашифрованным — сервер его не расшифровывает. Но если соединение уходит через relay (hbbr), весь зашифрованный поток физически проходит через вашу машину, поэтому канал и CPU сервера должны быть приличными, особенно при нескольких пользователях одновременно.

Требования к серверу

RustDesk-сервер лёгкий по CPU и памяти — узкое место почти всегда сеть, а не вычисления.

Ключевое требование — белый статический IP без CGNAT и открытые порты наружу. Если сервер стоит за NAT провайдера (частая история с домашним интернетом), hbbs/hbbr снаружи будут недоступны и вся конструкция не заработает. Арендованный VPS с публичным IP закрывает этот вопрос по умолчанию.

Если Docker ещё не установлен, разверните его по инструкции Ubuntu 24.04: установка Docker с нуля — там же есть шаги для установки Docker Compose plugin, который понадобится дальше.

Готовый docker-compose.yml

Создайте рабочую директорию и файл:

mkdir -p ~/rustdesk-server/data
cd ~/rustdesk-server
nano docker-compose.yml

Содержимое файла:

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    restart: unless-stopped
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"
      - "21118:21118"
    command: hbbs -r rustdesk.example.com:21117
    volumes:
      - ./data:/root
    networks:
      - rustdesk-net
    depends_on:
      - hbbr

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    restart: unless-stopped
    ports:
      - "21117:21117"
      - "21119:21119"
    command: hbbr
    volumes:
      - ./data:/root
    networks:
      - rustdesk-net

networks:
  rustdesk-net:
    driver: bridge

Замените rustdesk.example.com на реальный домен или IP-адрес вашего сервера — этот флаг -r в команде hbbs говорит клиентам, куда обращаться за relay-сервером (hbbr), если P2P не сложится. Если домена пока нет, можно временно указать голый IP — работать будет так же, просто менее удобно при смене сервера в будущем.

Обратите внимание на том ./data:/root — он общий для обоих контейнеров и критически важен. При первом запуске hbbs генерирует в /root пару ключей id_ed25519 / id_ed25519.pub. Публичный ключ из этого файла нужно будет прописать в каждом клиенте — без него клиенты не смогут проверить подлинность вашего сервера. Если том не примонтирован (или вы случайно удалите контейнер вместе с анонимным volume), при пересоздании контейнера сгенерируется новая пара ключей — и все ранее настроенные клиенты перестанут подключаться, пока вы не обновите ключ вручную на каждом из них.

Запуск:

docker compose up -d
docker compose logs -f hbbs

В логах hbbs должна появиться строка о запуске relay-сервера на 21116 и путь к сгенерированным ключам. Публичный ключ достаём так:

cat ~/rustdesk-server/data/id_ed25519.pub

Сохраните эту строку — она понадобится при настройке каждого клиента.

Firewall и открытие портов

RustDesk-серверу нужны пять портов, три из них — на hbbs, два — на hbbr:

Если у вас поднят UFW, откройте их так — подробный разбор самого UFW и типичных ошибок есть в статье UFW на Ubuntu 24.04: пошаговая установка:

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp
sudo ufw reload

Порт 21116/udp часто именно тот, который забывают — без него P2P-хендшейк не работает, и все соединения принудительно идут через relay даже там, где мог бы установиться прямой канал. Если сервер арендован у провайдера с собственным сетевым firewall (security group), продублируйте те же правила и там — UFW внутри VM их не заменяет.

Настройка клиентов на свой сервер

На каждой машине, которую хотите подключить через свой сервер:

1. Откройте RustDesk → значок трёх точек → Настройки сети (Network).
2. Отметьте «Свой сервер» / «Unlock Network Settings» (может потребоваться ввести пароль, если он задан).
3. Заполните поля:

• ID Server: rustdesk.example.com (или IP)
• Relay Server: rustdesk.example.com (или IP) — обычно достаточно того же адреса, hbbs сам перенаправит на hbbr по флагу -r
• Key: содержимое id_ed25519.pub, которое вы сохранили на предыдущем шаге

1. Сохраните и перезапустите приложение.

Проверить, что клиент действительно смотрит на ваш сервер, статус соединения в интерфейсе покажет «Ready» с указанием вашего адреса вместо публичного пула. Для массового парка машин удобнее не настраивать каждую машину вручную, а собрать кастомный инсталлятор с зашитыми ID Server/Key (через MSI-конфиг на Windows или сборочные параметры клиента) — это отдельная тема, но такая возможность у RustDesk есть.

Домен, TLS и веб-клиент

Протоколы hbbs/hbbr — не HTTP, а собственный бинарный протокол RustDesk поверх TCP/UDP, поэтому классический сертификат Let's Encrypt на эти порты не навешивается и не нужен — шифрование сессии обеспечивается самим RustDesk на уровне приложения (ключевая пара + сквозное шифрование клиент-клиент). Если видели у кого-то в инструкциях reverse-proxy с SSL перед hbbs — это, как правило, избыточно для типового кейса и нужно только тем, кто разворачивает у себя ещё и веб-клиент RustDesk (Flutter Web) как отдельный HTTP-сервис на своём поддомене — тогда TLS ставится перед этим HTTP-фронтом, а не перед самим hbbs. Если такой сценарий вам нужен, посмотрите общий подход в статье про Traefik как reverse proxy для Docker или про Caddy с авто-SSL на Ubuntu 24.04 — оба варианта заведутся поверх уже поднятых контейнеров без конфликта портов, если веб-клиент слушает отдельный порт.

Домен вместо голого IP оправдан по одной практической причине: если когда-нибудь придётся переезжать на другой сервер (например, добавить резервный или сменить локацию), вы просто поменяете A-запись — и все клиенты, у которых ID Server указан доменным именем, продолжат работать без переустройки. При IP в поле придётся вручную обновлять адрес на каждой машине.

Отдельно стоит сказать про GUI-панель управления: у RustDesk есть платная Pro-версия с веб-консолью для управления пользователями, группами и аудитом подключений (rustdesk-server-pro). Бесплатная community-версия, которую разворачивает docker-compose выше, консоли не имеет — управление ключами и доступом делается вручную через файл id_ed25519.pub и, при необходимости, через переменные окружения HBBS_HTTP_TOKEN для базового REST API самого hbbs. Для парка в 5-20 машин этого обычно достаточно, для крупного парка с ролями пользователей стоит присмотреться к Pro или к готовым обёрткам вроде rustdesk-api от сообщества.

Диагностика и типичные проблемы

Клиент показывает «Connecting…» и обрывается. Чаще всего не открыт UDP 21116 — проверьте с внешней машины:

nc -vzu ваш-ip 21116

Если TCP-часть (21115, 21116) проходит, а соединение всё равно не устанавливается напрямую и всегда идёт через relay — это нормальное поведение при симметричном NAT на одной из сторон, тут поможет только relay (hbbr), а не настройка сервера.

После перезапуска контейнера все клиенты отвалились с ошибкой ключа. Почти всегда причина — том ./data:/root не был примонтирован при первом деплое (например, тестировали командой docker run без -v), и при пересоздании контейнера hbbs сгенерировал новую пару ключей. Проверьте, что docker compose config показывает нужный volume, и обновите ключ на клиентах из актуального id_ed25519.pub.

Relay работает, но с задержками и рывками видео. Проверьте загрузку исходящего канала сервера:

docker stats rustdesk-hbbr

Если CPU или сеть контейнера упираются в потолок при нескольких одновременных сессиях — это повод расширить тариф VPS по CPU/каналу, а не перенастраивать сам RustDesk.

Логи ничего не показывают. По умолчанию verbose-логирование выключено. Добавьте переменную окружения в оба сервиса для диагностики:

environment:
  - RUST_LOG=info

и пересоздайте контейнеры (docker compose up -d --force-recreate), после чего смотрите docker compose logs -f.

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