Как я настроил свой RustDesk-сервер на Ubuntu VPS для удалённого доступа к домашнему ПК

Как я настроил свой RustDesk-сервер на Ubuntu VPS для удалённого доступа к домашнему ПК

Иногда мне нужно подключаться к своему домашнему компьютеру удалённо. Для этого я использую RustDesk — программу для удалённого доступа, похожую по смыслу на AnyDesk или TeamViewer, только с важным отличием: её можно завести через свой сервер.

До этого я использовал чужой RustDesk-сервер. В целом он работал, но была проблема: подключение нормально проходило не во всех условиях. Иногда всё зависело от IP, VPN, сети и того, откуда именно я подключаюсь.

А у меня сценарий простой: я могу сидеть с VPN, могу отключить VPN, могу быть в другой сети, могу подключаться не с того же места, где находится домашний компьютер. И мне не хочется каждый раз разбираться, почему сегодня удалённый доступ работает, а завтра нет.

Поэтому я решил поднять собственный RustDesk Server OSS на Ubuntu VPS. Это не огромный проект, но хорошая практичная задача из серии “сделать свою инфраструктуру чуть стабильнее и понятнее”.

В этой статье разберу, зачем я это сделал, как подошёл к настройке, что было реализовано, какие сложности появились и кому такая настройка может быть полезна.

Какая была задача

Задача была такая:

настроить свой RustDesk-сервер, чтобы подключаться к домашнему компьютеру через RustDesk не через чужой сервер, а через свой VPS.

Мне было важно:

• не зависеть от чужого RustDesk-сервера;
• подключаться к домашнему ПК с VPN и без VPN;
• не ломать уже работающие проекты на VPS;
• сделать всё через Docker Compose;
• получить понятную схему, которую можно проверить и обслуживать;
• не публиковать и не светить приватные данные подключения.

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

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

Почему я не хотел зависеть от чужого сервера

RustDesk может работать через публичную инфраструктуру или через свой self-hosted сервер. В моём случае был сторонний сервер, который использовался для подключения.

Проблема в том, что чужой сервер — это всегда чужие условия.

Он может:

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

Мне нужна была более предсказуемая схема. Не идеальная, не “корпоративная инфраструктура за миллионы”, а просто нормальный личный вариант: есть мой VPS, на нём работает RustDesk Server OSS, мои устройства подключаются через него.

Так я хотя бы понимаю, где искать проблему, если что-то перестанет работать.

Как RustDesk работает простыми словами

В RustDesk Server OSS есть два основных компонента: hbbs и hbbr.

hbbs — это ID Server

hbbs отвечает за то, чтобы устройства RustDesk находили друг друга.

Если объяснять совсем просто, устройства подключаются к ID Server и говорят: “я здесь”. Благодаря этому один клиент RustDesk может найти другой клиент RustDesk по ID.

То есть hbbs — это не сам удалённый рабочий стол, а сервер координации.

hbbr — это Relay Server

hbbr — это ретранслятор.

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

Например, если одно устройство за VPN, второе за домашним роутером, где-то NAT, где-то провайдер режет прямые соединения — прямой p2p может работать нестабильно.

В таком случае relay помогает: соединение идёт через мой VPS.

Минус простой: трафик идёт через сервер, поэтому может быть чуть выше задержка и больше нагрузка на VPS. Но для моей задачи это нормальный компромисс, потому что мне важнее стабильность, чем идеальная скорость в прямом соединении.

API Server мне не понадобился

В настройках RustDesk есть поле API Server, но в моём случае оно осталось пустым.

Я поднимал обычный RustDesk Server OSS, а не RustDesk Server Pro. Для моей задачи достаточно ID Server, Relay Server и ключа сервера.

API Server нужен не для базового удалённого подключения, а для других сценариев, связанных с расширенной серверной частью.

Как я подошёл к настройке

Я не стал сразу ставить RustDesk на сервер вслепую.

На VPS уже были другие рабочие проекты: сайты, боты, Docker-контейнеры, Nginx и системные сервисы. Поэтому сначала нужно было понять, не будет ли конфликтов.

Перед установкой я проверил:

• версию Ubuntu;
• установлен ли Docker;
• установлен ли Docker Compose;
• свободны ли нужные порты;
• включён ли UFW;
• какие контейнеры уже работают;
• какие порты использует Nginx;
• есть ли риск задеть существующие сайты и боты.

Это важный момент. Когда сервер уже используется, нельзя просто “доставить ещё один сервис” и надеяться, что всё не отвалится.

Нормальный подход такой:

1. Сначала аудит.
2. Потом план установки.
3. Потом аккуратная настройка в отдельной директории.
4. Потом проверка контейнеров, логов и портов.
5. Только после этого — настройка клиентов RustDesk.

Именно так я и сделал.

Что было реализовано

RustDesk Server OSS был поднят на Ubuntu VPS через Docker Compose.

Для проекта была создана отдельная директория:

/opt/rustdesk-server

Внутри отдельно хранятся данные и ключи сервера:

/opt/rustdesk-server/data

Конфигурация лежит в отдельном compose.yml.

В Docker Compose описаны два сервиса:

• hbbs — ID Server;
• hbbr — Relay Server.

Контейнеры настроены так, чтобы автоматически подниматься после сбоя или перезагрузки сервера.

Для RustDesk были открыты нужные порты в UFW:

TCP 21115-21119
UDP 21116

Точные IP-адреса, ключи и данные подключения я в статье не публикую. Это рабочая инфраструктура, а не публичная инструкция с моими доступами.

Почему я включил принудительный relay

После базовой установки я включил режим принудительного relay:

ALWAYS_USE_RELAY=Y

Смысл этой настройки в том, что RustDesk не пытается во всех случаях строить прямое p2p-соединение, а использует relay-сервер.

Для кого-то это может быть лишним. Если оба устройства находятся в простых сетях и прямое соединение отлично работает, p2p может быть быстрее.

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

• с VPN;
• без VPN;
• из другой сети;
• через домашний роутер;
• через NAT;
• при смене внешнего IP;
• при нестабильных сетевых условиях.

В таких сценариях принудительный relay — нормальный практичный компромисс.

Да, сервер становится промежуточной точкой. Да, трафик идёт через VPS. Да, задержка может быть выше, чем при прямом соединении.

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

Что получилось в итоге

В итоге у меня появился свой RustDesk-сервер.

Он работает отдельно от сайтов, не трогает Nginx, не мешает другим Docker-проектам и обслуживает подключение через свои контейнеры.

На стороне клиента RustDesk нужно указывать:

• ID Server;
• Relay Server;
• Key;
• API Server оставить пустым.

Главное правило: одинаковые настройки должны быть прописаны на обоих устройствах.

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

Если на одном устройстве останется старый сервер, а на другом будет новый, они могут просто не найти друг друга.

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

Что сработало хорошо

Лучше всего сработал подход “сначала проверить, потом ставить”.

Я заранее посмотрел, что происходит на сервере: какие сервисы работают, какие порты свободны, включён ли firewall, где может быть конфликт.

Из-за этого установка прошла аккуратно. RustDesk был вынесен в отдельную директорию и не задел существующие сайты, боты и другие сервисы.

Ещё хорошо сработал Docker Compose.

Для такой задачи это удобный вариант:

• конфигурация лежит в одном месте;
• понятно, какие сервисы запущены;
• можно быстро посмотреть статус контейнеров;
• можно отдельно перезапустить только RustDesk;
• проще сделать бэкап конфигурации;
• проще понять, что именно было изменено.

Также полезным оказалось включение ALWAYS_USE_RELAY=Y. Это не всегда нужно всем, но в моём случае это как раз решало проблему нестабильных сетей и VPN.

Что было сложным

Самая сложная часть в таких задачах — не сама установка, а сеть.

Можно правильно поднять контейнеры, открыть порты в UFW, увидеть, что всё слушается на сервере, но подключение всё равно может не работать.

Почему?

Потому что кроме firewall внутри Ubuntu может быть ещё внешний firewall у провайдера. Например, security group, правила в панели хостинга, anti-DDoS-фильтрация или ограничения на нестандартные порты.

Изнутри VPS не всегда можно точно понять, режет ли провайдер входящий трафик. Поэтому такие вещи нужно проверять отдельно в панели управления сервером.

Вторая сложность — аккуратность. На сервере уже были другие проекты, и мне было важно не устроить ситуацию, где ради RustDesk случайно ломаются сайты или боты.

Поэтому я не трогал Nginx, не менял чужие конфиги, не перезагружал весь сервер и не смешивал RustDesk с другими проектами.

Что не понадобилось

В процессе стало понятно, что для этой задачи не нужно усложнять.

Мне не понадобился Nginx, потому что RustDesk Server OSS работает на своих портах напрямую.

Мне не понадобился API Server, потому что обычному RustDesk OSS он не нужен для базового подключения.

Мне не понадобился отдельный домен на первом этапе. Домен можно добавить позже для удобства, но он не является обязательным условием работы.

Иногда хочется сразу сделать красиво: домен, HTTPS, панель, мониторинг, резерв, автоматику. Но не всегда нужно начинать с этого.

Сначала лучше сделать рабочую базу. Потом уже улучшать.

Почему это полезно

Для меня эта настройка полезна как часть личной рабочей инфраструктуры.

У меня есть сайты, боты, серверы, автоматизации и рабочие процессы, которые требуют нормального доступа к компьютерам и VPS. Когда удалённый доступ нестабилен, это мешает работать.

Собственный RustDesk-сервер помогает сделать схему понятнее:

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

Такая настройка может пригодиться не только мне.

Она полезна тем, кто:

• подключается к домашнему ПК удалённо;
• часто работает через VPN;
• хочет иметь доступ к рабочему компьютеру из разных сетей;
• держит свои сайты, боты или серверы;
• не хочет зависеть от чужих RustDesk-серверов;
• хочет собрать личную инфраструктуру для работы.

В похожем формате я делаю и другие технические задачи: настройку серверов, сайтов, Telegram-ботов и небольших автоматизаций. Подробнее можно посмотреть в разделе услуг, кейсов и digital-проектов.

Какие выводы я сделал

Главный вывод: удалённый доступ — это не только “скачать программу и ввести ID”.

Если хочется стабильности, нужно понимать всю цепочку:

• клиент RustDesk;
• ID Server;
• Relay Server;
• firewall на сервере;
• внешний firewall у провайдера;
• Docker-контейнеры;
• порты;
• VPN;
• NAT;
• одинаковые настройки на обоих устройствах.

Второй вывод: свои серверы дают больше контроля, но требуют аккуратности. Если ставить всё бездумно, можно сломать то, что уже работает.

Третий вывод: не всегда нужно усложнять. В моём случае не понадобились Nginx, API Server и сложная панель. Достаточно было поднять RustDesk Server OSS, включить relay и правильно настроить клиенты.

Что можно доработать дальше

Базовая задача решена, но эту схему можно развивать.

Дальше можно:

• подключить отдельный домен для RustDesk;
• проверить внешний firewall в панели провайдера;
• добавить мониторинг контейнеров;
• настроить уведомления, если RustDesk-сервер упал;
• делать бэкап папки с данными RustDesk;
• зафиксировать версию Docker-образа вместо latest;
• поднять резервный сервер на случай проблем с основным VPS.

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

Что похожее можно заказать у меня

Этот проект относится к настройке серверов и рабочей инфраструктуры.

Ко мне можно обратиться, если нужно:

• настроить свой RustDesk-сервер;
• сделать удалённый доступ к домашнему или рабочему ПК;
• настроить Ubuntu VPS;
• поднять Docker-проект;
• аккуратно развернуть сервис рядом с уже работающими сайтами;
• настроить сервер под сайт, Telegram-бота или автоматизацию;
• собрать личную инфраструктуру для удалённой работы.

Я не продаю магию и не обещаю “всё за 5 минут”. Обычно нормальная работа выглядит проще: сначала смотрим, что уже есть, потом аккуратно настраиваем, потом проверяем, что реально работает.

Если нужен похожий проект — можно оставить заявку через форму на сайте: оставить заявку.

А другие разборы моих проектов можно посмотреть в блоге.