SSD Nodes Learn 🎉 VPS از $5.50/ماه
راهنماها Matt Connorتوسط Matt Connor

آموزش نصب دسکتاپ گرافیکی روی VPS لینوکسی

با نصب xrdp و XFCE روی سرور لینوکسی به دسکتاپ گرافیکی متصل شوید. برای امنیت بیشتر به جای باز کردن پورت 3389 از تونل SSH استفاده کنید و تفاوت آن با RustDesk را بدانید.

معنای واقعی دسکتاپ از راه دور روی یک VPS لینوکسی

دو محصول متفاوت در پاسخ به جستجوی «دسکتاپ از راه دور روی یک VPS لینوکسی» وجود دارند و انتخاب اشتباه، وقت شما را تلف خواهد کرد. اولی، یک واسط دسترسی از راه دور (remote-access broker) است. سرور self-hosted برنامه RustDesk نمونه رایج آن است: این برنامه یک نشست (session) را بین دو ماشینی که از قبل در اختیار دارید، مانند لپ‌تاپ و کامپیوتر خانگی‌تان، برقرار می‌کند. سرور اجاره‌ای در اینجا هیچ دسکتاپی را رندر نمی‌کند. این سرور فقط دو طرف را به یکدیگر معرفی کرده و زمانی که آن‌ها نمی‌توانند مستقیماً به هم متصل شوند، بسته‌ها را منتقل می‌کند. دومی، یک دسکتاپ گرافیکی واقعی است که روی سرور اجاره‌ای اجرا می‌شود؛ بنابراین پیکسل‌ها در دیتاسنتر ترسیم شده و برای شما استریم می‌شوند. این همان xrdp، VNC (مخفف virtual network computing) یا یک container workspace است.

یک پرسش، این دو را از هم متمایز می‌کند. وقتی کار به درستی انجام شد، نشانگر موس کجا قرار دارد؟ اگر روی ماشینی است که از قبل دارید، به یک broker نیاز دارید. اگر روی خودِ VPS است، شما به یک دسکتاپ روی VPS نیاز دارید. مورد دوم بخش عمده‌ای از مطالب زیر را به خود اختصاص داده است، زیرا موردی است که اکثر راهنماها از آن عبور می‌کنند.

کدام گزینه برای کار شما مناسب است

  • RustDesk با relay اختصاصی. این گزینه از عبور نشست (session) از طریق سرور rendezvous عمومی که توسط افراد ناشناس اداره می‌شود جلوگیری می‌کند، زیرا جفت‌کلید (key pair) در اختیار شماست. این روش از ماشینی که کنترل می‌شود محافظت نمی‌کند؛ چرا که آن ماشین همچنان همان کامپیوتری است که کلاینت را روی آن نصب کرده‌اید و با همان رمز عبوری که آن کامپیوتر دارد، کار می‌کند.
  • xrdp از طریق تونل SSH یا VPN. این روش شما را در برابر اسکن مداوم پورت 3389 در سطح اینترنت و حملات حدس رمز عبور علیه صفحه ورود RDP محافظت می‌کند، زیرا این پورت هرگز در معرض اینترنت قرار نمی‌گیرد. این روش از یک حساب کاربری با رمز عبور ضعیف در برابر کسی که قبلاً به تونل دسترسی پیدا کرده است، محافظت نمی‌کند.
  • VNC از طریق همان تونل. این گزینه یک نشست دسکتاپ به شما می‌دهد که پس از قطع اتصال باقی می‌ماند و از پروتکلی قدیمی‌تر و ساده‌تر از RDP استفاده می‌کند. VNC به تنهایی هیچ حفاظتی ایجاد نمی‌کند: تونل تمام وظایف امنیتی را بر عهده دارد، بنابراین استفاده از VNC به تنهایی روی یک پورت عمومی، بدترین گزینه در اینجا است.
  • یک فضای کاری کانتینری مانند Webtop یا Kasm. این گزینه یک مرورگر یا یک دسکتاپ کامل را در کانتینری به شما می‌دهد که می‌توانید آن را دور بریزید و دوباره بسازید؛ این کار از ماشین اصلی شما در برابر هر آنچه مرورگر با آن در تماس است، محافظت می‌کند. این روش از میزبان (host) محافظت نمی‌کند: این ایمیج‌ها با دسترسی‌های گسترده و یک sudo بدون رمز عبور اجرا می‌شوند، بنابراین کانتینر مرزی نیست که بتوانید برای بارهای کاری مخرب به آن اعتماد کنید.

نصب xrdp و XFCE روی Ubuntu 24.04

ایمیج‌های سرور VPS به‌صورت پیش‌فرض فاقد محیط گرافیکی هستند. شما ابتدا یک محیط دسکتاپ و سپس xrdp را نصب می‌کنید؛ یک سرور متن‌باز که از پروتکل RDP (پروتکل دسکتاپ از راه دور) پشتیبانی می‌کند؛ همان پروتکلی که کلاینت‌های ویندوزی از آن استفاده می‌کنند. یک دسکتاپ سبک انتخاب کنید که XFCE گزینه معمول برای این منظور است.

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

Ubuntu 24.04 در تاریخ آگوست 2026، نسخه xrdp 0.9.24 و xorgxrdp را در مخزن universe ارائه می‌دهد. بسته xorgxrdp را با نام نصب کنید، حتی اگر تنها یک بسته پیشنهادی باشد: این بسته در واقع backend سرور X است که xrdp برای نشست‌های جدید اجرا می‌کند. بدون آن، صفحه ورود رمز عبور شما را می‌پذیرد اما بلافاصله شما را به همان صفحه ورود بازمی‌گرداند.

اکنون به نشست (session) بگویید که کدام دسکتاپ را اجرا کند. 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 را ویرایش کرده و listener را در بخش [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 به معنای «اتصال را باز کن اما هیچ دستوری اجرا نکن» است، بنابراین نشست فقط برای انتقال پورت وجود دارد. آن ترمینال را باز بگذارید و کلاینت RDP خود را به 127.0.0.1:3389 هدایت کنید. در کلاینت لینوکسی، نرم‌افزار 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

در ویندوز از 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 متصل شوید.

ایجاد یک تونل برای هر نفر خسته‌کننده است، بنابراین برای یک تیم، پاسخ بهتر استفاده از یک شبکه خصوصی است. سرور را پشت یک VPN شخصی WireGuard قرار دهید، آدرس تونل 10.8.0.1 را به آن اختصاص دهید و port=tcp://10.8.0.1:3389 را تنظیم کنید تا xrdp فقط در داخل VPN پاسخ دهد. در هر صورت، قانون فایروال برای پورت 3389 نباید اصلاً وجود داشته باشد. اگر مطمئن نیستید که قوانین فعلی شما چه چیزی را مجاز می‌دانند، از اصول اولیه فایروال ufw روی VPS شروع کنید و پیش از اتصال، نه پس از آن، قوانین را بررسی کنید.

میزان رم مصرفی دسکتاپ از راه دور روی یک VPS با 2 GB رم چقدر است

انتخاب دسکتاپ تعیین می‌کند که آیا پلن 2 GB برای شما مناسب است یا خیر. ارقام زیر مقادیر تقریبی و گرد شده برای حافظه مصرفی بلافاصله پس از ورود به سیستم در Ubuntu 24.04 هستند که از مقایسه‌های منتشر شده استخراج شده‌اند و نه اندازه‌گیری روی ماشین شما. میزان مصرف خود را بلافاصله پس از اتصال با free -m اندازه‌گیری کنید.

ChartTypical memory in use after login, Ubuntu 24.04 (published figures)
The data behind this chart
[
  {
    "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 رم مصرف می‌کنند، بنابراین هر دو گزینه فضای کافی برای اجرای یک مرورگر روی یک سرور 2 GB باقی می‌گذارند. GNOME پیش از آنکه حتی یک پنجره باز کنید به حدود 1,200 MB رم نیاز دارد که در یک سیستم 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 اضافه کنید تا پس از reboot باقی بماند. وقتی برنامه‌ای بدون هشدار ناپدید شد، dmesg | grep -i "killed process" را اجرا کنید. این خط نشان می‌دهد که kernel out-of-memory killer آن را متوقف کرده است و معمولاً مرورگر قربانی اصلی است.

CPU محدودیت دیگر است و دست‌کم گرفتن آن آسان‌تر است. یک VPS فاقد GPU است، بنابراین X به رندرینگ نرم‌افزاری از طریق llvmpipe متکی است؛ این یعنی CPU تمام پیکسل‌ها را ترسیم می‌کند. اسکرول کردن یک صفحه سنگین و پخش ویدیو هر دو به عنوان بار پردازشی روی CPU ظاهر می‌شوند و به جای فریز شدن کل ماشین، نرخ فریم کاهش می‌یابد. این همان محدودیتی است که اگر در فکر امکان اجرای بازی روی VPS هستید با آن مواجه می‌شوید: برای هر چیزی که سه‌بعدی باشد پاسخ منفی است و دلیل آن دقیقاً همین است.

صدا و کلیپ‌بورد در نشست xrdp

اوبونتو 24.04 از PipeWire برای مدیریت صدا استفاده می‌کند، در حالی که قابلیت هدایت صدای xrdp برای PulseAudio طراحی شده است؛ بنابراین در نصب تازه، تصویر برقرار است اما صدایی شنیده نمی‌شود. اوبونتو پل ارتباطی لازم را در بسته‌های خود ارائه می‌دهد.

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

به‌طور کامل از نشست RDP خارج (Log out) شده و دوباره وارد شوید، زیرا این ماژول هنگام شروع نشست بارگذاری می‌شود. اتصال مجدد (Reconnect) کافی نیست. سپس از داخل نشست، وضعیت را بررسی کنید:

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

شما باید یک sink ببینید که نام آن شامل xrdp باشد و صدای تست را از طریق کلاینت خود بشنوید. اگر sink مربوط به xrdp وجود ندارد، یعنی ماژول در این نشست بارگذاری نشده است. کلاینت شما نیز باید درخواست صدا داشته باشد: این همان فلگ /sound در xfreerdp3 یا تنظیم "Remote audio" در بخش Local Resources در کلاینت ویندوزی است.

کلیپ‌بورد متنی در هر دو جهت کار می‌کند، به شرطی که xrdp-chansrv برای نشست شما در حال اجرا باشد که xrdp آن را به‌صورت خودکار برایتان شروع می‌کند. با دستور pgrep -a xrdp-chansrv آن را تأیید کنید. اگر قابلیت کپی و پیست در میان نشست از کار افتاد، یعنی آن پردازش متوقف شده است و اتصال مجدد (Reconnect) آن را دوباره راه‌اندازی می‌کند. کپی کردن فایل‌ها به جای متن، یک کانال مجزا به نام هدایت درایو (drive redirection) است: /drive:home,/home/you در xfreerdp3 یک پوشه محلی را در نشست راه دور mount می‌کند.

پنجره بازشوی polkit و سایر خطاهای اولین ورود

رایج‌ترین غافلگیری در اولین ورود، مشاهده پنجره‌ای با متن Authentication is required to create a color managed device است. علت این موضوع مشخص است. سرویس colord از polkit درخواست مجوز می‌کند؛ polkit این مجوز را فقط به نشست‌هایی می‌دهد که آن‌ها را محلی (locally seated) تشخیص دهد. از آنجا که نشست RDP محلی محسوب نمی‌شود، polkit به جای اعطای خودکار، از شما رمز عبور می‌خواهد. توزیع Ubuntu 24.04 از نسخه 124 نرم‌افزار polkit استفاده می‌کند که فایل‌های قدیمی local authority با پسوند .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 در دایرکتوری home خود را بررسی کنید. نبود فایل xorgxrdp، وجود فایلی مانند ~/.xsession که به یک محیط دسکتاپ نصب‌نشده اشاره دارد، عدم امکان نوشتن در دایرکتوری home یا پر بودن دیسک، همگی به این وضعیت منجر می‌شوند.

متصل می‌شوید و یک صفحه خاکستری با نشانگر X می‌بینید. سرور X شروع به کار کرده اما دسکتاپ اجرا نشده است. این دوباره همان مشکل ~/.xsession است: دستور xfce4-session را به‌صورت دستی از طریق SSH اجرا کنید و خطایی که چاپ می‌شود را بخوانید.

عملکرد سرور self-hosted برای RustDesk

نرم‌افزار RustDesk به دو پردازش مجزا تقسیم می‌شود. hbbs سرور ID و rendezvous است که کلاینت‌ها در آن ثبت‌نام می‌کنند و hbbr رله‌ای است که در صورت شکست اتصال مستقیم peer-to-peer، ترافیک نشست را منتقل می‌کند. هیچ‌کدام از این دو، محیط دسکتاپ اجرا نمی‌کنند. هر دو از یک image واحد استفاده می‌کنند و این فایل compose است که پروژه منتشر کرده است، با این تفاوت که آدرس relay به نام میزبان (host name) شما تغییر یافته است:

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

هر کلاینت به نام میزبان و آن کلید عمومی نیاز دارد که هر دو باید در بخش Network settings در کلاینت RustDesk وارد شوند. کلید خصوصی متناظر در ./data/id_ed25519 باقی می‌ماند. اگر دایرکتوری data را حذف کنید، سرور یک جفت کلید جدید تولید می‌کند و در نتیجه باید تمام کلاینت‌ها با کلید جدید مجدداً پیکربندی شوند. از این دایرکتوری نسخه پشتیبان تهیه کنید.

فایروال باید اجازه دسترسی مستقیم به این پورت‌ها را بدهد. 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 header برای مسیریابی وجود ندارد و هیچ درخواست HTTP برای بررسی وجود ندارد، بنابراین یک بلاک server در nginx یا یک HTTP router در Traefik هیچ معیاری برای تطبیق درخواست‌ها در اختیار ندارند. listener پروتکل UDP روی پورت 21116 نیز در هیچ لایه‌ای با HTTP مرتبط نیست.

دو روش برای این کار وجود دارد. nginx می‌تواند پورت‌های TCP را با استفاده از یک بلاک stream هدایت کند که در واقع یک forwarding ساده در لایه 4 است و نه یک reverse proxy به معنای معمول آن. همچنین پورت‌های 21118 و 21119 از websocket استفاده می‌کنند که برای کلاینت وب RustDesk به کار می‌رود و از نوع HTTP استاندارد است؛ بنابراین این دو پورت می‌توانند پشت proxy شما قرار بگیرند. اگر این کار را انجام دادید، حتماً قوانین فایروال را طوری تنظیم کنید که فقط 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 روی توزیع‌های پایه مختلف است. مستندات خود پروژه درباره ریسک‌های آن صریح است: کانتینر دسترسی سطح بالا (privileged) به میزبان دارد و شامل یک ترمینال با دسترسی sudo بدون رمز عبور است، بنابراین نباید بدون محافظت در معرض اینترنت قرار گیرد. به همین دلیل است که پورت‌های بالا به 127.0.0.1 متصل (bind) شده‌اند و روی همه آدرس‌ها منتشر نمی‌شوند. از طریق همان تونل SSH یا VPN که برای xrdp استفاده کردید، به آن متصل شوید.

Kasm Workspaces همین ایده را در مقیاس بسیار بزرگ‌تر پیاده می‌کند و شامل کنسول وب، حساب‌های کاربری و کانتینرهای مخصوص هر نشست (session) است که با پایان نشست، بازنشانی می‌شوند. این ابزار به منابع سخت‌افزاری بیشتری نسبت به یک VPS کوچک نیاز دارد. تا اوت 2026، حداقل سخت‌افزار مستندشده شامل 2 هسته CPU، 4 گیگابایت رم و 50 گیگابایت فضای SSD است و هر نشست کاربری به‌صورت پیش‌فرض به 2 هسته و 2768 مگابایت رم اضافی نیاز دارد. پلن‌های 2 گیگابایتی قادر به اجرای آن نیستند. نصب آن شامل یک دانلود و اجرای یک اسکریپت است:

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 احساس می‌شود و کانال صوتی ندارد. این پروتکل تنها در یک سناریو کاربرد خود را حفظ می‌کند: زمانی که می‌خواهید یک نشست دسکتاپ داشته باشید که پس از قطع اتصال همچنان فعال بماند و هنگام بازگشت، دقیقاً همان نشست را بازیابی کنید. 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 فقط رمز عبور را در مرحله handshake محافظت می‌کنند و پس از آن هیچ امنیتی ندارند؛ بنابراین اگر پورت عمومی باشد، محتوای نشست در شبکه قابل شنود است.

آیا یک VPS برای استفاده به عنوان دسکتاپ مناسب است؟

به عنوان یک سیستم روزمره، خیر؛ و دلایل متعددی برای این موضوع وجود دارد. در VPS پردازنده گرافیکی (GPU) وجود ندارد، بنابراین تمام پردازش‌های گرافیکی بر عهده CPU است. هر ضربه به کلید کیبورد منتظر یک رفت‌وبرگشت شبکه می‌ماند و تأخیر 40 میلی‌ثانیه‌ای که در SSH قابل‌تحمل است، در یک ویرایشگر متن کاملاً محسوس خواهد بود. ویدیو دو بار فشرده می‌شود؛ یک بار توسط سایت و بار دیگر توسط انکودر RDP. فایل‌های شما روی دیسکی قرار دارند که در اختیار شما نیست و استفاده سنگین از دسکتاپ، پهنای باند ماهانه‌ای را که برای یک وب‌سرور در نظر گرفته شده است، به‌سرعت مصرف می‌کند.

به عنوان یک ماشین یک‌بارمصرف، VPS بسیار عالی است و همان ویژگی‌ها دلیل آن هستند. آدرس IP ثابت است و متعلق به یک دیتاسنتر است؛ این همان چیزی است که وقتی یک سرویس باید آدرس ثابتی را مشاهده کند، به آن نیاز دارید. ماشین در عرض چند دقیقه از روی یک image بازسازی می‌شود، بنابراین اگر یک نشست (session) آلوده شود، هزینه‌ای برای شما نخواهد داشت. این ماشین از سخت‌افزار واقعی شما ایزوله است و حتی زمانی که لپ‌تاپ خود را می‌بندید، به کار خود ادامه می‌دهد. صورت‌حساب ساعتی باعث می‌شود یک دسکتاپ موقت، ارزان تمام شود.

اگر هنوز در حال بررسی کاربرد این ماشین هستید، خواندن فهرست کاربردی مواردی که VPS در آن‌ها عملکرد خوبی دارد پیش از نصب دسکتاپ روی آن، ارزشمند است. و اگر دلیل شما برای داشتن دسکتاپ، اجرای یک نرم‌افزار خاص ویندوزی است، ابتدا آن را با تفاوت‌های واقعی بین Linux و Windows Server بسنجید، زیرا نوع لایسنس، هزینه نهایی پاسخ شما را تغییر می‌دهد.

FAQ

آیا می‌توانم روی یک VPS با 2 GB رم، دسکتاپ از راه دور اجرا کنم؟

بله، با یک محیط دسکتاپ سبک. XFCE یا LXQt پس از ورود به سیستم حدود 300 تا 400 MB رم اشغال می‌کنند که فضای کافی برای یک مرورگر با چند تب باز باقی می‌گذارد. GNOME یا KDE Plasma روی 2 GB رم تقریباً هیچ فضایی برای برنامه‌ها باقی نمی‌گذارند. یک swap file با حجم 2 GB اضافه کنید تا در صورت فشار حافظه، سیستم کند شود و پروسه‌ها به طور ناگهانی کشته نشوند. اگر برنامه‌ای بدون هیچ پیامی ناپدید شد، dmesg | grep -i "killed process" را برای بررسی kernel out-of-memory killer چک کنید.

آیا باید پورت 3389 را روی فایروال 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 را به جای loopback، روی یک آدرس WireGuard متصل (bind) کنید.

چرا xrdp پیام "Authentication is required to create a color managed device" را نمایش می‌دهد؟

سرویس colord از polkit درخواست مجوز می‌کند و polkit این اجازه را فقط برای نشست‌های محلی (locally seated) به صورت بی‌صدا صادر می‌کند. نشست RDP به عنوان نشست محلی شناخته نمی‌شود، بنابراین در هر بار ورود با درخواست رمز عبور مواجه می‌شوید. در Ubuntu 24.04، راهکار قدیمی .pkla دیگر کارایی ندارد، زیرا polkit 124 فایل‌های local authority را حذف کرده است. فایلی در /etc/polkit-1/rules.d/45-allow-colord.rules ایجاد کنید که حاوی یک قانون JavaScript باشد و برای action idهایی که با org.freedesktop.color-manager. شروع می‌شوند، مقدار polkit.Result.YES را برگرداند، سپس sudo systemctl restart polkit را اجرا کنید.

آیا می‌توانم سرور RustDesk را پشت nginx یا Traefik قرار دهم؟

سرویس اصلی خیر. hbbs و hbbr از پروتکل‌های باینری اختصاصی خود به جای HTTP استفاده می‌کنند، بنابراین هدر Host برای مسیریابی وجود ندارد و پورت UDP 21116 به هیچ وجه نمی‌تواند از یک HTTP proxy عبور کند. پورت‌های TCP 21115 تا 21119 و UDP 21116 را روی فایروال باز کنید و اجازه دهید کلاینت‌ها مستقیماً متصل شوند. پورت‌های websocket یعنی 21118 و 21119 که توسط کلاینت وب استفاده می‌شوند، HTTP هستند و می‌توانند پشت پروکسی قرار بگیرند. در این صورت، آن‌ها را در فایروال محدود کنید تا فقط پروکسی به آن‌ها دسترسی داشته باشد، زیرا hbbs در این اتصالات به X-Real-IP اعتماد می‌کند.

چرا در نشست xrdp من صدایی وجود ندارد؟

Ubuntu 24.04 از PipeWire استفاده می‌کند، در حالی که قابلیت انتقال صدای xrdp برای PulseAudio طراحی شده است؛ بنابراین تا زمانی که bridge مربوطه را نصب نکنید، صدا نخواهید داشت. sudo apt install -y pipewire-module-xrdp را اجرا کنید، سپس از نشست کاملاً خارج (log out) شده و دوباره وارد شوید، زیرا ماژول در زمان شروع نشست بارگذاری می‌شود و اتصال مجدد (reconnect) آن را بارگذاری نمی‌کند. با pactl list short sinks بررسی کنید که آیا sink با نام xrdp وجود دارد یا خیر، و مطمئن شوید که کلاینت درخواست صدا می‌کند؛ این کار با فلگ /sound در xfreerdp3 یا گزینه "Remote audio" در کلاینت ویندوز انجام می‌شود.

#remote-desktop#xrdp#rustdesk#vnc#self-hosting