MAATRIX / Блог / Как установить и настроить RustDesk на VPS

Как установить и настроить RustDesk на VPS

MAATRIX

Публичный relay-сервер RustDesk (rustdesk.com) бесплатный, но соединение через него часто упирается в очередь и не самую высокую скорость, а трафик идёт через чужую инфраструктуру. Если вы администрируете десяток машин клиентов или просто не хотите, чтобы ID и ключи шифрования проходили через сторонний сервер — поднимаете свой relay на VPS за 15-20 минут. Дальше пошагово: подготовка сервера, установка hbbs/hbbr в Docker и без него, настройка клиентов и типичные грабли с портами.

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

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Что даёт свой сервер и что для этого нужно

RustDesk-сервер состоит из двух процессов:

  • hbbs (ID/rendezvous server) — регистрирует ID устройств, помогает установить прямое P2P-соединение (NAT traversal).
  • hbbr (relay server) — если прямое соединение не удалось (оба клиента за симметричным NAT), трафик идёт транзитом через него.

Оба ставятся на один VPS одной командой. Для полноценной работы нужен сервер с белым IP (обязательно — без NAT со стороны провайдера) и открытыми портами наружу. Требования по железу минимальные: 1 vCPU и 512 МБ-1 ГБ RAM хватает на десятки одновременных сессий, relay-трафик — это в первую очередь пропускная способность канала, а не CPU. Для стабильной работы под нагрузкой закладывайте канал с запасом — если через сервер одновременно идёт несколько активных сессий с передачей файлов или видео, трафик суммируется.

Из локаций логично выбирать сервер географически ближе к тем, кто будет подключаться: для доступа к машинам в России и СНГ подойдёт RU-локация, для команд в Европе/США — UK или US.

Подготовка VPS: домен (опционально) и порты

Домен не обязателен — можно работать по IP, — но с ним удобнее: не придётся переписывать конфиги клиентов при смене сервера, и вы получите TLS на веб-порт, если решите пробросить веб-клиент. Если решите привязать домен, разберитесь заранее с настройкой домена и DNS — A-запись должна указывать на IP VPS.

RustDesk-серверу нужны такие порты:

ПортПротоколКомуНазначение
21115TCPhbbsNAT type test
21116TCP + UDPhbbsОсновной канал, регистрация ID и сигналинг
21117TCPhbbrRelay-трафик
21118TCPhbbsВеб-клиент (опционально)
21119TCPhbbrRelay для веб-клиента (опционально)

Если веб-клиент не нужен — 21118 и 21119 можно не открывать вовсе, это снижает поверхность атаки. Открываем оставшиеся порты через ufw:

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw enable

Если firewall на сервере ещё не настроен вообще — сначала пройдите базовую настройку по статье про UFW на VPS, а потом добавляйте перечисленные правила поверх неё. Не забудьте, что кроме ufw порты может резать firewall на стороне облачного провайдера (security group) — их тоже нужно открыть отдельно.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

Установка RustDesk Server через Docker Compose

Это самый быстрый и предсказуемый способ — обновления сводятся к смене тега образа. Если Docker ещё не стоит, поставьте его по инструкции для Ubuntu 24.04 (или AlmaLinux/Debian, в зависимости от вашей ОС), затем создайте рабочую директорию:

mkdir -p ~/rustdesk-server/data
cd ~/rustdesk-server

Файл docker-compose.yml:

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: hbbs
    command: hbbs -r your.domain.or.ip:21117
    volumes:
      - ./data:/root
    network_mode: host
    restart: unless-stopped
    depends_on:
      - hbbr

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

Замените your.domain.or.ip на реальный домен или белый IP вашего сервера — это адрес, по которому hbbs будет говорить клиентам искать relay. network_mode: host тут осознанный выбор: RustDesk активно использует UDP и точный набор портов, а host-режим избавляет от возни с проброской каждого порта в Docker.

Поднимаем:

docker compose up -d
docker compose logs -f

В логах hbbs при первом старте будет сообщение о генерации пары ключей — сохраните их сразу:

cat data/id_ed25519.pub

Это и есть Key, который нужно будет вписать в настройки каждого клиента. Приватный ключ (id_ed25519) с сервера никуда не уходит — не публикуйте и не удаляйте этот файл, при потере ключа все клиенты придётся перенастраивать заново.

Установка без Docker: systemd-сервис

Если Docker на сервере принципиально не нужен (например, это выделенная под RustDesk минимальная машина), можно поставить бинарники напрямую. Скачайте актуальный релиз с GitHub (проверьте на странице релизов rustdesk/rustdesk-server архитектуру — для большинства VPS это x86_64-unknown-linux-gnu):

cd /opt
sudo mkdir rustdesk-server && cd rustdesk-server
sudo wget https://github.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-x86_64.zip
sudo unzip rustdesk-server-linux-x86_64.zip
sudo chmod +x hbbs hbbr

Юнит для hbbs (/etc/systemd/system/hbbs.service):

[Unit]
Description=RustDesk ID/Rendezvous Server
After=network.target

[Service]
Type=simple
ExecStart=/opt/rustdesk-server/hbbs -r your.domain.or.ip:21117
WorkingDirectory=/opt/rustdesk-server
User=root
Restart=on-failure

[Install]
WantedBy=multi-user.target

Аналогично для hbbr (/etc/systemd/system/hbbr.service), только ExecStart=/opt/rustdesk-server/hbbr. Затем:

sudo systemctl daemon-reload
sudo systemctl enable --now hbbs hbbr
sudo systemctl status hbbs hbbr

Ключи в этом случае генерируются в рабочей директории (/opt/rustdesk-server/id_ed25519.pub) — команда та же, cat id_ed25519.pub.

Оба варианта равнозначны по функциональности. Docker удобнее для обновлений и переезда на другой сервер (достаточно скопировать папку data), systemd — чуть меньше накладных расходов и понятнее логи через journalctl -u hbbs -f, если Docker в принципе не хочется держать на машине.

Настройка клиентов: подключение к своему серверу

На каждом устройстве, которое должно ходить через ваш сервер, открываете RustDesk → значок настроек (три точки) → NetworkID/Relay Server, и в открывшемся окне указываете:

  • ID Server — IP или домен вашего VPS.
  • Relay Server — обычно тот же адрес (можно оставить пустым, тогда возьмётся значение ID Server).
  • API Server — можно оставить пустым для базовой настройки без веб-панели.
  • Key — содержимое файла id_ed25519.pub, полностью, одной строкой.

После сохранения ID устройства в интерфейсе RustDesk изменится — это нормально, теперь он выдан вашим hbbs, а не публичным сервером. Чтобы не прописывать эти четыре поля вручную на каждой машине, в настройках есть кнопка экспорта конфигурации в виде текстовой строки (Export Config) — её можно один раз сгенерировать и раздать остальным участникам через защищённый канал, а не по почте в открытом виде.

Проверка, что всё работает: с двух разных устройств, настроенных на ваш сервер, попробуйте подключиться друг к другу по ID. Если соединение не устанавливается — в 9 случаях из 10 дело в закрытом порте 21116/udp: NAT traversal у RustDesk сильно зависит именно от UDP, TCP-порта одного недостаточно.

Безопасность: ключи, доступ и ограничение портов

Главная защита в этой схеме — сам ключ id_ed25519. Без него подключиться к вашему hbbs и зарегистрировать чужой ID нельзя, но это не значит, что сервер можно оставлять полностью открытым:

  • Держите SSH-доступ на сервер по ключу, а не по паролю — это отдельная база безопасности сервера, разбирали подробно здесь.
  • Настройте fail2ban для защиты SSH от перебора — сам RustDesk-протокол fail2ban не фильтрует, но брутфорс по SSH на том же сервере остаётся стандартным риском; инструкция по установке.
  • Если сервер обслуживает закрытый круг лиц (например, только вашу команду), имеет смысл ограничить доступ к портам 21115-21119 конкретными IP или VPN-подсетью в ufw вместо 0.0.0.0/0 — тогда даже перебор ID снаружи станет невозможен физически.
  • Ротация ключа — при подозрении на утечку удалите id_ed25519* из рабочей директории и перезапустите hbbs: сгенерируется новая пара, но тогда все клиенты придётся перенастроить с новым Key.
  • Публичный веб-клиент (порты 21118/21119) добавляет поверхность атаки — включайте его только если реально нужен доступ через браузер, и по возможности заведите перед ним reverse-proxy с TLS.

Отдельно: RustDesk по умолчанию шифрует сессию end-to-end, relay видит только зашифрованный поток, а не содержимое экрана — это плюс self-hosted и публичного сервера одинаково, тут ничего дополнительно настраивать не нужно.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.

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

Обязательно ли открывать все пять портов?

Нет, 21118 и 21119 нужны только для веб-клиента в браузере. Для десктопных и мобильных приложений RustDesk достаточно 21115-21117 и 21116/udp.

Можно ли использовать один VPS для relay и других задач одновременно?

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

Почему клиенты видят друг друга, но экран не передаётся, или соединение постоянно рвётся?

Чаще всего это закрытый 21116/udp на файрволе провайдера (не ufw, а именно security group облака) — проверьте оба уровня фильтрации отдельно.

Нужен ли IPv6?

Не обязательно, RustDesk прекрасно работает по IPv4. Если у сервера есть и IPv6, и хочется его тоже использовать — hbbs подхватит доступные интерфейсы автоматически в режиме network_mode: host.

Как обновить сервер без потери ключей?

В Docker-варианте — docker compose pull && docker compose up -d, ключи в volume ./data не трогаются. В systemd-варианте — скачать новый бинарник поверх старого и перезапустить сервисы, файлы ключей лежат отдельно и не перезаписываются.

Что будет, если сервер уйдёт в даунтайм?

Активные сессии оборвутся, но никакие данные не теряются — при следующем запуске hbbs клиенты снова смогут подключаться с теми же ID и Key, поскольку вся привязка идёт через сохранённый ключ, а не через какое-то внешнее состояние.

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

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →