Клиент RustDesk показывает статус «Не готов, проверьте подключение» или соединение идёт через публичные ретрансляторы с низкой скоростью — типичный признак того, что собственный сервер не установлен или службы hbbs и hbbr запущены с ошибками. Настройка собственного сервера RustDesk решает обе проблемы: вы получаете контроль над инфраструктурой удалённого доступа и не зависите от публичных узлов.
Собственный сервер актуален для компаний, где трафик удалённых сессий не должен покидать периметр, и для пользователей, которым важны стабильность и скорость соединения. Ниже разберём архитектуру, установку на Linux, открытие портов, настройку ключей шифрования и подключение клиентов. Инструкция ориентирована на актуальные версии open-source сервера; детали могут отличаться в зависимости от версии, поэтому сверяйтесь с официальной документацией проекта.
Архитектура сервера RustDesk: hbbs и hbbr
Серверная часть RustDesk состоит из двух компонентов. hbbs — сервер идентификации (ID-сервер): он регистрирует клиентов, сопоставляет ID с адресами и организует пробив NAT. hbbr — сервер ретрансляции: через него проходит трафик, когда прямое P2P-соединение установить не удалось.
Оба процесса могут работать на одной машине. Минимальные требования скромные: подойдёт недорогой VPS с 1 vCPU и 1 ГБ ОЗУ, если только через ретранслятор не пойдёт тяжёлый видеотрафик множества одновременных сессий. Пропускная способность канала важнее процессора — именно она определяет качество картинки при ретрансляции.
- 🖥️ hbbs — регистрация клиентов, обнаружение, ключи шифрования
- 🔁 hbbr — ретрансляция трафика при невозможности P2P
- 🔑 Файлы ключей
id_ed25519иid_ed25519.pub— идентичность сервера - 🌐 Публичный IP или домен — обязательное условие для доступа клиентов извне
Какие порты нужно открыть
Частая причина неработающего сервера — закрытые порты на файрволе или в панели облачного провайдера. Клиенты используют как TCP, так и UDP, поэтому открывать нужно оба протокола там, где это требуется.
| Порт | Протокол | Служба | Назначение |
|---|---|---|---|
| 21115 | TCP | hbbs | Проверка типа NAT |
| 21116 | TCP/UDP | hbbs | Регистрация ID, heartbeat, пробив NAT |
| 21117 | TCP | hbbr | Ретрансляция трафика |
| 21118 | TCP | hbbs | Веб-клиент (опционально) |
| 21119 | TCP | hbbr | Веб-клиент, ретрансляция (опционально) |
Для базовой работы без веб-клиента достаточно портов 21115–21117. Порты 21118 и 21119 открывайте только если планируете подключаться через браузер. Проверить доступность портов снаружи можно командой nc -zv ваш_сервер 21116 с другой машины.
⚠️ Внимание: если UDP-порт 21116 закрыт, клиенты смогут зарегистрироваться по TCP, но P2P-соединения будут срываться на ретрансляцию — скорость заметно упадёт. Проверяйте оба протокола.
Установка сервера на Linux
Есть два основных способа развёртывания: через Docker и напрямую бинарными файлами. Docker-путь проще в обновлении и изоляции, ручная установка даёт больше контроля над службами systemd.
Для Docker достаточно двух контейнеров с пробросом портов и общим томом для ключей:
docker run -d --name hbbs -p 21115:21115 -p 21116:21116 -p 21116:21116/udp -p 21118:21118 -v $PWD/data:/root --net host rustdesk/rustdesk-server hbbsdocker run -d --name hbbr -p 21117:21117 -p 21119:21119 -v $PWD/data:/root --net host rustdesk/rustdesk-server hbbrПри ручной установке скачайте архив сервера со страницы релизов проекта, распакуйте и запустите оба бинарника. Для автозапуска создайте юниты systemd, чтобы службы поднимались после перезагрузки:
./hbbs
./hbbr
☑️ Проверка после установки
⚠️ Внимание: запускайте hbbs первым — hbbr при старте обращается к нему. Если запустить ретранслятор раньше ID-сервера, он может завершиться с ошибкой.
Ключи шифрования и принудительная проверка
При первом запуске hbbs генерирует пару ключей id_ed25519 (приватный) и id_ed25519.pub (публичный). Публичный ключ нужно скопировать в настройки каждого клиента — без него соединение не будет зашифровано ключом вашего сервера, а часть клиентов откажется подключаться, если на сервере включён режим обязательного ключа.
Принудительное использование ключа включается запуском hbbs с параметром -k _:
./hbbs -k _В этом режиме к серверу смогут подключиться только клиенты с правильным ключом — это закрывает доступ посторонним, даже если они знают адрес сервера. Скопируйте содержимое id_ed25519.pub до перезапуска служб: при случайном удалении ключей старые клиенты потеряют связь с сервером, и ключ придётся прописывать заново на каждом устройстве.
Подключение клиентов к своему серверу
На стороне клиента откройте настройки: Настройки → Сеть → Разблокировать сетевые настройки → ID/Ретрансляционный сервер. В поле «ID-сервер» укажите домен или IP вашей машины, в поле «Ключ» — содержимое файла id_ed25519.pub. Поле ретрансляционного сервера можно оставить пустым: клиент вычислит его автоматически по адресу ID-сервера.
После сохранения внизу окна клиента должен появиться статус «Готов». Если вместо этого видите «Не готов», проверьте по порядку: доступность порта 21116 по TCP и UDP, совпадение ключа, отсутствие опечаток в адресе. Логи сервера (в Docker — docker logs hbbs) покажут, доходят ли вообще запросы от клиента.
Типовые ошибки и их диагностика
Большинство проблем сводится к сети и ключам, а не к самому ПО. Разберём частые сценарии.
- 🔌 «Не готов, проверьте подключение» — недоступен порт 21116 или неверный адрес сервера
- 🐢 Медленное соединение — трафик идёт через ретранслятор, P2P не пробился; проверьте UDP 21116
- 🔐 «Key mismatch» — ключ на клиенте не совпадает с ключом сервера
- 📵 Клиент не виден в списке устройств — hbbs перезапустился с новыми ключами или клиент подключён к другому серверу
Диагностику начинайте с сервера: ss -tulpn | grep 211 покажет, какие порты реально слушаются. Затем с клиентской машины проверьте связность: telnet адрес 21116 для TCP и любой UDP-сканер для UDP. Если TCP доступен, а UDP нет — ищите проблему в правилах файрвола или NAT провайдера.
Почему P2P не устанавливается даже с открытыми портами
Пробив NAT зависит от типа NAT на обеих сторонах. Симметричный NAT (часто встречается у мобильных операторов и в корпоративных сетях) пробить сложно — в этом случае RustDesk автоматически уходит на ретрансляцию через hbbr. Это нормальное поведение, а не ошибка сервера.
Безопасность и обслуживание сервера
Сервер удалённого доступа — критичная точка инфраструктуры, поэтому минимальная гигиена обязательна. Ограничьте доступ к серверу по SSH ключами, обновляйте образы или бинарники RustDesk по мере выхода релизов и включите принудительный ключ -k _, чтобы чужие клиенты не могли использовать ваш сервер.
Дополнительно можно сменить стандартные порты на нестандартные — это не защита от целевой атаки, но снижает шум от массовых сканирований. Для мониторинга достаточно периодически проверять логи hbbs на предмет незнакомых ID и следить за нагрузкой на канал, если активно используется ретрансляция.
Часто задаваемые вопросы
Можно ли запустить сервер RustDesk на Windows?
Да, серверные бинарники доступны и для Windows, однако на практике чаще используют Linux или Docker — так проще обеспечить стабильную работу служб и автозапуск. Для Windows потребуется настроить запуск hbbs и hbbr как служб вручную или через планировщик.
Нужен ли домен или достаточно IP-адреса?
Достаточно статического публичного IP. Домен удобнее: при смене сервера не придётся перенастраивать клиентов, достаточно обновить DNS-запись. Динамический IP не подойдёт без привязки к DDNS.
Сколько клиентов выдержит один сервер?
Точных универсальных цифр нет — нагрузка зависит от числа одновременных сессий и доли трафика через ретранслятор. ID-сервер (hbbs) очень лёгкий, основная нагрузка ложится на канал при ретрансляции видео. Начните с минимального VPS и наблюдайте за загрузкой сети.
Что делать, если клиент пишет «Key mismatch»?
Сравните ключ в настройках клиента с содержимым файла id_ed25519.pub на сервере. Ключ должен совпадать полностью, без лишних пробелов и переносов строк. Если ключи на сервере пересоздавались, обновите ключ на всех клиентах.
Работает ли самостоятельный сервер без интернета, в локальной сети?
Да, сервер можно развернуть внутри LAN: клиенты указывают локальный адрес сервера и работают без выхода в интернет. Это удобный сценарий для изолированных корпоративных сетей.