سطح مكتب رسومي على خادم Linux VPS عبر xrdp

ما الذي يعنيه سطح المكتب البعيد فعلياً على خادم VPS يعمل بنظام Linux

توجد فئتان مختلفتان من المنتجات عند البحث عن «سطح مكتب بعيد على خادم VPS يعمل بنظام Linux»، واختيار المنتج الخطأ قد يضيّع ساعات من العمل. الفئة الأولى هي وسيط للوصول عن بُعد. ويُعد خادم RustDesk المستضاف ذاتياً مثالاً شائعاً على ذلك؛ فهو يمرّر جلسة بين جهازين تملكهما مسبقاً، مثل الحاسوب المحمول والحاسوب الموجود في المنزل. لا يعرض الخادم المستأجر أي سطح مكتب. بل يعرّف الطرفين أحدهما إلى الآخر ويمرّر الحزم عندما يتعذر عليهما الوصول المباشر إلى بعضهما. الفئة الثانية هي سطح مكتب رسومي فعلي يعمل على الخادم المستأجر، لذلك تُرسم وحدات البكسل في مركز البيانات وتُبث إليك. ومن أمثلتها xrdp وVNC (الحوسبة الشبكية الافتراضية) أو مساحة عمل داخل حاوية.

يفصل بين الفئتين سؤال واحد: بعد تشغيل ذلك، أين يوجد مؤشر الماوس؟ إذا كان على جهاز تملكه مسبقاً، فأنت تحتاج إلى وسيط. وإذا كان على خادم VPS نفسه، فأنت تحتاج إلى سطح مكتب يعمل على خادم VPS. يركّز معظم ما يلي على الحالة الثانية، لأنها الحالة التي تتجاهلها معظم الأدلة.

الخيار المناسب لعملك

• RustDesk مع relay خاص بك. يحمي الجلسة من المرور عبر خادم rendezvous عام يديره أشخاص لا تعرفهم، لأنك تملك زوج المفاتيح. لكنه لا يحمي الجهاز الذي تتحكم فيه؛ فهذا الجهاز هو الكمبيوتر الذي ثبّتَّ عليه العميل، وبكلمة المرور الموجودة على ذلك الكمبيوتر.
• xrdp عبر نفق SSH أو VPN. يحميك من المسح المستمر على مستوى الإنترنت للمنفذ TCP 3389، ومن تخمين كلمات المرور ضد واجهة تسجيل الدخول إلى RDP، لأن ذلك المنفذ لا يكون مكشوفاً على الإنترنت. لكنه لا يحمي كلمة مرور حساب ضعيفة من أي شخص لديه النفق بالفعل.
• VNC عبر النفق نفسه. يوفر جلسة سطح مكتب تستمر بعد انقطاع الاتصال، باستخدام بروتوكول أقدم وأبسط من RDP. لا يوفر أي حماية بمفرده؛ فالنفق يتولى كل مهام الأمان. لذلك فإن تشغيل VNC وحده على منفذ عام هو أسوأ خيار هنا.
• مساحة عمل داخل حاوية، مثل Webtop أو Kasm. توفر متصفحاً أو سطح مكتب كاملاً داخل حاوية يمكنك حذفها وإعادة بنائها، ما يحمي جهازك الحقيقي من أي شيء يتعامل معه ذلك المتصفح. لكنها لا تحمي المضيف؛ فهذه الصور تعمل بامتيازات واسعة وبحساب 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

يتضمن Ubuntu 24.04 الإصدار 0.9.24 من xrdp وxorgxrdp ضمن مكوّن universe، اعتبارًا من August 2026. ثبّت 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 «افتح الاتصال، لكن لا تشغّل أي أمر»، لذا تبقى الجلسة قائمة لنقل المنفذ فقط. اترك تلك الطرفية قيد التشغيل، ووجّه عميل RDP إلى 127.0.0.1:3389. على عميل 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.

يصبح إنشاء نفق لكل شخص مرهقاً، لذلك يكون الحل الأفضل للفريق هو استخدام شبكة خاصة. ضع الخادم خلف شبكة WireGuard VPN مستضافة ذاتياً، وامنحه عنوان النفق 10.8.0.1، واضبط port=tcp://10.8.0.1:3389 بحيث يستجيب xrdp داخل VPN فقط. في كلتا الحالتين، يجب ألا توجد قاعدة جدار ناري للمنفذ 3389 إطلاقاً. إذا لم تكن متأكداً مما تسمح به قواعدك الحالية، فابدأ من أساسيات جدار 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. لذلك يترك كلاهما مساحة للمتصفح على خادم بسعة 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 حتى يستمر ذلك بعد إعادة التشغيل. عندما يختفي شيء من دون تحذير، نفّذ dmesg | grep -i "killed process". يعني ذلك أن قاتل العمليات عند نفاد الذاكرة في النواة أنهى العملية، ويكون المتصفح هو الضحية المعتادة.

وحدة المعالجة المركزية هي الحد الآخر، ومن السهل التقليل من أثرها. لا يحتوي VPS على GPU، لذلك يعود X إلى التصيير البرمجي عبر llvmpipe، ما يعني أن وحدة المعالجة المركزية ترسم كل بكسل. يظهر تمرير صفحة ثقيلة وتشغيل الفيديو كحمل عادي على وحدة المعالجة المركزية، وينخفض معدل الإطارات بدلاً من تجمد الآلة. هذا هو الحد نفسه الذي تصطدم به إذا كنت تتساءل عمّا إذا كان بإمكانك تشغيل الألعاب على VPS: بالنسبة إلى أي محتوى ثلاثي الأبعاد، الإجابة لا، والسبب هو ذلك تحديداً.

الصوت والحافظة في جلسة 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، أو إعداد "الصوت البعيد" ضمن الموارد المحلية في عميل Windows.

تعمل حافظة النص في الاتجاهين بعد تشغيل xrdp-chansrv لجلسة المستخدم، ويبدأ xrdp تشغيله تلقائياً. أكّد ذلك باستخدام pgrep -a xrdp-chansrv. إذا توقف النسخ واللصق أثناء الجلسة، فهذا يعني أن العملية توقفت، وتؤدي إعادة الاتصال إلى تشغيلها مرة أخرى. نسخ الملفات بدلاً من النص قناة منفصلة تُسمى إعادة توجيه محركات الأقراص: إذ تؤدي /drive:home,/home/you في xfreerdp3 إلى تركيب مجلد محلي داخل الجلسة البعيدة.

نافذة polkit المنبثقة، وحالات فشل تسجيل الدخول الأول الأخرى

أكثر المفاجآت شيوعاً عند تسجيل الدخول لأول مرة هي ظهور مربع حوار يعرض Authentication is required to create a color managed device. السبب محدد. تطلب خدمة colord إذناً من polkit، ويمنح polkit هذا الإجراء بصمت فقط لجلسة يعتبرها محلية، بينما لا تُعتبر جلسة RDP محلية، لذلك يعود polkit إلى مطالبتك بكلمة مرور. يأتي Ubuntu 24.04 مع polkit 124، الذي أزال ملفات السلطة المحلية القديمة .pkla، لذلك لا تؤثر مطلقاً على 24.04 أي إرشادات تطلب منك كتابة /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla. اكتب قاعدة 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 المستضاف ذاتياً

ينقسم RustDesk إلى عمليتين. hbbs هو خادم المعرّفات والتنسيق الذي تسجّل فيه العملاء، وhbbr هو المرحّل الذي ينقل الجلسة عندما يفشل اتصال مباشر بين الطرفين. لا تشغّل أيٌّ منهما سطح مكتب. يأتي كلاهما من صورة واحدة، وهذا هو ملف 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 في عميل RustDesk. يبقى المفتاح الخاص المطابق في ./data/id_ed25519. إذا حذفت مجلد البيانات، فسينشئ الخادم زوجاً جديداً من المفاتيح. عندها يجب إعادة إعداد كل عميل باستخدام المفتاح الجديد. أنشئ نسخة احتياطية من ذلك المجلد.

يجب أن يسمح جدار الحماية بهذه المنافذ مباشرة. يستخدم 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 يمكن التوجيه وفقاً له، ولا يوجد طلب HTTP لفحصه، لذلك لا يملك nginx كتلة server ولا يملك موجّه HTTP في Traefik شيئاً يطابقه. إن المستمع UDP على المنفذ 21116 ليس من مكوّنات HTTP على أي مستوى.

هناك خياران يعملان. يمكن لـnginx إعادة توجيه منافذ TCP باستخدام كتلة stream، وهذا مجرد إعادة توجيه في الطبقة 4، وليس Reverse Proxy بالمعنى المعتاد. ويحمل المنفذان 21118 و21119 اتصالات WebSocket التي يستخدمها عميل RustDesk على الويب، وهي HTTP عادية، لذلك يمكن وضع هذين المنفذين خلف Reverse Proxy. إذا فعلت ذلك، فأضف قواعد جدار ناري بحيث لا يستطيع الوصول إلى 21118 و21119 سوى Reverse Proxy، لأن 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 عبر اتصال بطيء، ولا يوفّر قناة صوت. يظل مناسباً في حالة واحدة: عندما تريد جلسة سطح مكتب تستمر في العمل بعد قطع الاتصال، وتريد استعادة الجلسة نفسها عند عودتك. يوفّر 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. وتبقى ملفاتك على قرص لا تملكه فعلياً، كما أن الاستخدام المكثف لسطح المكتب يستهلك حصة النطاق الترددي الشهرية، التي حُدِّدت أصلاً لخادم ويب.

لكنه مناسب جداً كجهاز مؤقت، والخصائص نفسها تفسّر ذلك. يكون عنوان IP ثابتاً وتعود ملكيته إلى مركز بيانات، وهذا ما تحتاج إليه عندما يجب أن ترى خدمة ما عنواناً ثابتاً. يمكن إعادة بناء الجهاز من image خلال دقائق، لذلك لا تكلّفك الجلسة التي التقطت شيئاً ضاراً أي شيء. ويكون الجهاز معزولاً عن أجهزتك الحقيقية، ويستمر في العمل عندما يكون حاسوبك المحمول مغلقاً. كما يجعل الفوترة بالساعة استخدام سطح مكتب مؤقت منخفض التكلفة.

إذا كنت لا تزال تحدد الغرض من هذا الجهاز، فاقرأ القائمة العملية لما يجيده VPS قبل تثبيت سطح مكتب عليه. وإذا كان سبب رغبتك في سطح مكتب هو تشغيل تطبيق Windows واحداً، فقارن ذلك أولاً بـالفروق الفعلية بين Linux وWindows Server، لأن الترخيص يغيّر تكلفة الخيار.

FAQ

هل يمكنني تشغيل سطح مكتب بعيد على VPS بسعة 2 GB؟

نعم، باستخدام سطح مكتب خفيف. يستهلك XFCE أو LXQt نحو 300 إلى 400 MB بعد تسجيل الدخول، وهذا يترك مساحة كافية لمتصفح بعدة علامات تبويب. يستهلك GNOME أو KDE Plasma على جهاز بسعة 2 GB معظم الذاكرة، ولا يترك مساحة تُذكر للتطبيقات. أضف ملف swap بسعة 2 GB حتى يبطئ ضغط الذاكرة الجهاز بدلاً من إنهاء العمليات، وعندما يختفي شيء دون رسالة، افحص dmesg | grep -i "killed process" بحثاً عن قاتل العمليات بسبب نفاد ذاكرة kernel.

هل ينبغي أن أفتح المنفذ 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 بعنوان WireGuard بدلاً من loopback.

لماذا يطلب xrdp الرسالة "Authentication is required to create a color managed device"؟

تطلب خدمة colord الإذن من polkit، ولا يمنح polkit هذا الإجراء بصمت إلا لجلسة محلية أمام الجهاز. جلسة RDP ليست جلسة أمام الجهاز، لذلك يظهر طلب كلمة المرور عند كل تسجيل دخول. في Ubuntu 24.04، لا يعالج الإصلاح القديم .pkla المشكلة، لأن polkit 124 أسقط ملفات local authority. أنشئ /etc/polkit-1/rules.d/45-allow-colord.rules بحيث يحتوي على قاعدة JavaScript تُرجع polkit.Result.YES لمعرّفات الإجراءات التي تبدأ بـorg.freedesktop.color-manager.، ثم شغّل sudo systemctl restart polkit.

هل يمكنني وضع خادم RustDesk مستضاف ذاتياً خلف nginx أو Traefik؟

ليس الخدمة الرئيسية. يستخدم hbbs وhbbr بروتوكولات ثنائية خاصة بهما بدلاً من HTTP، لذلك لا يوجد رأس Host يمكن التوجيه بناءً عليه، ولا يمكن لـUDP 21116 عبور HTTP proxy على الإطلاق. افتح TCP من 21115 إلى 21119 وUDP 21116 في الجدار الناري، ودَع العملاء يتصلون مباشرة. أما منفذا websocket، 21118 و21119، اللذان يستخدمهما عميل الويب، فيعتمدان على HTTP ويمكن وضعهما خلف proxy. إذا فعلت ذلك، فقيّدهما في الجدار الناري بحيث لا يصل إليهما إلا الـproxy، لأن 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.