Віддалений робочий стіл на Linux VPS через xrdp

Що насправді означає віддалений робочий стіл на Linux VPS

Пошук «віддалений робочий стіл на Linux VPS» приводить до двох різних типів продуктів. Якщо вибрати неправильний, можна втратити весь день. Перший тип — брокер віддаленого доступу. Типовий приклад — self-hosted сервер RustDesk: він ретранслює сеанс між двома вашими пристроями, наприклад ноутбуком і домашнім ПК. Орендований сервер не запускає жодного робочого стола. Він знайомить два кінцеві пристрої між собою та пересилає пакети, коли вони не можуть встановити пряме з’єднання. Другий тип — повноцінний графічний робочий стіл, який працює на орендованому сервері. Пікселі рендеряться в дата-центрі та передаються вам через мережу. До цього типу належать xrdp, VNC (virtual network computing) і робоче середовище в контейнері.

Їх розрізняє одне запитання. Коли все запрацює, де буде вказівник миші? Якщо він має бути на пристрої, яким ви вже володієте, потрібен брокер. Якщо він має бути безпосередньо на VPS, потрібен робочий стіл на VPS. Нижче переважно розглянуто другий випадок, оскільки більшість посібників його оминає.

Який варіант відповідає вашому завданню

• RustDesk із власним relay-сервером. Це захищає сеанс від проходження через публічний rendezvous-сервер, яким керують сторонні особи, оскільки ключова пара перебуває у вас. Це не захищає машину, якою ви керуєте: нею все одно є той PC, на який ви встановили клієнт, із паролем, установленим на цьому PC.
• xrdp через SSH-тунель або VPN. Це захищає від постійного сканування TCP 3389 з усього Інтернету та від підбирання паролів до вікна входу RDP, оскільки цей порт не доступний з Інтернету. Це не захищає слабкий пароль облікового запису від того, хто вже має доступ до тунелю.
• VNC через той самий тунель. Це надає сеанс робочого столу, який зберігається після розриву з’єднання, використовуючи старіший і простіший протокол, ніж RDP. Сам по собі VNC нічого не захищає: усі функції безпеки забезпечує тунель, тому самостійно відкритий VNC-порт є найгіршим варіантом у цьому переліку.
• Контейнерне робоче середовище, наприклад Webtop або Kasm. Воно надає браузер або повноцінний робочий стіл у контейнері, який можна видалити й створити заново. Це захищає вашу реальну машину від усього, з чим взаємодіє цей браузер. Воно не захищає host: такі образи працюють із широкими привілеями та безпарольним sudo усередині, тому контейнер не є межею ізоляції, якій слід довіряти під час роботи з недовіреним навантаженням.

Встановлення xrdp і XFCE в Ubuntu 24.04

Образ VPS-сервера не містить графічного робочого середовища. Спочатку встановіть його, а потім xrdp — сервер із відкритим кодом, який працює за протоколом RDP (протокол віддаленого робочого стола), тим самим протоколом, який використовує клієнт Windows. Виберіть легке робоче середовище. Зазвичай використовують XFCE.

sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies dbus-x11
systemctl is-active xrdp

Станом на August 2026 Ubuntu 24.04 містить xrdp 0.9.24 і xorgxrdp у компоненті universe. Встановіть xorgxrdp за назвою, хоча це лише рекомендований пакет: він є серверною частиною X, яку xrdp запускає для нового сеансу. Без нього вікно входу приймає пароль, а потім одразу повертає вас до вікна входу.

Тепер вкажіть сеансу, яке робоче середовище запускати. xrdp виконує /etc/xrdp/startwm.sh, а той запускає ~/.xsession, якщо цей файл існує.

echo "xfce4-session" > ~/.xsession
chmod 644 ~/.xsession

Насамкінець xrdp має читати ключ TLS (безпека транспортного рівня), який він пропонує клієнтам. Цей файл має права 640 і належить до групи ssl-cert.

ls -l /etc/ssl/private/ssl-cert-snakeoil.key
id xrdp

У списку відображається -rw-r----- 1 root ssl-cert. Якщо id xrdp не виводить ssl-cert серед груп, виконайте sudo adduser xrdp ssl-cert, а потім sudo systemctl restart xrdp. Якщо пропустити цей крок, xrdp не зможе відкрити ключ, а /var/log/xrdp.log зафіксує помилку із зазначенням імені файла snakeoil у рядку.

Чому не слід відкривати порт 3389 для Інтернету

TCP-порт 3389 постійно сканується з Інтернету, а вікно входу RDP відповідає на кожну спробу введення пароля. Не відкривайте його. Натомість прив’яжіть xrdp до loopback-адреси та підключайтеся через тунель, якому ви вже довіряєте.

Відредагуйте /etc/xrdp/xrdp.ini і змініть слухач у секції [Globals].

[Globals]
port=tcp://.:3389

У коментарях самого файлу вказано синтаксис: tcp://.:3389 означає 127.0.0.1:3389, а tcp://:3389 — усі інтерфейси. Перезапустіть службу та перевірте результат, оскільки друкарська помилка може непомітно залишити службу доступною на всіх адресах.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

Потрібно отримати 127.0.0.1:3389. Якщо ви бачите 0.0.0.0:3389, xrdp проігнорував вашу зміну. Зазвичай це означає, що рядок опинився під іншим заголовком секції нижче у файлі.

Тепер відкрийте тунель зі свого комп’ютера.

ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com

-N означає «відкрити підключення, але не запускати команду», тому сеанс існує лише для передавання порту. Не закривайте цей термінал і вкажіть 127.0.0.1:3389 як адресу в RDP-клієнті. У Linux-клієнті використовується FreeRDP 3. В Ubuntu 24.04 його бінарний файл має назву xfreerdp3:

sudo apt install -y freerdp3-x11
xfreerdp3 /v:127.0.0.1:3389 /u:you /dynamic-resolution +clipboard /sound

У Windows використовуйте вбудований mstsc і введіть 127.0.0.1 як ім’я комп’ютера. Під час першого підключення FreeRDP запропонує довірити сертифікат і виведе Do you trust the above certificate? (Y/T/N). Це очікувано для самопідписаного сертифіката snakeoil.

Якщо ssh відповідає bind [127.0.0.1]:3389: Address already in use, на вашому комп’ютері вже використовується порт 3389. Змініть локальний кінець за допомогою ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com і підключіться до 127.0.0.1:13389.

Окремий тунель для кожного користувача швидко стає незручним. Для команди краще використовувати приватну мережу. Розмістіть сервер за self-hosted VPN WireGuard, призначте йому адресу тунелю 10.8.0.1 і налаштуйте port=tcp://10.8.0.1:3389, щоб xrdp відповідав лише всередині VPN. У будь-якому разі правило firewall для порту 3389 взагалі не повинно існувати. Якщо ви не впевнені, які підключення дозволяють поточні правила, почніть із основ налаштування firewall ufw на VPS і перевірте їх до підключення, а не після.

Скільки RAM використовує віддалений робочий стіл на VPS із 2 GB

Вибраний робочий стіл визначає, чи буде тариф із 2 GB зручним, чи непридатним для роботи. Наведені нижче значення є типовими округленими показниками використання пам’яті одразу після входу в Ubuntu 24.04. Їх узято з опублікованих порівнянь, а не виміряно на вашій машині. Виміряйте власне використання за допомогою free -m одразу після підключення.

[
  {
    "label": "LXQt",
    "idle_ram_mb": 300
  },
  {
    "label": "XFCE",
    "idle_ram_mb": 400
  },
  {
    "label": "MATE",
    "idle_ram_mb": 500
  },
  {
    "label": "KDE Plasma",
    "idle_ram_mb": 800
  },
  {
    "label": "GNOME",
    "idle_ram_mb": "1,200"
  }
]

У цих 5 робочих столах важливий саме діапазон значень. LXQt використовує близько 300 MB, а XFCE — близько 400 MB. Тому на VPS із 2 GB в обох випадках залишається місце для браузера. GNOME потребує приблизно 1,200 MB ще до відкриття першого вікна. На VPS із 2 GB браузер змушений ділити залишок пам’яті з робочим столом.

Основні витрати пам’яті створює браузер, а не оболонка робочого столу. Сучасний браузер використовує від 150 до 400 MB на кожну активну вкладку. Тому VPS із 2 GB і XFCE витримує кілька вкладок, після чого починає використовувати swap. Додайте swap, щоб система сповільнювалася, а не завершувала процеси: sudo fallocate -l 2G /swapfile, потім sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile і відповідний рядок у /etc/fstab, щоб swap зберігався після перезавантаження. Якщо процес раптово зникає без попередження, виконайте dmesg | grep -i "killed process". Це означає, що його завершив механізм ядра out-of-memory killer. Зазвичай його жертвою стає браузер.

Іншим обмеженням є CPU, і його вплив легко недооцінити. VPS не має GPU, тому X переходить на програмний рендеринг через llvmpipe. Це означає, що CPU обчислює кожен піксель. Прокручування складної вебсторінки та відтворення відео відображаються як звичайне навантаження на CPU. Частота кадрів знижується, а машина не зависає. Це те саме обмеження, з яким ви стикаєтеся, коли питаєте чи можна грати на VPS: для будь-якої 3D-гри відповідь — ні саме з цієї причини.

Звук і буфер обміну в сеансі xrdp

Ubuntu 24.04 використовує PipeWire, а перенаправлення звуку в xrdp розроблялося для PulseAudio. Тому після чистого встановлення відео працює, а звук відсутній. Ubuntu постачає потрібний міст.

sudo apt install -y pipewire-module-xrdp pulseaudio-utils alsa-utils

Повністю вийдіть із сеансу RDP і увійдіть знову, оскільки модуль завантажується під час запуску сеансу. Простого повторного підключення недостатньо. Потім перевірте це в сеансі:

pactl list short sinks
speaker-test -c 2 -t wav -l 1

Ви маєте побачити sink, у назві якого згадується xrdp, і почути тестовий сигнал через клієнт. Якщо sink xrdp немає, модуль не завантажився в цей сеанс. Клієнт також має запитувати перенаправлення звуку: це прапорець /sound у xfreerdp3 або параметр "Remote audio" у розділі Local Resources клієнта Windows.

Текстовий буфер обміну працює в обох напрямках, якщо для вашого сеансу запущено xrdp-chansrv. xrdp запускає його автоматично. Перевірте це за допомогою pgrep -a xrdp-chansrv. Якщо копіювання та вставлення перестали працювати під час сеансу, цей процес завершився. Повторне підключення запустить його знову. Копіювання файлів, а не тексту, працює через окремий канал під назвою перенаправлення дисків: /drive:home,/home/you у xfreerdp3 монтує локальну папку в remote session.

Спливаюче вікно polkit та інші помилки під час першого входу

Найпоширеніша несподіванка під час першого входу — діалог із текстом Authentication is required to create a color managed device. Причина конкретна. Служба colord запитує дозвіл у polkit. polkit мовчки надає цей дозвіл лише сеансу, який вважає локальним. Сеанс RDP не є локальним, тому polkit запитує пароль. Ubuntu 24.04 постачається з polkit 124, у якому старі файли локальної політики .pkla видалено. Тому всі інструкції, у яких пропонується створити /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla, у версії 24.04 не працюють. Натомість створіть правило JavaScript.

/* /etc/polkit-1/rules.d/45-allow-colord.rules */
polkit.addRule(function(action, subject) {
    if (action.id.indexOf("org.freedesktop.color-manager.") === 0 &&
        subject.isInGroup("sudo")) {
        return polkit.Result.YES;
    }
});

Виконайте sudo systemctl restart polkit і підключіться повторно. Ще дві помилки варто розпізнавати за симптомами.

Форма входу приймає пароль і відразу знову його показує. Сеанс запустився та завершився. Спочатку перегляньте /var/log/xrdp-sesman.log, а потім ~/.xsession-errors у домашньому каталозі. До цього призводять відсутній xorgxrdp, ~/.xsession із назвою нез установленого робочого столу, домашній каталог без прав на запис або заповнений диск.

Після підключення відображається сірий екран із курсором X. X запустився, але робочий стіл — ні. Це знову ~/.xsession: вручну виконайте xfce4-session через SSH і прочитайте повідомлення про помилку, яке він виведе.

Що робить self-hosted сервер RustDesk

RustDesk складається з двох процесів. hbbs — це ID- і rendezvous-сервер, на якому реєструються клієнти, а hbbr — relay-сервер, який передає сеанс, якщо пряме peer-to-peer-з’єднання не встановлюється. Жоден із них не запускає робочий стіл. Обидва постачаються в одному image. Нижче наведено compose-файл, який публікує проєкт, із адресою relay, зміненою на ім’я вашого хоста:

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r rustdesk.example.com:21117
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
      - 21118:21118
    volumes:
      - ./data:/root
    restart: unless-stopped
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - 21117:21117
      - 21119:21119
    volumes:
      - ./data:/root
    restart: unless-stopped

Запустіть його, а потім перегляньте public key, який сервер згенерував під час першого запуску:

sudo docker compose up -d
sudo cat ./data/id_ed25519.pub

Кожному клієнту потрібні ім’я вашого хоста та цей public key. Обидва значення потрібно ввести в розділі Network settings клієнта RustDesk. Відповідний private key зберігається в ./data/id_ed25519. Якщо видалити каталог даних, сервер згенерує нову пару ключів. Після цього кожен клієнт потрібно буде повторно налаштувати з новим ключем. Створіть резервну копію цього каталогу.

Firewall має безпосередньо дозволяти ці порти. hbbs використовує TCP-порти 21115, 21116 і 21118, а також UDP-порт 21116. hbbr використовує TCP-порти 21117 і 21119.

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp

Чому RustDesk не працюватиме за nginx або Traefik

Користувачі, які вже термінують TLS для всіх сервісів на одному reverse proxy, часто намагаються зробити це й для RustDesk, але зазнають невдачі. hbbs і hbbr використовують власні бінарні протоколи через TCP і UDP, а не HTTP. Заголовка Host, за яким можна виконати маршрутизацію, немає, як і HTTP-запиту для аналізу, тому блок nginx server або HTTP-маршрутизатор Traefik не має за що зіставляти запит. UDP-слухач на порту 21116 не є HTTP-компонентом на жодному рівні.

Працюють два варіанти. nginx може переспрямовувати TCP-порти за допомогою блока stream. Це звичайне переспрямовування на рівні 4, а не reverse proxy у звичному розумінні. Порти 21118 і 21119 передають websocket-з’єднання, які використовує вебклієнт RustDesk. Це звичайний HTTP, тому ці два порти можна розмістити за вашим proxy. Якщо ви це зробите, додайте правила firewall, щоб лише proxy мав доступ до 21118 і 21119, оскільки hbbs використовує заголовок X-Real-IP у websocket-з’єднаннях, щоб визначити фактичну адресу клієнта.

Одноразовий браузер у контейнері

Іноді потрібен лише чистий браузер із незмінною IP-адресою, ізольований від вашого комп’ютера. Контейнерне робоче середовище дає це без встановлення великої кількості додаткового програмного забезпечення. Webtop від LinuxServer — легкий варіант:

services:
  webtop:
    image: lscr.io/linuxserver/webtop:latest
    container_name: webtop
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - /path/to/data:/config
    ports:
      - 127.0.0.1:3000:3000
      - 127.0.0.1:3001:3001
    shm_size: "1gb"
    restart: unless-stopped

Порт 3000 обслуговує HTTP, а 3001 — HTTPS. Доступ до робочого столу здійснюється у вкладці браузера, без RDP-клієнта. Теги образів охоплюють XFCE, KDE, MATE та i3 на базі кількох дистрибутивів. Власна документація проєкту прямо попереджає про ризик: контейнер має привілейований доступ до хоста та містить термінал із безпарольним sudo, тому його не слід залишати без захисту доступним з інтернету. Саме тому наведені вище порти прив’язані до 127.0.0.1, а не опубліковані на всіх адресах. Підключайтеся до нього через той самий SSH-тунель або ту саму VPN, яку ви використовували для xrdp.

Kasm Workspaces працює за тим самим принципом, але має значно більший масштаб: вебконсоль, облікові записи користувачів і контейнери для окремих сеансів, які скидаються після завершення сеансу. Для нього потрібні ресурси, яких немає на невеликому VPS. Станом на August 2026 задокументований мінімум становить 2 ядра CPU, 4 GB пам’яті та 50 GB SSD. Крім того, для кожного сеансу користувача за замовчуванням виділяється 2 ядра та 2768 MB. План на 2 GB не дасть змоги запустити цей продукт. Встановлення виконується завантаженням файлу та запуском скрипту:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.sh

VNC і випадки, де він досі доречний

VNC надсилає оновлення framebuffer, а не команди малювання, тому на повільному каналі він працює важче за RDP і не має аудіоканалу. VNC доречний в одній ситуації: коли потрібно, щоб сеанс робочого стола продовжував працювати після відключення, а після повернення відкривався той самий сеанс. TigerVNC це підтримує. vncserver -localhost yes :1 прив’язує Xvnc до 127.0.0.1 через TCP 5901 і відхиляє підключення з будь-яких інших адрес, тому тунелюйте його так само, як xrdp, за допомогою ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com. Ніколи не відкривайте порт VNC у публічний доступ. Більшість VNC-серверів захищає пароль під час рукостискання, але не захищає дані після нього. Тому через публічний порт вміст сеансу передається мережею у відкритому вигляді.

Чи підходить VPS як робочий стіл?

Для щоденного використання — ні. Причини швидко накопичуються. GPU немає, тому все відображає CPU. Кожне натискання клавіші залежить від затримки передавання даних мережею. Затримка 40 ms, яка майже непомітна в SSH, відчувається в текстовому редакторі. Відео стискається двічі: спочатку сайтом, а потім кодером RDP. Ваші файли зберігаються на диску, до якого ви не маєте фізичного доступу. Інтенсивне використання робочого стола також швидко витрачає місячний ліміт трафіку, розрахований на web server.

Як тимчасова машина VPS дуже добре підходить. Саме ці властивості це пояснюють. IP-адреса стабільна й належить data centre. Це потрібно, коли сервіс має бачити незмінну адресу. Машину можна відновити з image за кілька хвилин. Тому сеанс, під час якого система отримала шкідливе програмне забезпечення, не створює проблем. VPS ізольований від вашого реального обладнання. Він продовжує працювати, навіть коли ноутбук закритий. Погодинна оплата робить одноразове використання робочого стола недорогим.

Якщо ви ще визначаєте призначення цієї машини, перед інсталяцією робочого стола варто прочитати практичний перелік завдань, для яких підходить VPS. Якщо робочий стіл потрібен вам лише для однієї Windows-застосунку, спочатку порівняйте це рішення з реальними відмінностями між Linux і Windows Server, оскільки ліцензія змінює вартість такого рішення.

FAQ

Чи можна запустити віддалений робочий стіл на VPS із 2 GB пам’яті?

Так, якщо використовувати легке графічне середовище. XFCE або LXQt після входу в систему використовує приблизно 300–400 MB, тому залишається достатньо пам’яті для браузера з кількома вкладками. GNOME або KDE Plasma на VPS із 2 GB майже не залишає пам’яті для застосунків. Додайте файл підкачки розміром 2 GB, щоб під час дефіциту пам’яті система сповільнювалася, а не завершувала процеси. Якщо щось зникає без повідомлення, перевірте dmesg | grep -i "killed process" на наявність записів про kernel out-of-memory killer.

Чи потрібно відкривати порт 3389 у firewall VPS?

Ні. TCP 3389 постійно сканують, а відкритий екран входу RDP провокує спроби вгадування паролів. Установіть port=tcp://.:3389 у /etc/xrdp/xrdp.ini, щоб xrdp прослуховував лише 127.0.0.1, перевірте це за допомогою ss -tlnp | grep 3389 і підключайтеся через ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com. Якщо користувачів більше одного-двох, прив’яжіть xrdp до адреси WireGuard, а не до loopback.

Чому xrdp запитує «Authentication is required to create a color managed device»?

Сервіс colord запитує дозвіл у polkit, а polkit без запиту надає цей дозвіл лише локально активній сесії. RDP-сесія не є локально активною, тому під час кожного входу з’являється запит пароля. В Ubuntu 24.04 старе виправлення .pkla не працює, оскільки polkit 124 більше не використовує локальні authority-файли. Створіть /etc/polkit-1/rules.d/45-allow-colord.rules із правилом JavaScript, яке повертає polkit.Result.YES для ідентифікаторів дій, що починаються з org.freedesktop.color-manager., а потім виконайте sudo systemctl restart polkit.

Чи можна розмістити self-hosted сервер RustDesk за nginx або Traefik?

Основний сервіс — ні. hbbs і hbbr використовують власні бінарні протоколи, а не HTTP, тому заголовка Host, за яким можна виконувати маршрутизацію, немає. UDP 21116 також не може проходити через HTTP-проксі. Відкрийте у firewall TCP 21115–21119 і UDP 21116 та дозвольте клієнтам підключатися безпосередньо. Порти websocket 21118 і 21119, які використовує вебклієнт, працюють через HTTP і можуть бути розміщені за проксі. У такому разі обмежте їх у firewall, щоб доступ до них мав лише проксі, оскільки hbbs довіряє X-Real-IP у цих підключеннях.

Чому в моїй сесії xrdp немає звуку?

В Ubuntu 24.04 використовується PipeWire, тоді як перенаправлення звуку в xrdp розраховане на PulseAudio. Тому звук відсутній, доки не буде встановлено міст. Виконайте sudo apt install -y pipewire-module-xrdp, повністю вийдіть із сесії та увійдіть знову, оскільки модуль завантажується під час запуску сесії, а повторне підключення не завантажить його. Перевірте за допомогою pactl list short sinks наявність sink із назвою xrdp і переконайтеся, що клієнт запитує перенаправлення звуку: це прапорець /sound у xfreerdp3 або параметр «Remote audio» у клієнті Windows.