Как поднять свой RustDesk relay сервер на VPS

Что такое self-hosted relay-сервер RustDesk

Self-hosted relay-сервер RustDesk представляет собой два демона на одном VPS. hbbs — это сервер идентификации и установления соединения (rendezvous server): он регистрирует ID каждого клиента и связывает двух клиентов между собой. hbbr — это relay-сервер: он передает байты сессии, но только для тех соединений, которые не удалось установить напрямую. Большинство руководств предлагают установить оба компонента, настроить сопряжение и на этом остановиться. Далее описана оставшаяся часть работы: ключ, который служит средством контроля доступа, порты, обновление и пропускная способность.

Оба демона поставляются в одном образе, rustdesk/rustdesk-server, и оба считывают одну и ту же пару ключей Ed25519 из одной директории. Ed25519 — это схема подписи с открытым ключом. Эта пара ключей определяет, с какими клиентами будет взаимодействовать ваш сервер, при этом никакой базы данных пользователей за ней не стоит.

hbbs и hbbr: какой демон расходует трафик

Трафик hbbs невелик и постоянен: это регистрация ID и сигналы heartbeat, а также короткий обмен данными для знакомства двух узлов. Он работает постоянно и почти не потребляет ресурсов.

Трафик hbbr — это сама сессия. Кадры изображения передаются в одну сторону, сигналы клавиатуры и мыши — в другую, при этом каждый ретранслируемый байт сначала поступает на ваш VPS, а затем покидает его. Если ваш провайдер учитывает только исходящий трафик, ретранслируемая сессия стоит вам объема переданных данных. Если учитывается суммарный трафик, стоимость удваивается.

Ретрансляция — это резервный, а не основной путь. hbbs сначала пытается соединить двух клиентов напрямую, используя hole punching через любой NAT (network address translation), находящийся перед каждым из них. Если это удается, сессия никогда не проходит через hbbr, и ваш лимит трафика остается нетронутым. Когда одна из сторон находится за NAT, который назначает новый порт для каждого направления, или за межсетевым экраном, блокирующим пробитый путь, сессия переключается на hbbr, и каждый кадр проходит через ваш VPS.

Одна переменная окружения лишает вас выбора. ALWAYS_USE_RELAY=Y в hbbs принудительно направляет все сессии через hbbr. Документация RustDesk приводит этот параметр в одном из примеров Compose, поэтому его часто копируют. Это делает соединения более предсказуемыми, но создает реальный расход исходящего трафика. Устанавливайте этот параметр осознанно, а не просто копируя примеры.

Какие порты необходимы для self-hosted сервера RustDesk

Указанные ниже номера портов были проверены на соответствие документации сервера RustDesk и репозиторию rustdesk-server 17 августа 2026 года.

• TCP 21115, на hbbs: тест типа NAT.
• UDP 21116, на hbbs: регистрация ID и heartbeat. Без этого клиент не перейдет в онлайн, независимо от того, какие еще порты открыты.
• TCP 21116, на hbbs: TCP hole punching и служба соединений.
• TCP 21117, на hbbr: ретранслятор (relay). Это порт, через который передаются данные сессии, именно он потребляет трафик.
• TCP 21118 на hbbs и TCP 21119 на hbbr: WebSocket, используется браузерным клиентом. Оставьте оба закрытыми, если не используете его.
• TCP 21114: веб-консоль в RustDesk Server Pro. Версия с открытым исходным кодом не прослушивает этот порт.

Установка hbbs и hbbr с фиксацией тега образа

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

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

mkdir -p ~/rustdesk
cd ~/rustdesk
# save the block above as ~/rustdesk/compose.yml before this line
sudo docker compose up -d
sudo docker compose ps

Оба сервиса должны считывать running. Убедитесь в наличии слушающих портов, прежде чем настраивать межсетевой экран.

sudo ss -tlnp | grep -E ':2111[5-7]'
sudo ss -ulnp | grep ':21116'

Вы должны увидеть TCP-сокеты на портах 21115, 21116 и 21117, а также UDP-сокет на порту 21116. Отсутствие строки UDP означает, что hbbs не запущен, так как именно этот порт используется клиентами для регистрации.

Четыре параметра в этом файле выбраны намеренно. Используется тег 1.1.16 — актуальный релиз на август 2026 года, выпущенный 20 июля 2026 года, вместо latest. Использование latest означает применение последней версии, и через полгода docker compose pull может привести к установке образа, который вы не тестировали. Параметр network_mode: "host" привязывает порты напрямую к интерфейсам хоста, что рекомендуется в документации RustDesk и определяет логику работы вашего межсетевого экрана. Параметр ./data:/root проецирует рабочую директорию образа на хост, чтобы пара ключей сохранялась в месте, доступном для резервного копирования. Параметр hbbr -k _ — это единственное отличие от примера из официальной документации, так как настройки по умолчанию оставляют ваш релей открытым для всех. Если вы новичок в Compose, в статье запуск Docker Compose на VPS описаны формат файла и команды управления жизненным циклом.

Если hbbr когда-либо будет перенесен на другой сервер, необходимо указать hbbs, где он находится: передайте аргумент -r relay.example.com:21117 или установите переменную окружения RELAY-SERVERS. При работе на одном сервере это не требуется.

Пара ключей Ed25519 как средство контроля доступа

При первом запуске hbbs генерирует id_ed25519 и id_ed25519.pub в своей рабочей директории. Благодаря указанному выше монтированию, оба файла появятся на хост-системе.

ls -l ~/rustdesk/data/
sudo cat ~/rustdesk/data/id_ed25519.pub

Файл id_ed25519.pub содержит одну строку в формате base64. Эту строку необходимо вставить в поле Key на каждом клиенте. Файл id_ed25519 является закрытой частью пары и никогда не должен покидать сервер. Открытый ключ не является секретным, так как он в любом случае копируется в конфигурацию каждого клиента. Закрытый ключ — это секрет: любой, у кого он есть, может развернуть сервер, которому будут доверять ваши клиенты.

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

sudo tar czf ~/rustdesk-keys.tgz -C ~/rustdesk/data id_ed25519 id_ed25519.pub
sudo chmod 600 ~/rustdesk-keys.tgz

Скопируйте этот архив с сервера. Вот почему это важнее любого другого шага. Удалите ~/rustdesk/data или выполните переустановку на новом VPS, не скопировав этот файл, и hbbs сгенерирует новую пару ключей при следующем запуске. Все клиенты по-прежнему будут использовать старый открытый ключ, поэтому hbbs отклонит их подключение, и клиенты перейдут в офлайн. Выполните sudo cat ~/rustdesk/data/id_ed25519.pub и сравните результат с полем Key на любом клиенте: строки больше не совпадают, и именно это несоответствие является причиной сбоя. Исправление потребует ручного редактирования настроек на каждой машине, включая те, к которым вы подключались через RustDesk.

Ключ — это не пароль сессии, и их путаница приводит к тому, что пользователи пропускают один из этапов настройки. Ключ определяет, с какими клиентами будет взаимодействовать ваш сервер. Постоянный пароль или одноразовый код на управляемой машине определяет, кто может открыть сессию на этом устройстве. Вам нужны оба компонента, и наличие одного не компенсирует слабость другого.

Почему открытый ретранслятор без аутентификации представляет проблему

По умолчанию hbbr не выполняет никаких проверок. В документации по настройке RustDesk прямо указано: пустой ключ позволяет клиентам без соответствующего ключа использовать ретранслятор. Пустое значение по умолчанию оставлено для того, чтобы новые пользователи не сталкивались с ошибками несовпадения ключей при первом запуске. Цена этого удобства заключается в том, что любой, кто обнаружит ваш адрес на TCP 21117, сможет пропускать свой сессионный трафик через ваш VPS, расходуя ваш лимит передачи данных и используя ваш IP-адрес.

command: hbbr -k _ устраняет эту проблему. Аргумент _ указывает hbbr загрузить пару ключей из рабочей директории, и поскольку оба контейнера используют один и тот же смонтированный ./data, это та самая пара, которую hbbs уже сгенерировал. Ничего не нужно копировать вручную, поэтому расхождения невозможны.

Общий том — это та часть, с которой пользователи чаще всего ошибаются. Если предоставить hbbr собственную директорию, он сгенерирует другую пару ключей. В результате hbbs и hbbr перестанут «понимать» друг друга, все сессии через ретранслятор будут завершаться ошибкой, а прямые сессии продолжат работать. Симптом сбивает с толку: RustDesk подключается к одним узлам, но не к другим, в зависимости от того, удалось ли выполнить hole punching. Один ls -l ~/rustdesk/data/, показывающий наличие единственной пары id_ed25519, позволяет исключить эту ошибку.

Настройка клиентов для работы с вашим сервером

На каждой машине откройте RustDesk, перейдите в Settings, затем в Network и выберите ID/Relay Server.

• ID Server: имя вашего хоста, например rustdesk.example.com. Клиент использует порт 21116, если вы не укажете другой.
• Relay Server: оставьте пустым, если hbbr запущен на том же хосте, что и hbbs.
• API Server: оставьте пустым. В версии с открытым исходным кодом этот сервер не предусмотрен.
• Key: строка в формате base64 из id_ed25519.pub. Вставьте её без изменений, не добавляя пробелов в конце.

После этого в главном окне должно появиться сообщение о готовности клиента. Если этого не произошло, значит, пакеты UDP 21116 не доходят до hbbs, так как регистрация и проверка активности (heartbeat) выполняются только по протоколу UDP, и без них ID не переходит в статус онлайн.

Ограничение портов, чтобы ретранслятор не стал открытым сервисом

Поскольку контейнеры используют сетевой режим host, перед ними нет правил Docker NAT, поэтому правила ufw применяются так, как вы ожидаете.

sudo ufw allow 22/tcp
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udp
sudo ufw enable
sudo ufw status numbered

Добавляйте 21118:21119/tcp только в том случае, если вы используете браузерный клиент. Держите вторую SSH-сессию открытой во время включения ufw, чтобы ошибка в правиле SSH не заблокировала вам доступ к серверу. В Основы работы с межсетевым экраном ufw для VPS описаны политики по умолчанию и порядок применения правил.

Теперь о ловушке. Если вы переключитесь на публикацию портов с помощью блока ports:, который используется в альтернативном примере образа супервизора RustDesk, Docker запишет собственные правила DNAT. Пакеты будут достигать контейнера, минуя цепочку, в которой находятся ваши правила ufw. В этом случае запрет ufw на порт 21117 не сработает, и ретранслятор окажется открытым для интернета, несмотря на то, что ufw status утверждает обратное. В Публикация портов Docker в обход ufw объясняется порядок цепочек. Сетевой режим host полностью исключает эту проблему. Если вы всё же публикуете порт, привязывайте его к одному адресу, как в "127.0.0.1:21118:21118" за обратным прокси-сервером.

Ограничение по исходному адресу работает только тогда, когда ваши клиенты имеют статические адреса.

sudo ufw allow from 203.0.113.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 21116 proto udp

Ноутбуки в сетях отелей не имеют статических адресов, именно поэтому ключ на hbbr здесь выполняет гораздо больше реальной работы, чем межсетевой экран.

Обновление стека с сохранением ключа

Ключ находится в bind mount, а не внутри контейнера, поэтому обновление безопасно, пока вы не трогаете ./data.

1. Сначала сделайте резервную копию каталога с данными: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. Ознакомьтесь с примечаниями к выпуску для нового тега на странице релизов rustdesk-server.
3. Отредактируйте compose.yml и измените обе строки image: на новый тег.
4. Выполните sudo docker compose pull, затем sudo docker compose up -d.
5. Выполните sudo cat ~/rustdesk/data/id_ed25519.pub и убедитесь, что строка совпадает с той, которая уже установлена у ваших клиентов.

Шаг 5 является критически важным, так как изменение ключа происходит на сервере незаметно, но мгновенно нарушает работу всех клиентов. Откат выполняется путем возврата старого тега и повторного запуска up -d. Это работает только в том случае, если вы зафиксировали версию: при использовании latest команда docker compose pull перенесла имя на новый образ, поэтому тега, указывающего на старый образ, больше не существует.

Обычно ключ теряется не из-за docker compose down, так как эта команда не затрагивает bind mount. Это происходит при миграции на новый VPS, если вы копируете только compose.yml. Копируйте ./data вместе с ним.

Мониторинг исходящего трафика при наличии лимита передачи данных

hbbr — единственный компонент этого стека, который может расходовать лимит трафика. Согласно FAQ RustDesk, одно ретранслируемое соединение при разрешении экрана 1920x1080 потребляет от 30 КБ/с до 3 МБ/с, а обычная офисная работа — около 100 КБ/с. Это опубликованные показатели для одной сессии, а не замеры вашей конкретной конфигурации. При расчете на 60 часов в месяц (по 2 часа в день) показатели выглядят следующим образом.

[
  {
    "label": "Low end, 30 KB/s",
    "gb_per_month": 6.5
  },
  {
    "label": "Office work, 100 KB/s",
    "gb_per_month": 21.6
  },
  {
    "label": "High end, 3 MB/s",
    "gb_per_month": 648
  }
]

При интенсивности офисной работы одна сессия расходует около 21.6 ГБ в месяц, что незаметно для любого тарифного плана. При максимальных опубликованных значениях те же 60 часов расходуют 648 ГБ, а две одновременные сессии с такой интенсивностью исчерпают лимит в 1 ТБ в течение месяца. Нижний предел составляет 6.5 ГБ. Гигабайты здесь считаются как 1000 МБ, что является стандартом для учета лимитов передачи данных.

docker stats не предоставит вам детализацию, так как контейнер, использующий host networking, разделяет пространство имен сети с хостом, поэтому его счетчики совпадают со счетчиками хоста. Работают два других инструмента. vnstat измеряет показатели всего сервера целиком:

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

«Весь сервер» означает именно весь сервер: если на этом VPS запущены другие процессы, передающие данные, например, self-hosted фотосерверы, которые каждую ночь загружают библиотеки с телефонов, их исходящий трафик попадет в ту же ежемесячную статистику, что и трафик реле.

Счетчик nftables позволяет измерить трафик конкретно для реле:

sudo nft add table inet relaymeter
sudo nft add chain inet relaymeter out '{ type filter hook output priority 0 ; }'
sudo nft add rule inet relaymeter out tcp sport 21117 counter
sudo nft list table inet relaymeter

Это правило не содержит вердикта, поэтому оно подсчитывает пакеты и байты, не влияя на правила доступа, и находится в отдельной таблице, чтобы не мешать работе ufw. Оно не является постоянным: добавьте эти же строки в /etc/nftables.conf, если хотите сохранить их после перезагрузки. Счетчик растет только во время активной ретрансляции сессии. Если счетчик продолжает расти, когда ни одна из ваших машин не подключена, это означает, что кто-то другой обнаружил ваше реле — именно этот случай призван предотвратить hbbr -k _.

В hbbr также есть лимиты скорости, которые можно уменьшить. Значение по умолчанию для SINGLE_BANDWIDTH составляет 128 Мбит/с на одно ретранслируемое соединение, а для TOTAL_BANDWIDTH — 1024 Мбит/с для всех соединений в сумме. Установка SINGLE_BANDWIDTH=8 ограничит одну сессию значением около 1 МБ/с. Это ограничивает скорость, а не месячный объем, поэтому рассматривайте это как способ предотвратить перегрузку канала одной сессией, а не как инструмент контроля бюджета.

Когда ретранслятор вообще не нужен

Для личного использования честный ответ заключается в том, что вам, возможно, ничего из этого не нужно. Объедините обе машины в mesh VPN и подключайтесь напрямую по адресу в туннеле. В этом случае не требуются hbbs, hbbr, исходящий трафик через ретранслятор и обновление контейнеров на VPS.

На машине, которой вы хотите управлять, включите прямой доступ по IP в настройках безопасности RustDesk. Поле порта по умолчанию имеет значение 21118. Перед попыткой подключения убедитесь, что порт прослушивается:

ss -tlnp | grep 21118

Затем подключайтесь к VPN-адресу этого узла вместо использования ID. В FAQ RustDesk указано, что в этом режиме соединение не шифруется, поэтому используйте его только внутри туннеля и никогда — через открытый интернет. Именно туннель обеспечивает шифрование.

Выбор зависит от того, кому принадлежат машины. Собственные hbbs и hbbr подходят, если вы обслуживаете чужие машины или работаете с людьми, которые не будут устанавливать VPN-клиент, так как с их стороны для настройки требуются только ID и пароль. Mesh VPN с прямым доступом по IP подходит, если все машины принадлежат вам и на них можно установить ключ. В статье сравнение WireGuard и Tailscale рассматриваются два основных способа построения такой сети, а в запуск удаленного рабочего стола на Linux VPS — другой случай, когда машина, к которой нужен доступ, сама является сервером.

FAQ

Все сессии RustDesk проходят через мой ретранслятор?

Нет. hbbs сначала пытается соединить два клиента напрямую, используя пробивку NAT (hole punching) перед каждым из них. Только те сессии, где это не удалось, переключаются на hbbr, и только они расходуют ваш трафик. Исключением является ALWAYS_USE_RELAY=Y в hbbs, которая принудительно направляет каждую сессию через hbbr, независимо от наличия прямого пути. Если эта переменная задана в вашем файле Compose, каждый байт каждой сессии будет учитываться в вашем счете за передачу данных.

Где хранится ключ сервера RustDesk и что делать, если я его потеряю?

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

Какие порты нужно открыть для собственного сервера RustDesk?

TCP 21115, 21116 и 21117, а также UDP 21116. hbbs использует 21115 для теста типа NAT, а 21116 — для регистрации ID и сигналов heartbeat по UDP, а также для пробивки NAT по TCP. hbbr использует 21117 для ретрансляции. TCP 21118 и 21119 — это порты WebSocket для браузерного клиента, поэтому оставьте их закрытыми, если вы его не используете. TCP 21114 относится к веб-консоли Pro, и для версии с открытым исходным кодом он не нужен.

Могут ли посторонние использовать мой собственный ретранслятор RustDesk?

Да, если вы запустите hbbr с конфигурацией по умолчанию. В документации RustDesk указано, что пустой ключ позволяет клиентам без соответствующего ключа использовать ретранслятор, поэтому любой, кто узнает ваше имя хоста и порт 21117, сможет пропускать трафик через ваш сервер. Запускайте hbbr с -k _, чтобы он загружал ту же пару ключей, которую hbbs сгенерировал в общем томе ./data. После этого только клиенты, настроенные с вашим открытым ключом, смогут использовать вас в качестве ретранслятора.