
Удалённый доступ давно перестал быть корпоративной историей. Помочь родителям с настройками компьютера, достучаться до домашнего сервера из поездки, подключиться к рабочей машине с ноутбука: всё это сценарии, где нужен рабочий стол через интернет. TeamViewer и AnyDesk их закрывают, но работают через серверы своих компаний, а бесплатные тарифы ограничены то временем сессии, то числом устройств.
У RustDesk другой подход. Это программа удалённого доступа с открытым исходным кодом: лицензия AGPL-3.0, больше 120 тысяч звёзд на GitHub, клиенты для Windows, macOS, Linux, Android и iOS. Главное отличие в том, что серверную часть можно развернуть на своей машине. Тогда регистрация и сигнализация идут через ваш VPS, соединения шифруются вашим ключом, и никакая чужая подписка не решает, поработаете вы сегодня за чужим компьютером или нет.
Соберём свой сервер RustDesk на VPS через Docker Compose и доведём до рабочего состояния: откроем порты, получим ключ шифрования, настроим клиенты.
Что такое RustDesk и зачем свой сервер
По возможностям RustDesk сопоставим с привычными программами удалённого доступа: он показывает экран, передаёт управление мышью и клавиатурой, умеет передавать файлы и работать с телефона. Отличается архитектура. Проект изначально задумывался как решение для самостоятельного размещения, поэтому серверная часть у него открыта и документирована.
Серверы у проекта двух видов. RustDesk Server OSS это бесплатная открытая версия: ID-сервер и релей, которые настраиваются вручную. RustDesk Server Pro добавляет веб-консоль, вход через LDAP и OIDC, двухфакторную аутентификацию и управление парком устройств: это вариант для компаний, где техникой занимается выделенная команда и на счету сотни машин. Для личного использования и небольшой команды базовой версии хватает полностью: подключения, релей и шифрование в неё уже входят.
Свой сервер стоит поднимать, когда через удалённый доступ проходят рабочие данные и не хочется, чтобы они шли через инфраструктуру посторонней компании. Предсказуемость тоже важна: адреса и права устройств живут у вас, доступ не зависит от изменений чужого тарифа. А кому-то просто важно контролировать свой контур. Настройка разовая, дальше сервер работает сам.
Как работает RustDesk: ID-сервер и релей
Серверная часть состоит из двух процессов. hbbs держит реестр устройств: он ID-сервер, и каждый клиент RustDesk постоянно отмечается на нём, сообщая свой текущий адрес и порт. hbbr это релей: через него идёт трафик, когда напрямую соединиться не получилось.
Подключение выглядит так. Клиент на машине A спрашивает у ID-сервера адрес машины B и пробует соединиться напрямую, этот приём называется проколом NAT. В большинстве случаев он срабатывает, и данные идут между компьютерами, минуя сервер. Если прямой канал построить не удалось, например мешает строгий файрвол, соединение переводится на релей.
Из этой схемы следуют требования к портам. Серверу нужен публичный адрес и открытые порты: 21115 для проверки типа NAT, 21116 по TCP и UDP для регистрации устройств и прокола, 21117 для релея. Есть ещё порты 21118 и 21119: они нужны только веб-клиенту, в базовой настройке их лучше не открывать, подробнее ниже. Порт 21114 задействован только в Pro-версии.
Что понадобится для установки
Публичный VPS с Linux: подойдёт Ubuntu, Debian или другой привычный дистрибутив. Нужен Docker с плагином Compose, он ставится по официальной инструкции. Домен не обязателен, к серверу можно подключаться и по IP-адресу, но с именем удобнее: его проще запомнить и безболезненно перенести на другой сервер при переезде.
Железо особое не нужно: серверные процессы лёгкие, им хватает минимальной конфигурации VPS.
Если поднять сервер дома, клиенты из той же сети могут спотыкаться о NAT loopback: при обращении по публичному адресу трафик не всегда доходит внутрь. Обходится локальным DNS или hairpin NAT на роутере, об этом предупреждает документация проекта. На публичном VPS таких сложностей нет, поэтому этот путь для старта проще.
Мощные VPS для ваших Docker-контейнеров
Идеально подходит для Nginx Proxy Manager, Portainer и Nextcloud. Высокая производительность (NVMe), защита от DDoS и скидка 5% по промокоду.
Установка сервера через Docker Compose
Установка RustDesk Server в Docker начинается с каталога и файла конфигурации. Создайте каталог и перейдите в него:
mkdir rustdesk && cd rustdesk
Внутри создайте файл 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
Режим network_mode: "host" работает на Linux и позволяет процессам видеть реальные адреса клиентов, а не внутренние адреса Docker. В Docker Desktop на macOS и Windows этот режим недоступен, но там сервер и не разворачивают. В каталоге ./data хранится состояние сервера: конфигурация и ключи, они переживают перезапуски и обновления.
Запускаем:
# поднимаем оба сервиса
docker compose up -d
И проверяем, что оба контейнера работают:
docker compose ps --all
docker logs --tail 5 hbbs
docker logs --tail 5 hbbr
При первом запуске hbbs создаёт пару ключей шифрования. Публичная часть лежит в файле data/id_ed25519.pub:
cat data/id_ed25519.pub
Эта строка понадобится при настройке клиентов, сохраните её.
Если на сервере включён ufw, откройте порты сигналинга и релея:
ufw allow 21115/tcp
ufw allow 21116/tcp
ufw allow 21116/udp
ufw allow 21117/tcp
Порты 21118 и 21119 мы не открываем, потому что веб-версию клиента не используем. У официальной документации к ним есть отдельное предупреждение: если они открыты в интернет, посторонний может подделывать IP-адреса в заголовках веб-сокет-соединений, обходя ограничения сервера. Проще держать их закрытыми.
Для разовой проверки в документации проекта есть вариант запуска через docker run, но для постоянной работы Compose удобнее: конфигурация хранится в файле, а обновление выполняется одной командой.
Настройка RustDesk: подключение клиентов
Клиенты RustDesk лежат на официальном сайте проекта: есть версии для Windows, macOS, Linux, Android и iOS. Установите клиент на устройства, которые должны видеть друг друга.
На компьютере настройки открываются через меню рядом с вашим ID (кнопка с тремя точками), пункт Network; изменения применяются с подтверждением прав. В мобильных приложениях те же поля лежат в настройках, на Android это Settings и ID/Relay Server.
Заполните два поля:
ID Server: адрес вашего сервера, напримерrd.example.comили203.0.113.10. Если не указывать порт, клиент сам подставит21116.Key: строка из файлаdata/id_ed25519.pub, которую мы сохранили после установки.
Поле Relay Server можно оставить пустым, если релей работает на том же хосте, что и ID-сервер (как в нашей конфигурации): клиент выведет адрес сам. Если серверы разнесены по разным машинам, адрес релея задают явно и в клиентах, и на стороне hbbs ключом -r в команде запуска. Нажмите Apply, чтобы применить настройки.
На остальных устройствах вводить всё вручную не обязательно. На настроенном клиенте откройте тот же раздел Network и нажмите Export Server Config, скопируйте строку, перенесите на другое устройство и примените через Import Server Config. Для развёртывания сразу на много машин у проекта есть скрипты, а параметры можно передать при установке флагом --config.
Проверить связку просто. Узнайте ID второго устройства (он виден на главном экране клиента), введите его в поле подключения на первом и нажмите Connect. Если на удалённом устройстве задан постоянный пароль, подключающийся вводит его; если нет, вторая сторона подтверждает запрос кнопкой «Принять». После этого открывается удалённый рабочий стол. Если соединение не проходит, смотрите обе стороны: docker logs hbbs на сервере показывает регистрацию устройств, а лог клиента доступен в самом приложении.
Обновление и обслуживание
Для обновления скачайте свежие образы и перезапустите службы:
# обновляем образы и перезапускаем контейнеры
docker compose pull
docker compose up -d
Данные из ./data при этом не трогаются, ключи и настройки остаются на месте. Перед обновлением полезно просматривать release notes серверного репозитория: крупные версии иногда меняют поведение релея. Если понадобится заодно почистить старые образы, пригодится docker image prune -f: команда убирает неиспользуемые слои, но действует на весь Docker на машине, а не только на RustDesk.
Если нужно, чтобы весь трафик шёл только через релей (например, когда прямые соединения между устройствами нежелательны), добавьте службе hbbs переменную окружения ALWAYS_USE_RELAY=Y. Скорость немного упадёт, но трафик пойдёт по одному предсказуемому маршруту.
Публичная половина пары из data/id_ed25519.pub шифрует соединения клиентов с вашим сервером: при несовпадении ключей подключение не установится. Приватный ключ data/id_ed25519 остаётся на сервере и никогда его не покидает: не выкладывайте его никуда, а в клиенты вписывайте только .pub-версию. Релей по умолчанию ключ не проверяет: если нужна строгая проверка и на нём, её включают тем же ключом через переменную KEY для hbbr.
Итог
Теперь удалённый доступ работает через вашу инфраструктуру: ID-сервер и релей под вашим контролем, соединения зашифрованы вашим ключом. Клиенты соединяются напрямую, а релей включается только там, где прямой канал невозможен.
RustDesk-серверу хватает минимального VPS с публичным адресом: подходящие конфигурации есть в нашей подборке. А если сервисов на машине станет больше, загляните в гайд про Portainer: с ним контейнерами удобнее управлять, чем из консоли.