الاستضافة الذاتية لسطح المكتب البعيد: الدليل الكامل 2026 (RustDesk + GoDesk Relay)

بالنسبة لمعظم المستخدمين، فإن خدمة الريلاي المستضافة من البائع (TeamViewer و AnyDesk و GoDesk) كافية. التشفير من طرف إلى طرف يعني أن الريلاي يرى نصاً مشفراً فقط — لا يستطيع قراءة إطارات الشاشة، ضغطات المفاتيح، أو الملفات. لكن "كافية" ليست "مثالية" إذا كان لديك أحد القيود التالية:

• الامتثال: صناعة منظمة حيث يجب ألا تمر البيانات عبر بنية تحتية لطرف ثالث (قانوني، دفاعي، بعض قطاعات الرعاية الصحية).
• السيادة: لا تريد أن تُجمع بيانات تعريف الوصول البعيد (من اتصل بمن، ومتى، ولأي مدة) بواسطة أي طرف.
• التكلفة عند التوسع: إذا كنت تشغّل 100+ جهاز عبر الريلاي، فتكاليف البائع تتراكم — الريلاي المستضاف ذاتياً على VPS بقيمة $5/شهر يتعامل مع آلاف الجلسات.
• الشبكات المعزولة أو المقيدة: قد لا يكون الريلاي المقدم من البائع قابلاً للوصول من بيئتك.

إذا كان أي من ذلك ينطبق عليك، يشرح هذا الدليل كيفية الاستضافة الذاتية من الطرف إلى الطرف على VPS أساسي. الحزمة المرجعية هي RustDesk's hbbs + hbbr، التي يمكن لكل من عملاء GoDesk و RustDesk الاتصال بها. إجمالي وقت الإعداد: حوالي 30 دقيقة بما في ذلك TLS.

ما الذي ستبنيه

خدمتان:

• hbbs (rendezvous server): يتعامل مع المصافحة الأولية. يتصل به كلا العميلين لفترة وجيزة لاكتشاف بعضهما البعض، تبادل المفاتيح العامة، وتحديد ما إذا كان الاتصال P2P ممكنًا. يستمع على TCP/UDP 21115-21117.
• hbbr (relay server): إذا فشل الاتصال المباشر P2P (بسبب NAT أو جدار ناري)، يمر الترافيك عبر الريلاي. يستمع على TCP 21117 (و UDP في بعض السيناريوهات).

الريلاي يعمل فقط عندما لا ينجح P2P — وهو ما يحدث في معظم سيناريوهات المستهلك بسبب NAT، لكنه نادر في الشبكات المحلية نفسها. لذلك حتى مع الريلاي المستضاف ذاتياً، ستدفع عرض نطاق VPS فقط للجلسات التي تحتاجه.

الخطوة 1: اختر VPS

عرض النطاق هو المورد الرئيسي. CPU و RAM أساسيان (الريلاي مجرد مُمرر حزم). خيارات معقولة في 2026:

• Hetzner CX22 (€4/mo, 2 vCPU, 4 GB RAM, 20 TB bandwidth, EU data centers) — أفضل نسبة سعر إلى عرض النطاق.
• DigitalOcean Basic Droplet ($6/mo, 1 vCPU, 1 GB, 1 TB bandwidth) — تجربة مستخدم جيدة، مناطق US/EU.
• OVH VPS Starter (€3.50/mo, 2 vCPU, 2 GB, unmetered bandwidth) — الأفضل لسيناريوهات عرض النطاق العالي.
• Hetzner Storage Box — ليس VPS، مدرج لأن بعض القراء يسألون. لن يعمل لهذا الغرض؛ تحتاج خادماً فعلياً أو VPS.

اختر منطقة قريبة من مكان تواجد العملاء المتصلين — هذا يؤثر على الكمون لأن ترافيك الريلاي يعتمد على الذهاب والإياب.

الخطوة 2: إعداد الخادم

نشّئ VPS جديد على Ubuntu 22.04 أو Debian 12. اتصل عبر SSH كـ root.

# Update + harden basics
apt update && apt upgrade -y
apt install -y ufw fail2ban docker.io docker-compose-plugin
ufw allow 22/tcp     # SSH
ufw allow 21115:21119/tcp
ufw allow 21115:21119/udp
ufw enable
systemctl enable --now docker

لا تتخطى الجدار الناري. تكوين RustDesk الافتراضي يفتح فقط المنافذ المطلوبة، لكن الباقي يجب أن يُغلق.

الخطوة 3: تشغيل hbbs + hbbr عبر Docker

أنشئ /opt/godesk-relay/docker-compose.yml:

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

استبدل your-server.example.com باسم المضيف الفعلي. شغّله:

cd /opt/godesk-relay
mkdir -p data
docker compose up -d
docker compose logs --tail 20

ينبغي أن ترى hbbs يطبع مفتاحًا عامًا عند التشغيل الأول — احفظه من السجلات (id_ed25519.pub في مجلد البيانات) لأن العملاء يستخدمونه للتحقق من أنهم يتصلون بريلايَك وليس بهجوم وساطة.

الخطوة 4: إعداد DNS

الخطوة 5: توجيه العملاء إلى الريلاي المستضاف ذاتياً

هذا الجزء هو ما تتجاوزه معظم الأدلة. يحتاج كل عميل إلى ثلاث قيم تكوين:

• ID server = relay.yourdomain.com:21116
• Relay server = relay.yourdomain.com:21117
• Public key = محتوى data/id_ed25519.pub من الـ VPS الخاص بك

على Windows / macOS / Linux:

1. افتح عميل GoDesk أو RustDesk.
2. الإعدادات → الشبكة → خادم ID/Relay.
3. أدخل القيم الثلاث أعلاه. احفظ.
4. أعد تشغيل العميل.

يجب أن يتحول مؤشر الحالة إلى اللون الأخضر خلال ثوانٍ قليلة، مما يدل على أنه مسجل لدى الريلاي الخاص بك. إذا بقي أحمر، تحقق من قواعد الجدار الناري وأن المفتاح العام يطابق بالضبط.

الخطوة 6: إضافة TLS (اختياري لكن موصى به)

بروتوكول RustDesk الافتراضي مشفّر بالفعل على طبقة التطبيق (المفتاح العام الذي نسخته جزء من ذلك). إضافة TLS فوقه تضيف طبقة ثانية وتحصّن ضد بعض هجمات الاستماع السلبية على الشبكة. الإعداد يتضمن وكيل عكسي (nginx أو Caddy) أمام منافذ الريلاي.

نسخة Caddy (أبسط):

relay.yourdomain.com {
    reverse_proxy /ws/* localhost:21118
    reverse_proxy * localhost:21115
}

Caddy يصدر شهادة Let's Encrypt تلقائياً. حدّث العملاء لاستخدام المنفذ 443 مع تفعيل TLS.

الخطوة 7: نسخ المفاتيح احتياطياً

مجلد data/ يحتوي على زوج مفاتيح خادم rendezvous. إذا فقدته، يجب إعادة تكوين كل عميل بالمفتاح العام الجديد. قم بعمل نسخة احتياطية:

# Local backup
rsync -avz vps:/opt/godesk-relay/data/ ~/godesk-relay-backup-$(date +%Y%m%d)/
# OR copy the two key files
scp vps:/opt/godesk-relay/data/id_ed25519* ~/godesk-keys/

خزن النسخة الاحتياطية في مكان خارج الإنترنت. إذا تم اختراق الـ VPS، سترغب في تشغيل واحد جديد بنفس المفاتيح حتى يستمر عمل العملاء الحاليين دون إعادة تكوين.

حالات الفشل التي لا تذكرها الوثائق

الفشل 1: العملاء لا يستطيعون الوصول إلى الريلاي. في 90٪ من الحالات يكون السبب الجدار الناري. تحقق من ufw status، وتحقق من أن مجموعة أمان مزوّد السحابة تسمح بنفس المنافذ، وشغّل nc -vz relay.yourdomain.com 21116 من عميل للتحقق من إمكانية الوصول.

الفشل 2: P2P دائماً يعود إلى الريلاي. NAT متماثل أو جدران حماية شركات صارمة تجبر كل شيء على المرور عبر الريلاي. هذا طبيعي — الأداء جيد لكن يُطبّق احتساب عرض النطاق. استخدم relay.yourdomain.com مع خطة VPS بعرض نطاق عالٍ.

الفشل 3: عملية الريلاي تتوقف ولا تعود للعمل. تعيّن Docker restart: unless-stopped يتعامل مع معظم الحالات. أضف docker compose ps إلى مهمة cron تُنبهك عند اختفاء الحاويات.

الفشل 4: شهادة SSL تنتهي صلاحيتها. إذا كنت تستخدم Caddy، فالأمر تلقائي — يجدد قبل 30 يوماً من انتهاء الصلاحية. إذا كنت تستخدم nginx + certbot، أعد جدولة مهمة cron للتجديد. certbot.eff.org يحتوي على الدليل الرسمي.

حساب عرض النطاق

الجودة مهمة هنا. تقدير تقريبي:

• جودة منخفضة (عمل نصي كثيف): ~50 KB/s = 180 MB/hour
• متوسط (عمل مكتبي عام): ~200 KB/s = 720 MB/hour
• عالي (فيديو، تصميم): ~1 MB/s = 3.6 GB/hour

يستطيع Hetzner CX22 بحدود 20 TB/شهر تغطية تقريباً 5,500 ساعة من الجلسات عالية الجودة في الشهر — أكثر بكثير مما سيستخدمه فرد أو فريق صغير. حد 20 TB يصبح مهماً للمنظمات التي تملك مئات الأجهزة.

خيار جاهز مسبقاً: ريلاي قابل للاستضافة الذاتية من GoDesk

كل ما سبق هو الطريق اليدوي باستخدام حزمة RustDesk مفتوحة المصدر. GoDesk تنشر حزمة قابلة للاستضافة الذاتية لنفس حزمة hbbs/hbbr مع إعدادات افتراضية معقولة مسبقاً. إذا لم ترغب في إدارة ملفات Docker compose، راجع دليل الاستضافة الذاتية — نفس البنية، مع سكربت تثبيت بأمر واحد يلف الخطوات أعلاه.

متى لا تستضيف ذاتياً

الاستضافة الذاتية تضيف عبئاً عملياتياً: المراقبة، نسخ المفاتيح احتياطياً، تحديثات نظام التشغيل، تجديد الشهادات. إذا كانت حالتك "أريد الوصول إلى حاسوبي المنزلي عن بُعد"، فالريلاي المستضاف من البائع (طبقة GoDesk المجانية تغطي 5 GB/month) أسهل بكثير من تشغيل VPS إلى الأبد.

استضف ذاتياً إذا كان لديك سبب حقيقي — امتثال، سيادة، تدرج. تجنّبه إذا كان الدافع الوحيد أنه "سيكون ممتعاً"؛ العبء التشغيلي سيلحق بك في النهاية.

الخلاصة

1. $5/month VPS في المنطقة التي تفضلها.
2. Docker + UFW + RustDesk's hbbs/hbbr containers.
3. سجل DNS A يشير إلى الـ VPS.
4. ثلاث قيم تكوين على كل عميل (ID server, relay server, public key).
5. نسخ المفاتيح احتياطياً.
6. اختياري: TLS عبر Caddy/nginx.

وقت إعداد من الطرف إلى الطرف: 30 دقيقة. الصيانة الجارية: قليلة. النتيجة: سطح مكتب بعيد لا يمر ترافيكه عبر بنية تحتية تابعة لأي طرف ثالث.

لمزيد حول جانب GoDesk من هذا الموضوع — توثيق الاستضافة الذاتية، مستقبل المصادر المفتوحة، أو تنزيل العميل.