Свой сервер RustDesk: установка на Ubuntu 26.04 и защита

Мне нужен был удалённый доступ к своим компьютерам через собственный сервер. Я выбрал RustDesk: клиент есть для Windows, Linux и macOS, а серверную часть можно развернуть самостоятельно. В этой статье я собрал свою конфигурацию на Ubuntu 26.04: Docker Compose, собственный домен, принудительная ретрансляция, доступ по списку IP и SSH без прямого входа root.

По дороге встретились вполне практические проблемы: на сервере не оказалось ufw и nano, файл Compose назывался не так, как я ожидал, а первое подключение закончилось ошибкой «Несоответствие ключей». Эти моменты я тоже разобрал ниже.

Статья рассчитана на отдельный VPS под RustDesk. На сервере с уже работающими сайтами, почтой, VPN или нестандартным firewall сначала нужно учесть их правила. Команды я выполняю последовательно, проверяя результат каждого этапа.

Что я настраиваю

Параметр	Моя конфигурация
Система	Ubuntu Server 26.04 LTS, amd64
Домен	rustdesk.fastdedic.ru
IPv4 сервера	192.139.97.199
Файл Docker Compose	/opt/rustdesk/compose.yaml
Общий каталог данных	/opt/rustdesk/data
SSH-порт	2232
Администратор	guru с правами sudo
Доверенные внешние IP	127.0.0.1, 127.0.0.2, 127.0.0.3

Домен и IP в примере относятся к моей конфигурации. Для повторения на другом сервере я заменяю их своими значениями во всех командах и настройках. То же относится к пользователю guru и списку доверенных адресов.

Для нескольких компьютеров в качестве стартовой конфигурации я бы закладывал 1 vCPU, 1 ГБ RAM и около 10 ГБ диска. Это практический ориентир для VPS вместе с Ubuntu и Docker, а не измеренный аппаратный минимум RustDesk. При принудительной ретрансляции особенно важны пропускная способность и условия тарификации трафика.

В моём развёртывании использовался образ rustdesk/rustdesk-server:1.1.15. Ниже я сохраняю этот тег для воспроизводимости. Он не обозначает последнюю версию: перед новой установкой я сверяюсь с релизами RustDesk Server и отдельно проверяю выбранное обновление.

1. Подготавливаю домен и сервер

В DNS создаю A-запись:

Код:

Тип:      A
Имя:      rustdesk
Значение: 192.139.97.199

Домен должен указывать непосредственно на сервер. Обычное HTTP-проксирование для портов RustDesk здесь не использую. Если у домена есть AAAA-запись, учитываю её отдельно: в моей итоговой схеме разрешены только три IPv4, а доступ к сервисам по IPv6 закрыт.

Проверяю разрешение имени:

Bash:

getent ahostsv4 rustdesk.fastdedic.ru

В выводе ожидаю 192.139.97.199. Само наличие домена не создаёт сайт или панель управления. Для обычных клиентов RustDesk Server OSS nginx и сертификат HTTPS в этой схеме не нужны.

Обновляю список пакетов и устанавливаю базовые инструменты:

Bash:

sudo apt update
sudo apt install -y ca-certificates curl nano ufw

На моём VPS команды ufw и nano сначала возвращали command not found. Причина оказалась простой: пакеты не были установлены.

Дальше использую sudo, чтобы команды подходили и для пользователя guru. При работе из root отдельный sudo не требуется.

2. Готовлю firewall до запуска RustDesk

Сначала смотрю существующие правила:

Bash:

sudo ufw status verbose
sudo ufw status numbered
sudo grep '^IPV6=' /etc/default/ufw

Для этой конфигурации оставляю IPV6=yes. При запрете входящего трафика это позволяет UFW фильтровать оба семейства адресов. Если значение другое, исправляю его через sudo nano /etc/default/ufw.

До включения firewall разрешаю текущий SSH-порт и будущий 2232. На новом сервере исходным портом у меня был 22:

Bash:

sudo ufw allow 22/tcp
sudo ufw allow 2232/tcp

Если исходный SSH-порт отличается, сначала разрешаю именно его. Текущее подключение можно проверить по переменной:

Bash:

echo "$SSH_CONNECTION"

Первое значение — внешний IP моего подключения, последнее — SSH-порт сервера. При работе через консоль провайдера переменная может отсутствовать.

Порты RustDesk сразу разрешаю только для доверенных сетей:

Bash:

for RD_IP in 127.0.0.1 127.0.0.2 127.0.0.3; do
  sudo ufw allow proto tcp from "$RD_IP" to any port 21115:21117
  sudo ufw allow proto udp from "$RD_IP" to any port 21116
done

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

Bash:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

Если UFW уже активен с этими политиками, повторно включать его не требуется. Если я менял IPV6 в уже активном UFW, после добавления разрешений для SSH применяю это изменение командой sudo ufw reload. Я не выполняю ufw reset: для настройки RustDesk сброс firewall не нужен.

Порт	Назначение	Доступ в моей схеме
21115/TCP	Проверка NAT	Только доверенные IP
21116/TCP и UDP	Регистрация, присутствие и согласование соединений	Только доверенные IP
21117/TCP	Ретрансляция сессий	Только доверенные IP
21118–21119/TCP	WebSocket для веб-клиента	Закрыты
21114/TCP	Панель и API официальной версии Pro	Закрыт, в моей OSS-установке не используется

Ограничение на сервере относится ко всем клиентам. И мой управляющий компьютер, и компьютер, к которому я подключаюсь, должны выходить в интернет с адресов из списка. Если нужно ограничивать только операторов, оставляя управляемые ПК в любых сетях, потребуется другая схема контроля доступа.

При наличии отдельного firewall в панели VPS аналогичные разрешения добавляю и там. Назначение портов сверяю с документацией RustDesk.

3. Устанавливаю Docker и Compose

Если Docker уже установлен и sudo docker compose version работает, этот этап пропускаю. На чистой Ubuntu подключаю официальный репозиторий Docker.

Добавляю ключ репозитория:

Bash:

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Проверяю систему и архитектуру:

Bash:

cat /etc/os-release
dpkg --print-architecture

Для Ubuntu 26.04 с архитектурой amd64 открываю файл:

Bash:

sudo nano /etc/apt/sources.list.d/docker.sources

Вставляю:

Код:

Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: resolute
Components: stable
Architectures: amd64
Signed-By: /etc/apt/keyrings/docker.asc

Для другой архитектуры или выпуска Ubuntu значения нужно менять по фактическому выводу проверок. Затем устанавливаю пакеты:

Bash:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker compose version

Использую команду docker compose с пробелом. Источник установки — официальная инструкция Docker для Ubuntu.

4. Создаю конфигурацию RustDesk

На новой установке создаю каталоги:

Bash:

sudo install -d -m 0755 /opt/rustdesk
sudo install -d -m 0700 /opt/rustdesk/data

Если Compose-файл уже существует, перед изменением сохраняю отдельную копию:

Bash:

sudo cp -a /opt/rustdesk/compose.yaml "/opt/rustdesk/compose.yaml.backup-$(date +%Y%m%d-%H%M%S)"

Открываю файл:

Bash:

sudo nano /opt/rustdesk/compose.yaml

Помещаю в него полную конфигурацию:

YAML:

services:
  hbbr:
    image: rustdesk/rustdesk-server:1.1.15
    container_name: rustdesk-hbbr
    command: hbbr -k _
    network_mode: host
    volumes:
      - ./data:/root
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

  hbbs:
    image: rustdesk/rustdesk-server:1.1.15
    container_name: rustdesk-hbbs
    command: hbbs -r rustdesk.fastdedic.ru:21117 -k _
    environment:
      ALWAYS_USE_RELAY: "Y"
    network_mode: host
    volumes:
      - ./data:/root
    depends_on:
      - hbbr
    restart: unless-stopped
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

В nano сохраняю файл через Ctrl+O, Enter и выхожу через Ctrl+X. В YAML использую пробелы, не табуляцию.

Здесь hbbs отвечает за регистрацию и согласование соединений, а hbbr — за их ретрансляцию. Оба контейнера используют один каталог ./data:/root, поэтому загружают одну пару серверных ключей.

ALWAYS_USE_RELAY: "Y" включает принудительную ретрансляцию для соединений, согласованных этим сервером. Параметр -k _ у hbbr включает проверку ключа; у hbbs я указываю его явно. Это не список пользователей: публичный ключ не заменяет пароль доступа к ПК.

Образ работает в network_mode: host. В данной Linux-конфигурации сервисы используют сетевой стек хоста, и правила входящего трафика UFW относятся к их портам. Этот вывод нельзя автоматически переносить на Docker bridge с публикацией через ports:, где обработка firewall отличается. Подробнее — Docker host network.

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

5. Запускаю сервер и получаю публичный ключ

Сначала проверяю Compose:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml config -q

Если команда сообщает об ошибке, исправляю файл до запуска.

На совершенно новой установке первым запускаю hbbs без зависимостей, чтобы он успел создать пару ключей до запуска второго сервиса:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml up -d --no-deps hbbs
sudo docker compose -f /opt/rustdesk/compose.yaml logs --tail=30 hbbs

Дожидаюсь нормального старта и наличия ключа. Публичную часть вывожу так:

Bash:

sudo awk '{print}' /opt/rustdesk/data/id_ed25519.pub

Если файл пока отсутствует, проверяю журнал hbbs и не запускаю следующий этап до устранения причины. После появления ключей запускаю весь проект:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml up -d
sudo docker compose -f /opt/rustdesk/compose.yaml ps
sudo docker compose -f /opt/rustdesk/compose.yaml logs --tail=40 hbbs hbbr

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

Код:

ALWAYS_USE_RELAY=Y
relay-servers=["rustdesk.fastdedic.ru:21117"]

Слушающие порты проверяю отдельно:

Bash:

sudo ss -lntup | grep -E '21115|21116|21117|21118|21119'

Наличие Listening или строки в ss означает, что процесс открыл сокет. Оно не доказывает доступность порта из интернета: доступ снаружи определяет firewall.

С ключами у меня простое правило:

id_ed25519.pub — публичная часть, её указываю в клиентах.
id_ed25519 — приватная часть, она остаётся на сервере и в защищённой резервной копии.

Дополнительно ограничиваю права приватного файла:

Bash:

sudo chmod 600 /opt/rustdesk/data/id_ed25519
sudo chmod 644 /opt/rustdesk/data/id_ed25519.pub

Вывод через awk удобен тем, что добавляет перенос строки. При обычном cat приглашение терминала может прилипнуть к ключу, если в файле нет завершающего перевода строки. Сам файл от этого не портится.

6. Подключаю компьютеры

Клиент устанавливаю из официальных релизов RustDesk на управляющий и управляемый компьютеры. На каждом открываю настройки сети и, если требуется, разблокирую их с правами администратора.

Поле клиента	Что я указываю
ID Server	rustdesk.fastdedic.ru:21116
Relay Server	rustdesk.fastdedic.ru:21117
API Server	Оставляю пустым
Key	Полное содержимое моего id_ed25519.pub

В ID Server и Relay Server не добавляю https://. В поле Key копирую всю строку без кавычек и пробелов, сохраняя завершающий =, если он есть. На обоих компьютерах должен быть ключ одного и того же сервера. Порядок настройки описан в документации клиента.

После сохранения настроек проверяю готовность клиентов и пробую соединение: ввожу ID удалённого компьютера, затем его пароль либо подтверждаю запрос на управляемой стороне. Серверный ключ и пароль удалённого компьютера — разные значения.

На каждом управляемом ПК выключаю «Прямой доступ по IP». Для доступа без присутствия использую длинный уникальный постоянный пароль. Если подключение нужно только в моём присутствии, выбираю подтверждение кликом; отдельно проверяю, что не включено разрешение входа по паролю на экране блокировки.

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

На macOS дополнительно выдаю запрошенные системой разрешения на запись экрана и управление. На Linux проверяю ограничения используемой графической сессии. Пустой рабочий стол или отсутствие управления после авторизации — отдельная проблема, которую не исправляет замена серверного ключа.

7. Разбираюсь с ошибкой «Несоответствие ключей»

При первом подключении я получил Key mismatch. В журнале hbbs была строка:

Код:

Authentication failed ... invalid key

Это сразу сузило поиск: запрос уже дошёл до сервера, но проверка ключа не прошла. Я сверил публичный ключ из журнала и файла, затем указал его на обоих клиентах. После исправления подключение заработало.

Для такой проверки использую:

Bash:

sudo awk '{print}' /opt/rustdesk/data/id_ed25519.pub
sudo docker compose -f /opt/rustdesk/compose.yaml logs --tail=100 hbbs hbbr
sudo docker inspect rustdesk-hbbs rustdesk-hbbr \
  --format '{{.Name}}{{range .Mounts}} {{.Source}} -> {{.Destination}}{{end}}'

Для обоих контейнеров ожидаю:

Код:

/rustdesk-hbbs /opt/rustdesk/data -> /root
/rustdesk-hbbr /opt/rustdesk/data -> /root

Если ключ внесён верно, а ошибка сохраняется, проверяю адрес сервера на обоих клиентах, перезапускаю клиентское приложение и при необходимости его службу. Дополнительно смотрю, нет ли второго hbbs, запущенного вне Docker:

Bash:

ps aux | grep -E '[h]bbs|[h]bbr'
sudo ss -lntup | grep -E '21115|21116|21117'

Я не удаляю файлы ключей в качестве первого способа исправления: после генерации другой пары придётся обновлять настройки клиентов. Возможные причины ошибки также перечислены в FAQ RustDesk.

Если Compose-файл или контейнер «не найден»

У меня файл оказался compose.yaml, а не compose.yml. Поэтому копирование по неверному имени завершилось сообщением No such file or directory. Фактический путь можно получить из метки контейнера:

Bash:

sudo docker inspect rustdesk-hbbs \
  --format '{{index .Config.Labels "com.docker.compose.project.config_files"}}'

У Docker Compose сервисы называются hbbs и hbbr, а контейнеры — rustdesk-hbbs и rustdesk-hbbr. Для docker compose logs hbbs использую имя сервиса, для docker inspect rustdesk-hbbs — имя контейнера.

8. Проверяю, что сессия проходит через мой сервер

Одного параметра в YAML мне недостаточно. Смотрю журнал ретранслятора во время нового подключения:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml logs --since=1m -f hbbr

В моей проверке появились сообщения:

Код:

New relay request ...
Relayrequest ... got paired
Both are raw

Они показывают, что hbbr получил запрос и соединил две стороны сессии. В информации о соединении клиента также проверяю режим Relay / «Ретрансляция». Просмотр журнала завершаю Ctrl+C — контейнеры от этого не останавливаются.

Both are raw здесь означает, что обе стороны используют обычный TCP-транспорт вместо WebSocket. Сама эта строка не является признаком отключённого шифрования: такое условие видно в исходном коде relay-сервера версии 1.1.15.

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

9. Переношу SSH на порт 2232

На этом этапе я сохраняю текущую SSH-сессию и проверяю, что в панели провайдера доступна консоль восстановления. Порт 2232 уже разрешён в UFW; если есть внешний firewall, открываю его и там.

Создаю файл:

Bash:

sudo nano /etc/ssh/sshd_config.d/00-local-port.conf

Его содержимое:

Код:

Port 2232

Проверяю конфигурацию:

Bash:

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep '^port '

Первая команда должна завершиться без ошибок. Во второй ожидаю только port 2232. Директива Port допускает несколько значений, поэтому при наличии активного Port 22 в другом файле одного нового фрагмента недостаточно. Такие настройки нахожу командой:

Bash:

sudo grep -RnsE '^[[:space:]]*(Port|ListenAddress|Include|Match)[[:space:]]' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d

Лишние активные Port исправляю вручную, затем повторяю проверку. Файлы конфигурации целиком не заменяю.

У моего сервера порт 22 первоначально слушали одновременно sshd и systemd. В Ubuntu это связано с socket activation. Для такого режима после изменения порта нужно обновить и сокет, а не ограничиваться перечитыванием ssh.service. Поведение описано в материале Ubuntu о socket activation.

После успешной проверки применяю настройку с учётом активного режима:

Bash:

if systemctl is-active --quiet ssh.socket; then
  sudo systemctl daemon-reload
  sudo systemctl restart ssh.socket ssh.service
else
  sudo systemctl restart ssh.service
fi

Проверяю фактический слушающий порт:

Bash:

sudo ss -lntp | grep -E ':(22|2232)[[:space:]]'

Если порт не изменился, проверяю systemctl cat ssh.socket на старые переопределения и возвращаюсь к конфигурации. Старый доступ до успешной проверки нового не закрываю.

На своём компьютере в отдельном окне открываю новое соединение:

Bash:

ssh -o ControlPath=none -p 2232 guru@rustdesk.fastdedic.ru

У меня пользователь guru уже существовал и имел sudo, поэтому создавать другого администратора не пришлось. Внутри нового подключения проверяю:

Bash:

sudo whoami

Ожидаю root. Если вход или sudo не работают, сначала исправляю доступ guru и только потом перехожу к запрету root. Сам перенос порта уменьшает часть фонового шума, но не заменяет авторизацию и firewall.

10. Запрещаю прямой вход root по SSH

После проверки guru создаю файл:

Bash:

sudo nano /etc/ssh/sshd_config.d/00-disable-root-login.conf

Добавляю строку:

Код:

PermitRootLogin no

Проверяю результат:

Bash:

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | grep '^permitrootlogin '

Ожидаю permitrootlogin no. Если вывод другой, разбираюсь с порядком подключаемых файлов и директивами Match, прежде чем применять изменения. В Ubuntu используется каталог фрагментов /etc/ssh/sshd_config.d/; порядок чтения важен. Подробнее — настройка OpenSSH в Ubuntu.

После успешной проверки перечитываю конфигурацию:

Bash:

sudo systemctl reload ssh.service

С клиентского компьютера проверяю два новых подключения:

Bash:

ssh -o ControlPath=none -p 2232 guru@rustdesk.fastdedic.ru
ssh -o ControlPath=none -p 2232 root@rustdesk.fastdedic.ru

Команды выполняю по отдельности. guru должен входить и получать административные права через sudo, а root — получать отказ, даже с правильным паролем или ключом. Проверяю именно новое соединение: уже открытая root-сессия сама по себе не показывает, разрешён ли новый вход.

Так я запрещаю SSH-вход root, сохраняя обычную работу через sudo. Значение no запрещает все способы SSH-аутентификации root; prohibit-password оставило бы возможность входа по ключу. Это различие указано в справочнике OpenSSH.

11. Оставляю SSH и RustDesk только для доверенных IP

Сначала ещё раз проверяю внешний адрес текущего SSH-подключения:

Bash:

echo "$SSH_CONNECTION"

Если первый IP не входит в мой список, сначала подключаюсь из доверенной сети. Возможность новой SSH-сессии с разрешённого адреса должна быть проверена до удаления общих разрешений.

Добавляю полный набор разрешений. Правила RustDesk из второго раздела при повторном добавлении UFW пропустит как уже существующие:

Bash:

for RD_IP in 127.0.0.1 127.0.0.2 127.0.0.3; do
  sudo ufw allow proto tcp from "$RD_IP" to any port 2232
  sudo ufw allow proto tcp from "$RD_IP" to any port 21115:21117
  sudo ufw allow proto udp from "$RD_IP" to any port 21116
done

Если команды завершились без ошибок, смотрю текущий список:

Bash:

sudo ufw status numbered

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

Bash:

sudo ufw --force delete allow 2232/tcp
sudo ufw --force delete allow 22/tcp
sudo ufw --force delete allow OpenSSH
sudo ufw --force delete allow 21115/tcp
sudo ufw --force delete allow 21116/tcp
sudo ufw --force delete allow 21116/udp
sudo ufw --force delete allow 21117/tcp

При установке строго по этой статье общих разрешений RustDesk не будет: они нужны в списке удаления для перехода с моей первоначальной открытой конфигурации. Если правило отсутствует, удалять его не требуется. Другие широкие разрешения, если они есть, проверяю отдельно.

Удаление по полной записи правила убирает его варианты IPv4 и IPv6. При удалении по номеру удалился бы только конкретный пункт. Поэтому здесь использую полный текст. Основание — документация UFW.

Проверяю итог:

Bash:

sudo ufw status verbose
sudo ufw status numbered

Для отдельного сервера из этой статьи ожидаю девять разрешений:

Код:

2232/tcp          ALLOW IN    127.0.0.1
21115:21117/tcp   ALLOW IN    127.0.0.1
21116/udp         ALLOW IN    127.0.0.1
2232/tcp          ALLOW IN    127.0.0.2
21115:21117/tcp   ALLOW IN    127.0.0.2
21116/udp         ALLOW IN    127.0.0.2
2232/tcp          ALLOW IN    127.0.0.3
21115:21117/tcp   ALLOW IN    127.0.0.3
21116/udp         ALLOW IN    127.0.0.3

Порядок строк может отличаться. Важно, чтобы для SSH и RustDesk не оставалось общих ALLOW Anywhere, в том числе IPv6, а входящая политика оставалась deny. При этих условиях новый внешний доступ к перечисленным сервисам по IPv6 также закрыт. Порты 21118–21119 я не открываю.

Правила UFW применяются сразу и сохраняются после перезагрузки. Уже установленные соединения могут продолжать работать, поэтому для завершения существующих сеансов RustDesk перезапускаю его сервисы:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml restart hbbs hbbr

Этот шаг прерывает текущие удалённые сеансы. Открытую административную SSH-сессию сохраняю, пока не проверю новое подключение guru из доверенной сети.

Финальную проверку провожу с двух сетей: из разрешённой должны работать SSH и RustDesk, из сети с другим внешним IP — новые подключения должны блокироваться. Если использую мобильный интернет для отрицательной проверки, сначала убеждаюсь, что его адрес действительно не входит в список.

Список IP доверяет сетевому адресу, а не конкретному компьютеру. Несколько устройств за одним NAT могут иметь один внешний IP. Поэтому пароль RustDesk и SSH-аутентификация остаются обязательными. При смене внешнего IP заранее добавляю новый адрес или пользуюсь консолью провайдера для восстановления доступа.

12. Что именно защищает эта конфигурация

Я разделяю несколько механизмов, чтобы не приписывать одному из них лишние возможности:

Домен и публичный ключ указывают клиентам мой сервер.
ALWAYS_USE_RELAY=Y направляет согласованные им сессии через ретранслятор.
Отключённый прямой доступ по IP на клиентах закрывает отдельный способ подключения к их слушающему порту.
UFW ограничивает внешний доступ к серверным портам доверенными сетями.
Пароль или ручное подтверждение на управляемом ПК определяют, будет ли разрешён доступ к рабочему столу.

Установка своего сервера сама по себе не делает любой компьютер с правильным ключом доверенным. При этом firewall VPS не запрещает локальному администратору ПК изменить настройки RustDesk, запустить другой клиент или использовать другой сервер. Для жёсткого запрета таких действий нужны дополнительные политики на самих компьютерах и в сети.

Моя схема рассчитана на собственные управляемые устройства с сохранёнными настройками и известными внешними IP. Если адреса часто меняются или требуется допуск по отдельным устройствам, следующим шагом я рассматриваю VPN с индивидуальными ключами и ограничением доступа только через него либо централизованную систему управления доступом. Это отдельный этап, не выполненный одними параметрами Compose.

13. Где здесь веб-панель

В выбранном мной RustDesk Server OSS встроенной административной веб-панели нет. Здесь работают hbbs и hbbr; открывать домен в браузере ради админки бессмысленно. Это также причина, по которой поле API Server в клиентах остаётся пустым.

Официальную веб-консоль с пользователями, устройствами и другими средствами управления предоставляет платная версия Pro. Есть и сторонние открытые проекты, например lejianwen/rustdesk-api, но я не включаю их в эту конфигурацию: у них собственные требования к совместимости, настройке и обновлениям.

Состав бесплатной версии описан в документации OSS, возможности официальной админки — в документации Pro.

14. Обслуживание и резервная копия

Для повседневной проверки мне достаточно нескольких команд:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml ps
sudo docker compose -f /opt/rustdesk/compose.yaml logs --tail=50 hbbs hbbr
sudo ufw status numbered

Перед обновлением я сохраняю Compose-файл, базу и оба файла ключей. Для согласованной файловой копии SQLite останавливаю сервисы на время архивации:

Bash:

sudo install -d -m 0700 /var/backups/rustdesk
sudo docker compose -f /opt/rustdesk/compose.yaml stop hbbs hbbr

Архив создаю с закрытыми правами:

Bash:

sudo sh -c 'umask 077; tar -czf "/var/backups/rustdesk/rustdesk-$(date +%Y%m%d-%H%M%S).tar.gz" -C /opt/rustdesk compose.yaml data'

Сразу после архивации возвращаю сервисы в работу, даже если создание архива завершилось ошибкой:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml start hbbs hbbr
sudo docker compose -f /opt/rustdesk/compose.yaml ps
sudo ls -lh /var/backups/rustdesk

Для проверки архива подставляю его фактическое имя:

Bash:

sudo tar -tzf /var/backups/rustdesk/ИМЯ_СОЗДАННОГО_АРХИВА.tar.gz

Архив содержит приватный ключ, поэтому храню его как секрет и отдельно сохраняю защищённую копию вне VPS. Копия на том же диске удобна для отката, но не спасает при потере сервера. Настройки SSH и UFW сохраняю отдельно перед их последующими изменениями.

Для обновления читаю изменения релиза, меняю тег образа у обоих сервисов в compose.yaml и выполняю:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml config -q

Только если проверка прошла, продолжаю:

Bash:

sudo docker compose -f /opt/rustdesk/compose.yaml pull
sudo docker compose -f /opt/rustdesk/compose.yaml up -d
sudo docker compose -f /opt/rustdesk/compose.yaml ps
sudo docker compose -f /opt/rustdesk/compose.yaml logs --tail=40 hbbs hbbr

Проверяю сохранность публичного ключа и новое реальное подключение. Фиксированный тег 1.1.15 не обновится на другую версию от одной команды pull — для этого я явно меняю тег. Неудачное обновление откатываю с учётом совместимости базы, используя сохранённую конфигурацию и резервную копию.

Для меня главная проверка такой установки — рабочая сессия через hbbr и отказ нового подключения из посторонней сети. Статус Up полезен, но только эти проверки показывают, что вместе работают и удалённый доступ, и заданные ограничения.

Поиск

Поиск

Как я настроил RustDesk на Ubuntu 26.04: свой сервер и защита

Что я настраиваю

1. Подготавливаю домен и сервер

2. Готовлю firewall до запуска RustDesk

3. Устанавливаю Docker и Compose

4. Создаю конфигурацию RustDesk

5. Запускаю сервер и получаю публичный ключ

6. Подключаю компьютеры

7. Разбираюсь с ошибкой «Несоответствие ключей»

Если Compose-файл или контейнер «не найден»

8. Проверяю, что сессия проходит через мой сервер

9. Переношу SSH на порт 2232

10. Запрещаю прямой вход root по SSH

11. Оставляю SSH и RustDesk только для доверенных IP

12. Что именно защищает эта конфигурация

13. Где здесь веб-панель

14. Обслуживание и резервная копия

Комментарии

Информация о статье

Ещё в Сервисы и системы

Ещё от Guru

Поделиться этой статьёй

Как я настроил RustDesk на Ubuntu 26.04: свой сервер и защита

Что я настраиваю​

1. Подготавливаю домен и сервер​

2. Готовлю firewall до запуска RustDesk​

3. Устанавливаю Docker и Compose​

4. Создаю конфигурацию RustDesk​

5. Запускаю сервер и получаю публичный ключ​

6. Подключаю компьютеры​

7. Разбираюсь с ошибкой «Несоответствие ключей»​

Если Compose-файл или контейнер «не найден»​

8. Проверяю, что сессия проходит через мой сервер​

9. Переношу SSH на порт 2232​

10. Запрещаю прямой вход root по SSH​

11. Оставляю SSH и RustDesk только для доверенных IP​

12. Что именно защищает эта конфигурация​

13. Где здесь веб-панель​

14. Обслуживание и резервная копия​

Комментарии

Информация о статье

Ещё в Сервисы и системы

Ещё от Guru

Поделиться этой статьёй

Что я настраиваю

1. Подготавливаю домен и сервер

2. Готовлю firewall до запуска RustDesk

3. Устанавливаю Docker и Compose

4. Создаю конфигурацию RustDesk

5. Запускаю сервер и получаю публичный ключ

6. Подключаю компьютеры

7. Разбираюсь с ошибкой «Несоответствие ключей»

Если Compose-файл или контейнер «не найден»

8. Проверяю, что сессия проходит через мой сервер

9. Переношу SSH на порт 2232

10. Запрещаю прямой вход root по SSH

11. Оставляю SSH и RustDesk только для доверенных IP

12. Что именно защищает эта конфигурация

13. Где здесь веб-панель

14. Обслуживание и резервная копия