لماذا تستضيف خادم سطح المكتب عن بُعد بنفسك
للحلول التجارية كـTeamViewer وAnyDesk خاصية مشتركة: كل اتصال يمر عبر بنية التتابع الخاصة بهم، بغض النظر عن المسافة الفعلية بين الجهازين. هذا يخلق ثلاث مشاكل عملية.
الخصوصية والامتثال. تتدفق البيانات عبر خوادم طرف ثالث خاضعة لقوانين بلد استضافتهم. لمزودي تقنية المعلومات الذين يصلون إلى الأنظمة المالية والطبية والقانونية، هذا التفويض الضمني قد يُبطل اتفاقية الامتثال (GDPR، ISO 27001، HIPAA). RustDesk المستضاف ذاتياً يلغي هذه التبعية: الحركة المشفرة تبقى في مركز بياناتك.
تاريخ الثغرات الأمنية. تعرضت TeamViewer لعدة حوادث بارزة — في 2016 تعرضت آلاف الحسابات للاختراق عبر حشو بيانات الاعتماد؛ وفي 2024 نُسب اختراق البيئة المؤسسية إلى مجموعة APT. هذه الحوادث لا تطعن في البروتوكول، لكنها تؤكد أن الاعتماد على طرف ثالث يعني الاعتماد على سطح هجومه.
تكلفة التراخيص. TeamViewer Business يبدأ من أكثر من 600 يورو/سنة لمستخدم متزامن واحد. AnyDesk أرخص لكنه لا يزال على نموذج لكل مقعد. RustDesk المستضاف ذاتياً يخفض التكلفة إلى تكلفة VPS فحسب — ServOrbit بدءاً من 99 درهم/شهر يكفي لفريق كامل.
ما يمنحكم RustDesk المستضاف ذاتياً
- لا حدود للجلسات — لا ترخيص لكل مقعد ولا حصة اتصالات متزامنة؛ خادمكم يخدم كل المستخدمين الذين يستطيع VPS استيعابهم
- تشفير شامل مضمون — منحنى Ed25519 لتبادل المفاتيح، ChaCha20-Poly1305 لبث الفيديو ومدخلات لوحة المفاتيح/الفأرة: المفتاح العام لخادمكم مضمّن في العميل مما يجعل الاعتراض مستحيلاً هيكلياً
- كمون تحت السيطرة — التتابع في مركز البيانات الذي تختارونه؛ باختيار المنطقة الأقرب لفرقكم يكون RTT أقل باستمرار من تتابع SaaS عام في شمال أوروبا
- عملاء متعددو المنصات — Windows وmacOS وLinux وAndroid وiOS ومتصفح الويب من خادم مركزي واحد بلا تكوينات مختلفة لكل منصة
- معرفات مخصصة — خصصوا معرفات سهلة التذكر (
SERVER-DB-01,LAPTOP-ALICE) بدلاً من المعرفات الرقمية العشوائية الافتراضية - REST API مدمجة — RustDesk Server Pro يكشف REST API للاستعلام عن حالة الاتصالات وسرد الأجهزة المسجلة وأتمتة التوفير عبر سكريپتاتكم أو CMDB
- سجل تدقيق كامل للجلسات — كل اتصال وانقطاع ونقل ملفات موثق بطابع زمني من جانب الخادم؛ ضروري للبيئات الخاضعة لمتطلبات إمكانية التتبع
معمارية RustDesk: hbbs وhbbr
يفصل RustDesk دور الإشارة عن دور التتابع في عمليتين مستقلتين.
hbbs — خادم التجمع (خادم الهوية). هذه نقطة الدخول. كل عميل RustDesk يبدأ ويسجل بمعرف رقمي (أو مخصص). عند بدء اتصال، يتصل الطرفان بـhbbs لتبادل عناوين IP ومحاولة اتصال P2P مباشر. يستمع hbbs على المنافذ TCP 21115 و21116 وUDP 21116.
hbbr — خادم التتابع. إذا فشل اتصال P2P (NAT متماثل، جدار حماية مقيد)، يُتابَع حركة المرور عبر hbbr. التتابع يرى فقط تدفقات مشفرة — لا يستطيع قراءة المحتوى. يستمع hbbr على المنفذ TCP 21117.
تدفق الاتصال. الجهاز A يتصل بـhbbs عبر TCP للحصول على عنوان الجهاز B. يحاول الجهازان اتصالاً UDP مباشراً (hole punching). إذا نجح، لا يُشرك hbbr وتكون الكمون في حدها الأدنى. إذا فشل، يزود hbbs الجهاز A بعنوان hbbr للتتابع — مع عبء طفيف بضعة ملي ثانية. عملياً، P2P ينجح في غالبية شبكات المنازل والمؤسسات التي لا تستخدم NAT صارماً.
متطلبات VPS
الحد الأدنى من الموارد. 1 غيغابايت RAM و1 vCPU كافيان حتى نحو 20 اتصالاً متزامناً في وضع التتابع. بعد ذلك، العامل المحدد هو النطاق الترددي: بث Full HD يُشفَّر بحوالي 2-4 ميغابت/ث. لـ50 اتصالاً متزامناً عبر التتابع، خططوا لـ2 vCPU و2 غيغابايت RAM وVPS بإنتاجية مضمونة لا تقل عن 200 ميغابت/ث.
المنافذ المطلوب فتحها.
- TCP 21115 — تفاوض NAT
- TCP 21116 — تسجيل الهوية
- UDP 21116 — hole punching لـP2P
- TCP 21117 — البث المتابَع
- TCP 21118 و21119 — عميل الويب (اختياري)
- TCP 443 — واجهة الإدارة HTTPS (إذا فُعّلت)
البرامج المطلوبة. Docker Engine 24+ وDocker Compose v2 (الأمر docker compose بدون شرطة). يُنصح باسم نطاق أو نطاق فرعي لكشف واجهة الإدارة خلف TLS — وإلا تعمل اتصالات الإدارة بـHTTP غير مشفر.
نشر RustDesk Server على VPS
إنشاء الدليل وملف docker-compose.yml
أنشئوا هيكل الأدلة وملف Compose:
mkdir -p /opt/rustdesk/data cd /opt/rustdeskمحتوى ملف
docker-compose.yml:services: hbbs: image: rustdesk/rustdesk-server:latest command: hbbs ports: - "21115:21115" - "21116:21116" - "21116:21116/udp" - "21118:21118" volumes: - ./data:/root restart: unless-stopped depends_on: - hbbr hbbr: image: rustdesk/rustdesk-server:latest command: hbbr ports: - "21117:21117" - "21119:21119" volumes: - ./data:/root restart: unless-stoppedحجم
./dataالمشترك يضمن أن hbbs وhbbr يستخدمان زوج المفاتيح نفسه المُولَّد عند الإطلاق الأول.تشغيل الحاويات واسترداد المفاتيح
شغّلوا الخدمتين في الخلفية:
docker compose up -dعند الإطلاق الأول، يُولِّد hbbs تلقائياً زوج مفاتيح Ed25519 في
./data/. استردوا المفتاح العام:cat /opt/rustdesk/data/id_ed25519.pubسجّلوا هذه القيمة — ستحتاجونها لتهيئة كل عميل. بدونها يرفض العملاء الاتصال بخادمكم. احتفظوا أيضاً بـ
id_ed25519(المفتاح الخاص) في مكان آمن؛ إذا تعرض للاختراق، سيحتاج جميع العملاء إعادة تهيئة بمفتاح جديد.تهيئة جدار الحماية (منافذ TCP/UDP)
افتحوا المنافذ الضرورية في ufw:
ufw allow 21115/tcp ufw allow 21116/tcp ufw allow 21116/udp ufw allow 21117/tcp ufw allow 21118/tcp ufw allow 21119/tcp ufw reloadإذا كان VPS محمياً أيضاً بجدار حماية شبكي في لوحة ServOrbit، طبّقوا القواعد ذاتها هناك. ثم تحققوا من أن المنافذ في حالة استماع:
ss -tlnup | grep -E '2111[5-9]'كشف واجهة الإدارة خلف reverse proxy HTTPS
RustDesk Server Pro يوفر واجهة إدارة ويب على المنفذ 21114 (HTTP). لكشفها عبر HTTPS، أضيفوا nginx كـreverse proxy.
تكوين nginx الأدنى لـ
rustdesk.نطاقكم.com:server { listen 443 ssl; server_name rustdesk.نطاقكم.com; ssl_certificate /etc/letsencrypt/live/rustdesk.نطاقكم.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/rustdesk.نطاقكم.com/privkey.pem; location / { proxy_pass http://127.0.0.1:21114; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }احصلوا على الشهادة بـCertbot:
certbot --nginx -d rustdesk.نطاقكم.comتهيئة عملاء سطح المكتب (Windows وmacOS وLinux)
حمّلوا عميل RustDesk من [rustdesk.com](https://rustdesk.com) وافتحوا إعدادات الشبكة (أيقونة الترس ← الشبكة). أدخلوا:
- خادم الهوية: عنوان IP أو اسم نطاق VPS الخاص بكم
- خادم التتابع: نفس القيمة
- المفتاح: القيمة المنسوخة منid_ed25519.pubأكّدوا. مؤشر الاتصال يتحول للأخضر إذا كان الخادم قابلاً للوصول والمفتاح صحيحاً. من هذه اللحظة، لا تمر أي محاولة اتصال عبر خوادم RustDesk العامة.
تهيئة العملاء المحمولين (Android وiOS)
على Android، ثبّتوا RustDesk من Play Store أو مباشرة عبر APK (مفيد إذا كان Play Store مقيداً على بعض أجهزة المؤسسات). على iOS، RustDesk متاح على App Store.
في كلتا الحالتين، انتقلوا إلى الإعدادات ← خادم الهوية/التتابع وأدخلوا نفس القيم كعميل سطح المكتب: عنوان الخادم والمفتاح العام. يمكن مشاركة المفتاح عبر QR من واجهة إدارة RustDesk Server Pro، مما يبسّط النشر الجماعي على أسطول الأجهزة المحمولة.
اختبار اتصال شامل من طرف إلى طرف
على جهازين مهيّئين بخادمكم، لاحظوا المعرف المعروض على الجهاز الهدف. من الجهاز المصدر، أدخلوا هذا المعرف في حقل الاتصال بـRustDesk وابدأوا الجلسة.
تحققوا من السجلات أن الاتصال يمر عبر بنيتكم التحتية:
docker logs rustdesk-hbbr-1 --tail 20سطر يحتوي
[RELAY]يشير لاستخدام التتابع (NAT صارم). سطر[DIRECT]أو غياب السطور في سجلات hbbr يشير لاتصال P2P مباشر — مثالي للكمون.
تهيئة TLS للاتصالات الآمنة
افتراضياً، بثوث RustDesk مشفرة شاملاً بـChaCha20-Poly1305 — TLS إضافي غير مطلوب لجلسات سطح المكتب عن بُعد نفسها. لكن واجهة الإدارة (المنفذ 21114) وREST API تعمل بـHTTP غير مشفر إذا لم تحميهما.
الخيار 1: Certbot + nginx (موصى به). كما في الخطوة 4، nginx يعمل كـreverse proxy أمام المنفذ 21114. Certbot يجدد الشهادة تلقائياً عبر مؤقت systemd.
الخيار 2: Traefik كـedge proxy. إذا كنتم تستخدمون Traefik بالفعل لخدمات أخرى على نفس VPS، أضيفوا ببساطة labels لخدمة hbbr في Compose:
labels:
- "traefik.enable=true"
- "traefik.http.routers.rustdesk-admin.rule=Host(`rustdesk.نطاقكم.com`)"
- "traefik.http.routers.rustdesk-admin.tls.certresolver=letsencrypt"
- "traefik.http.services.rustdesk-admin.loadbalancer.server.port=21114"ما يبقى غير مشفر بالتصميم. المنافذ 21115-21119 لا تستخدم HTTPS لأنها تستخدم بروتوكولاتها الثنائية الخاصة. تشفير هذه التدفقات تعالجه مفاتيح Ed25519 وChaCha20 — ليس TLS. لا تحاولوا إجبار HTTPS على هذه المنافذ.
تفعيل المصادقة والتحكم في الوصول
الإصدار مفتوح المصدر من RustDesk Server لا يوفر واجهة مصادقة أصيلة — أي عميل يعرف مفتاحكم العام يستطيع محاولة الاتصال بجهاز مسجل (إذا قبل الجهاز الطلب). RustDesk Server Pro (قابل للاستضافة الذاتية، مجاني حتى 20 مستخدماً) يضيف طبقات تحكم متعددة.
حسابات المستخدمين والمجموعات. واجهة الإدارة تتيح إنشاء حسابات مسماة وتجميعها وتعريف سياسات الوصول لكل مجموعة. تقني يمكنه الوصول فقط لأجهزة مجموعة 'البنية التحتية'، لا إلى أجهزة الموارد البشرية.
موافقة الاتصال. كل جهاز يمكن تهيئته لطلب تأكيد فعلي من المستخدم المحلي قبل السماح بالتحكم عن بُعد — نافذة 'قبول الاتصال' تظهر على شاشة الجهاز الهدف.
سجل تدقيق كامل. كل حدث (اتصال بُدئ، قُبل، رُفض، المدة، نقل الملفات) مسجل بهوية المبادر والطابع الزمني. السجلات قابلة للتصدير كـCSV من واجهة الإدارة.
تعطيل الخوادم العامة. لإجبار الاستخدام الحصري لخادمكم — بدون fallback لتتابعات RustDesk العامة عند عدم توفر خادمكم — أضيفوا الخيار --key مع مفتاحكم الخاص لأمر hbbs. العملاء المهيّأون بمفتاحكم العام سيرفضون أي خادم بديل، بما في ذلك خادم RustDesk الرسمي.
تحسين جودة الصورة والأداء
يستخدم RustDesk افتراضياً كودك الفيديو الخاص به (VP9 أو H.264 حسب المنصة) بجودة تكيفية مبنية على النطاق الترددي المكتشف. عدة عوامل تتيح ضبط هذا السلوك.
جودة الصورة. في إعدادات العميل، يمكن ضبط 'جودة الصورة' على منخفض أو متوسط أو عالٍ أو مخصص. في بيئات المؤسسات على شبكة LAN أو VPS قريب جغرافياً، 'عالٍ' قابل للاستخدام دون إشباع النطاق الترددي. على اتصال محمول أو بُعد جغرافي كبير، 'متوسط' يقلل الكمون المدرَك.
الكودك. RustDesk يختار تلقائياً أفضل كودك متاح: H.265 إذا كان الطرفان يملكان تشفيراً/فك تشفير بالأجهزة، وإلا VP9. على VPS بدون GPU، VP9 هو الافتراضي — معقول في استهلاك المعالج لتدفقات المكتب. تجنبوا إجبار H.264 على VPS بمعالج ضعيف إذا كان لديكم اتصالات متزامنة متعددة.
P2P مقابل التتابع. اتصال P2P المباشر دائماً مفضل: يتجنب القفزة الإضافية عبر hbbr ويقلل الكمون بـ5 إلى 20 ملي ثانية. إذا كان مستخدموكم يتصلون من نفس شبكة LAN كالجهاز الهدف، تحققوا أن جدار الحماية لا يمنع اتصالات UDP المباشرة بين المضيفين — RustDesk يحاول P2P أولاً قبل التراجع إلى التتابع.
RustDesk مقابل TeamViewer وAnyDesk وGuacamole
مرّر الجدول أفقيًا
| المعيار | RustDesk (مستضاف ذاتياً) | TeamViewer | AnyDesk | Guacamole |
|---|---|---|---|---|
| نموذج الاستضافة | مستضاف ذاتياً (VPS) | SaaS (سحابة المورد) | SaaS (سحابة المورد) | مستضاف ذاتياً (خادم ويب) |
| تكلفة الترخيص | مجاني (OSS) / Pro مدفوع | من 600 يورو/سنة/مستخدم | من 180 يورو/سنة/مستخدم | مجاني (Apache 2.0) |
| البروتوكول | مشفر خاص (Ed25519 + ChaCha20) | خاص (هجين RDP/VNC) | DeskRT (كودك خاص) | VNC / RDP / SSH عبر المتصفح |
| اتصال P2P | نعم (مع fallback للتتابع) | لا (دائماً عبر السحابة) | نعم (مع fallback) | لا (وكيل مركزي) |
| عملاء محمولون أصيلون | Android + iOS أصيلان | Android + iOS أصيلان | Android + iOS أصيلان | متصفح فقط |
| سجل التدقيق | نعم (Pro) | نعم (Business+) | نعم (Business+) | محدود (سجلات خادم خام) |
| REST API | نعم (Pro) | نعم (مدفوع) | لا (API طرف ثالث) | نعم (REST جزئي) |
| سيادة البيانات | كاملة (بنيتكم التحتية) | معدومة (سحابة TeamViewer) | جزئية (تتابع AnyDesk) | كاملة (بنيتكم التحتية) |
النشر المؤسسي: توفير العملاء بصورة جماعية
يدعم RustDesk التهيئة التلقائية عبر ملف تهيئة مضمّن في تنفيذ العميل. عند البناء أو التعبئة لأسطولكم، ضعوا ملف RustDesk2.toml في دليل التهيئة بقيمكم:
relay-server = "vps-خاصتكم.example.com"
id-server = "vps-خاصتكم.example.com"
key = "<مفتاحكم_العام_ed25519>"على Windows، يذهب هذا الملف إلى %APPDATA%\RustDesk\config\. على Linux، إلى ~/.config/rustdesk/. يمكنكم نشر هذا التهيئة عبر أداة إدارة أسطولكم (Ansible، Intune، Puppet) بلا تفاعل مستخدم. المفتاح العام وعنوان الخادم محمّلان مسبقاً — المستخدم يثبّت RustDesk ويجد نفسه متصلاً مباشرة ببنيتكم التحتية.
مراقبة الخادم وصيانته
مقاييس Docker. راقبوا استهلاك الموارد في الوقت الفعلي بـdocker stats — ارتفاع المعالج على hbbr يشير لعدد غير معتاد من الاتصالات المتابَعة. إذا تجاوز المتوسط 80% لعدة دقائق، فكّروا في زيادة vCPU أو التحقق من أن اتصالات عالقة تولّد حلقات retry.
تدوير السجلات. الحاويات تكتب في stdout/stderr يديرها Docker daemon. أضيفوا سياسة تدوير في docker-compose.yml لمنع السجلات من ملء القرص:
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "5"تحديث الصورة. RustDesk ينشر إصدارات جديدة بانتظام. للتحديث بأدنى انقطاع ملحوظ:
docker compose pull
docker compose up -dDocker يستبدل الحاويات واحدة تلو الأخرى. الجلسات الجارية عبر hbbr تنقطع خلال إعادة التشغيل (ثوانٍ قليلة) — فضّلوا التحديثات في ساعات الذروة المنخفضة. المفاتيح في ./data/ محفوظة — لا تهيئة عملاء مطلوبة.
حل المشاكل الشائعة
الاتصال مستحيل، الهوية غير موجودة. تحققوا أن hbbs يعمل (docker ps) وأن المنافذ TCP 21115-21116 وUDP 21116 قابلة للوصول من الخارج: nc -vz <ip-vps> 21116. إذا فشل الاختبار، جدار الحماية الشبكي (ufw أو قاعدة VPS) يحجب المنفذ.
'مفتاح غير صحيح' في العميل. المفتاح المعروض في العميل لا يتطابق مع id_ed25519.pub على الخادم. أعيدوا قراءة القيمة الدقيقة بـcat /opt/rustdesk/data/id_ed25519.pub وأعيدوا تهيئة العميل — انتبهوا للمسافات أو فواصل الأسطر الزائدة عند النسخ واللصق.
دائماً في وضع التتابع، لا P2P أبداً. hole punching UDP يفشل إذا استخدمت إحدى الشبكتين NAT متماثلاً (شائع على بعض شبكات 4G/5G المحمولة وVPN المؤسسات). هذا ليس خللاً — التتابع يعمل بصحة، مع كمون أعلى قليلاً. للتشخيص القسري، قارنوا سجلات hbbr مع وبدون VPN نشط من جانب العميل.
واجهة الإدارة غير قابلة للوصول. المنفذ 21114 غير مكشوف في docker-compose.yml الأساسي — يجب إضافته صراحة أو الوصول عبر nginx reverse proxy في الخطوة 4. تحققوا أيضاً من استخدامكم صورة rustdesk-server-pro (الإصدار مفتوح المصدر لا يوفر واجهة إدارة).
تحديث الصورة دون إعادة توليد المفاتيح. بعد docker compose pull && docker compose up -d، تحققوا أن ./data/id_ed25519.pub لم يتغير — لا ينبغي أن يتغير، لكن تلف حجم التخزين قد يعيد توليد الزوج في حالات نادرة. إذا تغير المفتاح، سيحتاج جميع العملاء إعادة تهيئة.
