Source: https://aiprimetech.io/ru/blog/rustdesk-open-source-ai/ 15 июня, 2026 · 8 мин · Открытый исходный код # Rustdesk: подробный разбор популярного ИИ-проекта для разработчиков (2026) A Автор: [AI Prime Tech](https://aiprimetech.io/ru/) · При участии ИИ В 2:13 утра дообучение завершилось, метрики выглядели нормально, и единственной проблемой оставалось диалоговое окно в графическом интерфейсе обучающей машины: окно входа в браузере, в котором нужно было нажать кнопку, прежде чем мог начаться следующий запуск. SSH хватало для просмотра журналов, но он был бесполезен для взаимодействия, доступного только через рабочий стол. Именно такие проблемы RustDesk решает хорошо. RustDesk уже перешагнул порог «серьёзного проекта с открытым исходным кодом», но причина, по которой инженеры продолжают им пользоваться, проще: он предоставляет доступ к удалённому рабочему столу, который можно разместить самостоятельно, контролировать и которому действительно можно доверять в пределах собственной сети. Это не ИИ-модель. Это инфраструктура, которая незаметно делает эксплуатацию ИИ более устойчивой. ## Какие задачи RustDesk действительно решает RustDesk заполняет неудобный, но вполне реальный промежуток между «я могу подключиться по SSH» и «мне прямо сейчас нужен полноценный графический интерфейс». Это важно, когда вы работаете с: - рабочей станцией с GPU за NAT - локальным сервером, который загружает рабочий стол ради одного конкретного инструмента - машиной для разметки данных, которой пользуется небольшая команда - демонстрационным ноутбуком, подключённым к Wi-Fi на конференции - лабораторной машиной в изолированной подсети, где VDI было бы избыточным решением Главная инженерная ценность заключается не в самом удалённом экране. Она в том, что трафик RustDesk можно направить через инфраструктуру, которую вы контролируете. Для команд, работающих с моделями, это означает меньшую зависимость от сторонних ретрансляторов удалённого доступа, меньше сложностей с соблюдением нормативных требований и более понятную схему аудита и контроля доступа. На практике проект наиболее полезен, когда нужен резервный способ доступа на случай, если VPN, SSH и администрирования через браузер недостаточно. ## Как устроена архитектура Архитектура RustDesk проста, и отчасти именно поэтому он привлекателен с точки зрения эксплуатации. В общих чертах он состоит из трёх частей: - Клиентские приложения на локальной и удалённой машинах - Сервер координации и идентификации который помогает узлам находить друг друга - Сервер ретрансляции который передаёт трафик, когда прямое подключение не удаётся В типичном развёртывании на собственной инфраструктуре используются hbbs и hbbr сервисы. hbbs обрабатывает идентификацию и координацию; hbbr обрабатывает ретранслируемый трафик, когда обход NAT или правила межсетевого экрана не позволяют установить прямое соединение между узлами. Основная идея такова: - Удалённая машина регистрируется. - Ваш клиент находит эту машину по идентификатору. - RustDesk пытается подключиться напрямую. - Если установить прямое соединение не удаётся, трафик передаётся через сервер ретрансляции. - Сеанс сохраняет сквозное шифрование. Последний пункт важен. При разумно настроенном развёртывании сервер ретрансляции не должен иметь возможности просматривать содержимое вашего рабочего стола. Он передаёт пакеты, а не становится вашей доверенной операторской консолью. Такая модель лучше, чем «отправлять все пиксели на какой-то SaaS-сервер и надеяться, что страница с политикой соответствует действительности». ### Что часто упускают Распространённая ошибка — считать, что самостоятельное размещение означает «установить сервер, и всё готово». Вам всё ещё нужно: - открыть нужные порты - настроить клиент на использование вашего сервера - закрепить ожидаемый ключ или идентификатор сервера - убедиться, что клиенты незаметно не используют публичный резервный маршрут Если не выполнить последний пункт, вы можете думать, что используете собственную инфраструктуру, хотя клиент всё ещё находит узлы через маршрут по умолчанию. ## Реалистичная конфигурация на собственной инфраструктуре Один из распространённых вариантов — небольшой VPS или виртуальная машина на периферии сети, на которой работают сервисы координации и ретрансляции, с DNS-именем вроде rd.example.com указывающим на неё. Минимальное развёртывание на основе контейнеров часто выглядит так: ``` docker run -d --name hbbr --restart unless-stopped \ -p 21117:21117 \ -v $PWD/data:/root \ rustdesk/rustdesk-server hbbr docker run -d --name hbbs --restart unless-stopped \ -p 21115:21115 \ -p 21116:21116 \ -p 21116:21116/udp \ -v $PWD/data:/root \ rustdesk/rustdesk-server hbbs -r rd.example.com:21117 ``` И политика межсетевого экрана обычно столь же незамысловата: ``` { "name": "rustdesk-self-hosted", "ingress": [ { "proto": "tcp", "port": 21115 }, { "proto": "tcp", "port": 21116 }, { "proto": "udp", "port": 21116 }, { "proto": "tcp", "port": 21117 } ], "egress": [ { "proto": "all", "port": "all" } ] } ``` Конкретные порты и теги образов могут различаться в зависимости от выпуска, поэтому зафиксируйте их в своих заметках по развёртыванию. Неизменной остаётся эксплуатационная схема: сервис координации, сервис ретрансляции, DNS и набор правил межсетевого экрана, который вы действительно понимаете. ### Компромиссы при развёртывании | Режим развёртывания | Лучше всего подходит для | Что вы получаете | Чем вы жертвуете | Публичная инфраструктура RustDesk | Самая быстрая настройка | Простое начало работы, минимум эксплуатационных задач | Меньше контроля над маршрутизацией и политиками | Сервер ретрансляции и сервер идентификации на собственной инфраструктуре | Команды и лаборатории | Контроль, конфиденциальность, предсказуемый доступ | Вы отвечаете за доступность и установку исправлений | Традиционная удалённая поддержка через SaaS | Корпоративная служба поддержки | Развитые функции администрирования | Зависимость от поставщика, расходы и компромиссы в вопросах доверия Для машины, используемой в личных проектах, публичной инфраструктуры может быть достаточно. Для ИИ-инфраструктуры в промышленной эксплуатации самостоятельное размещение обычно является правильным выбором по умолчанию. ## Как выглядит реальный рабочий процесс Вот рабочий процесс, который я считаю обычным. У исследователя есть рабочая станция в офисе, на которой запущены сервер ноутбуков, локальные инструменты разметки и браузерная процедура входа на портал с лицензируемым набором данных. Рабочая станция недоступна через VPN, поскольку офисная подсеть сегментирована. SSH работает, но окно входа в браузере и локальное приложение с графическим интерфейсом остаются настоящими препятствиями. С RustDesk: - Установите клиент на рабочую станцию и ноутбук администратора. - Настройте оба клиента на использование серверов идентификации и ретрансляции на собственной инфраструктуре. - Убедитесь, что рабочая станция отображается с ожидаемым идентификатором. - Подключитесь с ноутбука. - Через графический интерфейс завершите вход в браузере, проверьте локальное приложение и восстановите нарушенный сеанс. - При необходимости передайте файл или конфигурацию. - Выйдите из системы, не оставляя постоянно открытого входящего доступа по типу VNC. Что происходит на практике, когда прямой маршрут не работает? Вы получаете более медленный сеанс через ретранслятор, но для администрирования это обычно приемлемо. Если вы пытаетесь смотреть видео с высокой частотой кадров или выполнять интерактивную работу с интенсивной графикой, маршрут через ретранслятор напомнит вам, что это запасной вариант, а не волшебное средство снижения задержки. Таковы реальные границы его возможностей: RustDesk отлично подходит для эксплуатационного доступа. Он не пытается выдавать себя за платформу потоковой передачи с облачных GPU. ## Место RustDesk в современном ИИ-стеке С точки зрения инфраструктуры самое интересное в RustDesk — то, что он занимает очень практичную нишу в эксплуатации ИИ. Он полезен для: - Восстановления доступа к машине с GPU когда машина загружается в сеанс рабочего стола, требующий вмешательства человека - Станций разметки которыми пользуются проверяющие без технической подготовки - Демонстрационных установок которым нужно быстро устранить проблему в графическом интерфейсе перед звонком с клиентом - Среды с полной или частичной сетевой изоляцией где разрешён SSH, но аутентификация через браузер и инструменты с графическим интерфейсом по-прежнему важны - Реагирование дежурной команды когда узел обучения технически работает, но фактически завис Современный стек ИИ — это не только обслуживание моделей и векторные базы данных. Он также включает: - рабочие станции - планировщики - хранилища - браузеры - драйверы - инструменты разметки - процессы работы с секретами - способы аварийного доступа RustDesk относится к последней категории. Это способ доступа, который стоит иметь на случай, когда система технически исправна, но работать с ней невозможно. Именно в этом качестве он хорошо дополняет другие инструменты: - SSH для администрирования преимущественно через командную оболочку - VPN для сетевого доступа - RustDesk для аварийного доступа к графическому интерфейсу и поддержки - MDM или политики для конечных устройств для управления парком устройств Если вы управляете инфраструктурой ИИ, такая комбинация реалистичнее, чем ожидание, что один инструмент справится со всеми видами сбоев. ## Плюсы и минусы ### Почему он нравится командам - Развёртывание на собственной инфраструктуре возможно на практике, а не только в теории - Разделение на клиент и сервер хорошо соответствует реальной инфраструктуре - Прямые соединения между узлами снижают нагрузку на ретранслятор, когда сеть это позволяет - Резервное подключение через ретранслятор позволяет оказывать поддержку даже при сложной сетевой топологии - Такая модель доверия лучше, чем передача всего удалённого доступа непрозрачному SaaS-сервису ### Что создаёт трудности - Вы отвечаете за сервер, DNS, межсетевой экран и доступность - Качество сеанса по-прежнему зависит от качества сети - Режим ретрансляции работает, но не идеален для задач, чувствительных к задержкам - Это всё ещё инструмент удалённого рабочего стола, поэтому он не заменяет доступ к командной оболочке, управление конфигурацией или полноценный мониторинг - Строгие корпоративные политики могут потребовать дополнительных мер контроля буфера обмена, передачи файлов и авторизации устройств Самая распространённая ошибка, которую я вижу, — считать RustDesk универсальным решением. Это не так. Это хорошо спроектированный инструмент, связывающий части эксплуатационной инфраструктуры. ## Честно об ограничениях Наиболее важны два ограничения. Во-первых, удалённый рабочий стол по своей природе зависит от состояния сеанса и графического интерфейса. Если задачу можно выполнить в терминале или через API, используйте этот способ. RustDesk должен быть запасным вариантом для особых случаев, а не основным интерфейсом администрирования. Во-вторых, размещение на собственной инфраструктуре даёт больше контроля, но не повышает надёжность автоматически. Если сервер координации соединений недоступен, правила межсетевого экрана неверны или записи DNS устарели, поведение всей системы очень быстро становится непонятным. Поэтому я всегда отношусь к серверу как к промышленной инфраструктуре, даже если это «всего лишь» небольшой вспомогательный сервис. Иными словами, стек удалённого рабочего стола на собственной инфраструктуре надёжен лишь настолько, насколько надёжна окружающая его рутинная инфраструктура. ## Практические рекомендации - Используйте RustDesk, когда вам нужен доступ к графическому интерфейсу с размещением на собственной инфраструктуре и контролем, особенно для рабочих станций ИИ и лабораторных машин. - Отдавайте предпочтение сервисы координации соединений и ретрансляции на собственной инфраструктуре если эти машины важны для вашей команды или соблюдения нормативных требований. - Храните SSH, VPN и RustDesk вместе; они помогают при разных видах сбоев. - Рассматривайте режим ретрансляции как резервный вариант, а не как ориентир производительности. - Проверьте DNS, порты и закрепление идентификатора сервера до того, как инструмент понадобится в критической ситуации. - Для команд ИИ RustDesk — это страховка при эксплуатации тех частей стека, которые недоступны через командную оболочку. [Открытый исходный код](/ru/blog/tag/open-source/)[Безопасность](/ru/blog/tag/security/)[Инженерия](/ru/blog/tag/engineering/) A [AI Prime Tech](https://aiprimetech.io/ru/) Этот блог публикует AI Prime Tech. Статьи готовятся с помощью ИИ; прежде чем полагаться на сведения, зависящие от версии, такие как идентификаторы моделей, цены и лимиты, сверяйте их с официальной документацией. Получите более дешёвый доступ к API Claude Один ключ API для Claude Opus 5.5, Sonnet 5, Haiku 4.5 и Fable 5.1, а также GPT-6 моделей. Оплата по мере использования, без подписки. [Получить ключ API →](/register) AI Prime Tech — независимый сторонний API-шлюз. Claude™ и Anthropic® — товарные знаки Anthropic, PBC. Связь с этой компанией или одобрение с её стороны не подразумеваются.