14 августа RustDesk выложил превью-сборку 1.4.9, в которой появился настоящий unattended-доступ на Wayland — подключение к машине, за которой никого нет, включая экран логина после перезагрузки. Новость сама по себе небольшая, но она хорошо напоминает, зачем вообще держать RustDesk у себя: чтобы удалённый доступ к домашним и рабочим машинам не зависел от чужой инфраструктуры и чужого настроения.
Проблема в том, что документация по самохостингу разбросана по десятку страниц, и в итоге типовая установка выглядит как «скопировал compose с форума, вроде подключается». Ниже — собранное в одном месте: что делают два демона, за что отвечает каждый из шести портов, откуда берётся ключ, что открывать на файрволе и где в официальных доках спрятано предупреждение о подделке IP.
Кому пригодится: тем, у кого дома NAS, мини-ПК или домашняя лаборатория, и нужно надёжно попадать на них с ноутбука; тем, кто помогает родственникам с компьютером; тем, кто не хочет, чтобы идентификаторы и трафик проходили через публичные серверы вендора.
Часть 1. Два демона: кто ищет, а кто передаёт
RustDesk-сервер — это не одна программа, а два независимых бинарника (плюс утилита rustdesk-utils):
- hbbs — сервер идентификаторов и рандеву. Клиенты регистрируют на нём свой числовой ID, шлют heartbeat, здесь же происходит определение типа NAT и сведение двух клиентов друг с другом.
- hbbr — ретранслятор. Включается только тогда, когда прямое соединение между клиентами поднять не удалось.
Ключевой момент, который стоит понять до установки: в нормальном сценарии ваш сервер видит только служебный обмен, а сам поток рабочего стола идёт напрямую между машинами. Сервер становится узким местом по трафику только в режиме ретрансляции.
Именно поэтому на VPS с 1 vCPU и символическим каналом RustDesk обычно живёт спокойно — ровно до момента, пока обе стороны не окажутся за симметричным NAT или CGNAT. Тогда весь видеопоток пойдёт через ретранслятор, и внезапно окажется, что 100 Мбит/с на VPS были не бесконечными.
Если вы уже читали разбор про серый IP и CGNAT — Серый IP и CGNAT: пять маршрутов к домашнему серверу — большой гайд — то узнаете половину механики: пробивка NAT здесь ровно та же, что в WireGuard-подобных решениях, только роль координатора играет hbbs.
Часть 2. Шесть портов, и один из них про UDP
Самая частая ошибка при развёртывании — открыть диапазон TCP и забыть про UDP. После этого клиенты видят друг друга, соединение устанавливается, но всегда через ретранслятор: пробивка NAT работает по UDP.
| Порт | Демон | Назначение |
|---|---|---|
| 21114/tcp | hbbs | веб-консоль (только Pro-версия) |
| 21115/tcp | hbbs | тест типа NAT |
| 21116/tcp | hbbs | регистрация ID и heartbeat |
| 21116/udp | hbbs | пробивка NAT и установка соединения |
| 21117/tcp | hbbr | ретрансляция |
| 21118/tcp | hbbs | WebSocket для веб-клиента |
| 21119/tcp | hbbr | WebSocket-ретрансляция для веб-клиента |
21116 нужен и в TCP, и в UDP — это два разных канала на одном номере. Если в правилах файрвола описан только TCP-диапазон 21114:21119, пробивка NAT молча не заработает, и вы будете платить трафиком за каждую сессию.
Часть 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.
Публичный ключ выполняет здесь двойную роль: он и обеспечивает шифрование, и фактически работает пропуском. Клиент без правильного ключа не сможет пользоваться вашим ретранслятором. Если вы выложите адрес сервера и ключ в общий чат, вы раздадите посторонним свой канал — и трафик пойдёт за ваш счёт.
Приватный id_ed25519 не должен уезжать никуда за пределы сервера и не должен попадать в git вместе с compose-файлом.
Часть 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-соединениях.
Не выставляйте 21118/21119 напрямую в интернет. Любой, кто до них дотянется, может подделать эти заголовки и выдать себя за произвольный IP-адрес — со всеми последствиями для логов, бана и учёта.
Как правильно:
- если веб-клиент не нужен — держите 21118 и 21119 закрытыми, они не требуются для обычных десктопных клиентов;
- если нужен — публикуйте их только через реверс-прокси, который сам проставляет
X-Real-IP, а на файрволе разрешайте доступ к этим портам только с адреса прокси.
Часть 8. Что там с Wayland и превью-сборкой 1.4.9
Теперь про повод. По сообщению официального блога RustDesk от 14 августа 2026 года, в превью-сборке 1.4.9 появился unattended-доступ на Wayland: подключение без ручного подтверждения на той стороне, работа с несколькими мониторами и доступ к экрану входа после перезагрузки.
Ограничения на сегодня, тоже по официальному анонсу:
- сборка отдельная, превью, в стандартные релизы это ещё не приехало;
- поддерживаются только системы на базе Debian/Ubuntu архитектуры x86_64;
- Fedora и Arch заявлены в планах.
Стабильным релизом на момент публикации остаётся 1.4.7 от 2 июня 2026 года. Превью-сборка — это то, что ставят на тестовую машину, а не на сервер, к которому вы приезжаете за доступом из отпуска. Заявления вендора о том, «как теперь всё хорошо на Wayland», независимо пока не проверялись.
Почему это вообще новость: в 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
Чем закрываете удалённый доступ к домашним машинам: RustDesk со своим сервером, WireGuard плюс обычный RDP/VNC, или чем-то вроде Apache Guacamole? И если гоняли RustDesk через ретранслятор — сколько трафика съедал час работы?