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

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

دو محصول متفاوت به جستجوی عبارت "remote desktop on a Linux VPS" پاسخ می‌دهند و انتخاب اشتباه، وقت زیادی از شما تلف خواهد کرد. اولی یک واسط دسترسی از راه دور (remote-access broker) است. سرور self-hosted نرم‌افزار RustDesk نمونه رایج آن است: این ابزار یک نشست را بین دو ماشینی که از قبل در اختیار دارید، مثلاً لپ‌تاپ شما و کامپیوتر خانگی‌تان، برقرار می‌کند. سرور اجاره‌ای در این حالت هیچ دسکتاپی را ترسیم نمی‌کند. این سرور فقط دو طرف را به یکدیگر معرفی کرده و زمانی که آن‌ها نمی‌توانند مستقیماً به هم متصل شوند، بسته‌ها را منتقل می‌کند. دومی یک دسکتاپ گرافیکی واقعی است که روی سرور اجاره‌ای اجرا می‌شود؛ بنابراین پیکسل‌ها در دیتاسنتر ترسیم شده و برای شما استریم می‌شوند. این همان 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 را نصب می‌کنید؛ 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، نسخه 0.9.24 از xrdp و 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 گیگابایت رم چقدر است

انتخاب دسکتاپ تعیین می‌کند که آیا پلن 2 گیگابایتی برای شما مناسب است یا خیر. ارقام زیر مقادیر تقریبی و گرد شده برای میزان حافظه مصرفی بلافاصله پس از ورود به سیستم در 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 مگابایت و XFCE در حدود 400 مگابایت رم مصرف می‌کنند؛ بنابراین هر دو گزینه فضای کافی برای اجرای یک مرورگر روی یک سرور 2 گیگابایتی باقی می‌گذارند. GNOME پیش از آنکه حتی یک پنجره باز کنید، حدود 1,200 مگابایت رم اشغال می‌کند که در یک سیستم 2 گیگابایتی، باعث می‌شود مرورگر برای باقی‌مانده منابع با دسکتاپ رقابت کند.

هزینه اصلی منابع، مرورگر است، نه پوسته دسکتاپ. یک مرورگر مدرن بین 150 تا 400 مگابایت به ازای هر تب فعال مصرف می‌کند؛ بنابراین یک VPS با 2 گیگابایت رم که 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 آن را تأیید کنید. اگر کپی و پیست در میان نشست از کار افتاد، یعنی آن پردازش متوقف شده است و اتصال مجدد آن را دوباره راه‌اندازی می‌کند. کپی کردن فایل‌ها به‌جای متن، یک کانال جداگانه به نام هدایت درایو (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 از polkit 124 استفاده می‌کند که فایل‌های قدیمی 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 اجرا کنید و خطای چاپ‌شده را بخوانید.

عملکرد سرور RustDesk در حالت self-hosted

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

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

سرویس را بالا بیاورید و سپس کلید عمومی که سرور در اولین اجرا تولید کرده است را بخوانید:

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

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

فایروال باید اجازه دسترسی مستقیم به این پورت‌ها را بدهد. 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 مدیریت می‌کنند، در این مورد با شکست مواجه می‌شوند. پروتکل‌های hbbs و hbbr از پروتکل‌های باینری اختصاصی خود روی TCP و UDP استفاده می‌کنند، نه HTTP. در این پروتکل‌ها هیچ Host header برای مسیریابی و هیچ درخواست HTTP برای بررسی وجود ندارد، بنابراین یک بلاک server در nginx یا یک HTTP router در Traefik هیچ پارامتری برای تطبیق (match) ندارد. 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 برای استفاده به عنوان دسکتاپ مناسب است؟

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

به عنوان یک ماشین یک‌بارمصرف، بسیار عالی است و همان ویژگی‌ها دلیل آن را توضیح می‌دهند. آدرس 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 متصل کنید.

چرا 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 را اجرا کنید، سپس کاملاً از نشست خارج شده و دوباره وارد شوید، زیرا ماژول در زمان شروع نشست بارگذاری می‌شود و اتصال مجدد (reconnect) آن را بارگذاری نمی‌کند. با استفاده از pactl list short sinks بررسی کنید که آیا sink با نام xrdp وجود دارد یا خیر، و مطمئن شوید که کلاینت درخواست صدا می‌کند؛ این کار با استفاده از فلگ /sound در xfreerdp3 یا گزینه "Remote audio" در کلاینت ویندوز انجام می‌شود.