Свой сервер удалённого доступа: разбираем RustDesk по деталям — от шести портов до ключа

Удалённый доступ к своим же машинам — та область, где чужой сервер посередине раздражает сильнее всего: чужая инфраструктура знает, какие у вас компьютеры, когда вы к ним подключаетесь и с каких адресов. RustDesk эту проблему решает тем, что серверную часть можно полностью забрать себе, и стоит она ровно один дешёвый VPS.

Загвоздка в том, что установка выглядит обманчиво простой. Скопировал compose-файл, открыл диапазон портов, вставил ключ в клиент — работает. А потом выясняется, что весь трафик почему-то идёт через ретранслятор, что вебсокет-порты торчат наружу и что при перезагрузке контейнера все клиенты отвалились.

Разберём инсталляцию по деталям: чем занимаются два демона, за что отвечает каждый из шести портов, откуда берётся ключ и что именно написано в официальной документации про заголовки X-Real-IP. Заодно посмотрим на превью-сборку 1.4.9, где 14 августа появился unattended-доступ на Wayland.

Часть 1. Два демона: кто ищет, а кто передаёт

RustDesk-сервер — это не одна программа, а два независимых бинарника (плюс утилита rustdesk-utils):

• hbbs — сервер идентификаторов и рандеву. Клиенты регистрируют на нём свой числовой ID, шлют heartbeat, здесь же происходит определение типа NAT и сведение двух клиентов друг с другом.
• hbbr — ретранслятор. Включается только тогда, когда прямое соединение между клиентами поднять не удалось.

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

Именно поэтому на VPS с 1 vCPU и символическим каналом RustDesk обычно живёт спокойно — ровно до момента, пока обе стороны не окажутся за симметричным NAT или CGNAT. Тогда весь видеопоток пойдёт через ретранслятор, и внезапно окажется, что 100 Мбит/с на VPS были не бесконечными.

Часть 2. Шесть портов, и один из них про UDP

Самая частая ошибка при развёртывании — открыть диапазон TCP и забыть про UDP. После этого клиенты видят друг друга, соединение устанавливается, но всегда через ретранслятор: пробивка NAT работает по UDP.

Часть 3. Развёртывание в Docker

Официальный образ — rustdesk/rustdesk-server. Минимальный docker-compose.yml из документации:

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

Тот же результат без compose:

sudo docker run --name hbbs -v ./data:/root -td --net=host \
  --restart unless-stopped rustdesk/rustdesk-server hbbs

sudo docker run --name hbbr -v ./data:/root -td --net=host \
  --restart unless-stopped rustdesk/rustdesk-server hbbr

Здесь есть две неочевидные детали.

Почему network_mode: host. Пробивке NAT нужно, чтобы сервер видел реальные адреса и порты клиентов. Классический bridge с -p 21116:21116/udp подменяет источник, и определение типа NAT начинает врать. Плата за это — контейнеры занимают порты на самом хосте, так что развести две инсталляции на одной машине без дополнительных приседаний не выйдет.

Каталог ./data. В него ложатся база SQLite и, главное, пара ключей. Если смонтировать сюда tmpfs или забыть про volume, при каждом перезапуске сервер будет генерировать новый ключ, а все клиенты — отваливаться с ошибкой соединения.

Часть 4. Ключ: пропуск, а не просто галочка «шифрование»

При первом запуске hbbs создаёт пару ключей и кладёт их в рабочий каталог:

ls -1 ./data
# id_ed25519      — приватный, остаётся на сервере
# id_ed25519.pub  — публичный, его вводят в клиенте
# db_v2.sqlite3   — база
cat ./data/id_ed25519.pub

Содержимое id_ed25519.pub — та самая строка, которую в клиенте вставляют в поле Key.

Часть 5. Настройка клиента

В клиенте (Настройки → Сеть, требует повышения прав) заполняются четыре поля:

• ID Server — обязательное. Хост или IP вашего hbbs, при желании с портом: srv.example.com или srv.example.com:21116.
• Key — обязательное. Содержимое id_ed25519.pub.
• Relay Server — обычно можно не заполнять: клиент узнаёт адрес ретранслятора от hbbs.
• API Server — для OSS-сборки не нужен; он требуется для входа в аккаунт и веб-консоли, то есть для Pro.

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

rustdesk.exe --config <config-string>

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

Часть 6. Когда трафик идёт мимо сервера, а когда через него

По умолчанию клиенты пытаются договориться напрямую и переключаются на hbbr только при неудаче. Иногда прямое соединение нежелательно — например, когда не хочется светить домашний IP перед тем, кому вы даёте доступ. Для этого есть переменная окружения:

    environment:
      - ALWAYS_USE_RELAY=Y

С ней весь трафик пойдёт через ретранслятор всегда, даже если прямой канал возможен. Это стоит осознанного решения: латентность вырастет, а исходящий трафик VPS будет расходоваться на каждый сеанс. На дешёвом хостинге с лимитом трафика полноценная удалёнка в режиме «всегда relay» способна съесть месячную квоту заметно быстрее, чем кажется.

Часть 7. Файрвол и одна строчка в доках, которую все проматывают

Базовые правила из официальной инструкции:

ufw allow 21114:21119/tcp
ufw allow 21116/udp
sudo ufw enable

А вот дальше в документации идёт предупреждение, которое стоит прочитать целиком: при включённом WebSocket (порты 21118/21119) hbbs и hbbr доверяют заголовкам X-Real-IP и X-Forwarded-For во входящих WebSocket-соединениях.

Часть 8. Что там с Wayland и превью-сборкой 1.4.9

Теперь про повод. По сообщению официального блога RustDesk от 14 августа 2026 года, в превью-сборке 1.4.9 появился unattended-доступ на Wayland: подключение без ручного подтверждения на той стороне, работа с несколькими мониторами и доступ к экрану входа после перезагрузки.

Ограничения на сегодня, тоже по официальному анонсу:

• сборка отдельная, превью, в стандартные релизы это ещё не приехало;
• поддерживаются только системы на базе Debian/Ubuntu архитектуры x86_64;
• Fedora и Arch заявлены в планах.

Почему это вообще новость: в Wayland нет привычного по X11 глобального доступа к экрану и вводу, всё идёт через порталы и требует сессии с интерактивным подтверждением. Именно поэтому «подключиться к машине, за которой никого нет» долгое время у большинства решений либо не работало, либо работало через возврат на X11.

Часть 9. Где заканчивается бесплатная версия

Честная граница, чтобы не было разочарований после установки:

• веб-консоль на 21114, учётные записи, адресная книга с общим доступом, генератор кастомных клиентов, SSO и журнал сессий — это Pro;
• в OSS вы получаете рабочий rendezvous и ретранслятор, шифрование по ключу и всё, что делает клиент, — но управление парком машин остаётся на вас;
• обновления клиентов на всех машинах в OSS придётся катать самостоятельно.

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

Источники

• Официальная документация: rustdesk.com/docs — self-host, OSS, Docker
• rustdesk.com/docs — установка сервера OSS и правила файрвола
• rustdesk.com/docs — настройка клиента для своего сервера
• Блог RustDesk: unattended remote access on Wayland, 14 августа 2026
• Релизы клиента RustDesk на GitHub