RustDesk self hosted setup — دليل كامل لـ Docker + Caddy TLS

تحاول استضافة RustDesk ذاتيًّا لكنك تصطدم بنفس العوائق: NAT والجدران النارية، مكونات الخادم المربكة، والسؤال المتكرر إن كانت هناك حاجة إلى TLS فوق تشفير RustDesk نفسه. يرشدك هذا الدليل — الموجّه للقارئ التقني — خلال إعداد RustDesk ذاتي الاستضافة كامل وقابل لإعادة الإنتاج على VPS واحد: استخدم Docker Compose لـ hbbs/hbbr، وضع TLS أمام الخادم عبر Caddy حتى يتمكن العملاء من الاتصال على المنفذ 443 من شبكات مقيدة.

ما الذي نبنيه ولماذا

الهدف: خادم rendezvous وrelay على VPS واحد تُشير إليه عملاؤك باسم DNS. المكوّنات المعنية:

• rustdesk server components (hbbs and hbbr) تعمل داخل Docker — تم اختبارها هنا باستخدام صور rustdesk-server v1.2.1.
• Caddy v2 (إدارة الشهادات عبر Let's Encrypt) لتوفير مدخل TLS على المنفذ 443 بحيث يمكن للعملاء الوصول إلى المرْسِل حتى عند حظر الصادر للمنفذ 21115.
• تمرير UDP اختياري أو مرسلات إضافية للتوسع (مذكورة في الملاحظات).

لماذا نفعل هذا؟ بروتوكول RustDesk يوفر تشفير نهاية لنهاية لجلسة سطح المكتب، لكن العديد من الشبكات تسمح فقط بالاتصالات الصادرة عبر 443/80. إنهاء TLS على VPS الخاص بك (وسماح Caddy بالحصول على الشهادات وتجديدها تلقائيًا) هو طريقة عملية لجعل الخدمة متاحة دون فتح منافذ غير قياسية. إذا أردت الوصول داخل LAN أو التحكم في NAT باستخدام نفق عكسي، اطلع على مقالنا عن remote-desktop-without-port-forwarding.

المتطلبات والاختيارات

• Ubuntu 22.04 LTS على VPS عام (1 vCPU / 2 GB RAM يكفي للاختبار؛ لعدد عملاء أكبر ارفع إلى 4+ CPU وراقب CPU/RAM).
• Docker 24.x و Docker Compose v2 (صيغة سطر الأوامر compose V2).
• صورة docker لـ rustdesk-server (الوسم v1.2.1 في هذا الدليل) — عدّل الوسوم إذا كانت هناك إصدارات مستقرة أحدث.
• Caddy v2.6+ (آلية ACME الآلية في Caddy تجعل تجديد الشهادات سلسًا).
• سجل DNS من نوع A مثل rustdesk.example.com يشير إلى IP العام للـ VPS، وسماح بالمنافذ 80/443 واردة (تحتاج Caddy إلى 80/443 للتحقق الأولي).

ملاحظات متى قد يكون منتج تجاري مستضاف أنسب: إذا احتجت إلى SLA بمستوى مؤسسي، تدقيق جلسات متقدم، أو دعم تجاري، قد تكون TeamViewer/AnyDesk أنسب — راجع rustdesk-vs-anydesk ومواد المقارنة السعرية لدينا. الاستضافة الذاتية مناسبة عندما تريد تحكمًا أكبر، تكاليف متكررة أقل، أو تجنب خوادم طرف ثالث.

الخطوة 1 — نشر خادم rustdesk باستخدام Docker Compose

أنشئ دليل مشروع على الـ VPS وضع ملف docker-compose.yml أدناه. هذا المثال يعرِّض منافذ الخادم النموذجية لـ RustDesk على المضيف. عدّل متغيرات البيئة ووسوم الصور لتناسب بيئتك.

mkdir -p ~/rustdesk-server
cd ~/rustdesk-server
cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  rustdesk-server:
    image: rustdesk/rustdesk-server:1.2.1
    container_name: rustdesk-server
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"   # rendezvous / TCP relay
      - "21115:21115/udp"   # optional UDP relay (if your image supports it)
      - "21116:21116/udp"   # additional UDP (some builds use multiple UDP ports)
    volumes:
      - ./data:/root/.config/rustdesk-server
    environment:
      - RUSTDESK_RELAY_IPV4=0.0.0.0
      - RUSTDESK_RELAY_PORT=21115
EOF

شغّله:

docker compose up -d
# watch logs
docker compose logs -f rustdesk-server

تأكد أن الحاوية بدأت وتستمع على 21115. على الـ VPS شغّل:

ss -tuln | grep 21115

إذا كانت الصورة التي تستخدمها تكشف منافذ مختلفة أو لديها أسلوب تكوين مختلف، راجع README الخاص بتلك الصورة. بعض المشغلين يجمّعون hbbs/hbbr يدويًا ويستخدمون منافذ مخصصة؛ عدّل الخطوات وفقًا لذلك.

الخطوة 2 — استخدام Caddy لوضع TLS فوق المرْسِل (443)

هناك نمطان شائعان لجعل RustDesk قابلاً للوصول على 443:

1. إنهاء TLS على مستوى TCP باستخدام Caddy 2.6+ (يقوم Caddy بإنهاء TLS وإعادة توجيه TCP خام إلى مرْسِل rustdesk). أضاف Caddy ميزات TCP محسّنة في v2.6؛ باستخدام هذا الأسلوب تحصل على شهادات ACME تلقائية وتجديدات.
2. دع Caddy يدير الشهادات فقط، واستخدم وكيل TCP (stunnel أو HAProxy أو Nginx stream) لاستهلاك ملفات الشهادة هذه. هذا حل احتياطي إن كان إصدار Caddy أو بيئتك لا يدعم ميزات بروكسي TCP المطلوبة.

فيما يلي إعداد Caddy بسيط وعملي يستخدم Caddy لوضع TLS على المنفذ 443 وتحويل الاتصال TCP الخام إلى مرْسِل RustDesk على localhost:21115. هذا يتطلب Caddy v2.6+ (تحقق عبر caddy version).

# Caddyfile (save as ./Caddyfile in the same folder as docker-compose.yml)
rustdesk.example.com:443 {
    # Caddy will obtain/renew certificates automatically
    reverse_proxy 127.0.0.1:21115 {
        # Use plain TCP transport; Caddy will accept TLS from clients and connect to the backend via TCP
        transport http {
            # We don't speak HTTP to the backend; keep minimal transport settings
        }
    }
}

مقتطف Docker-compose لتشغيل Caddy بجانب خادم rustdesk (نفس المشروع):

cat >> docker-compose.yml <<'EOF'
  caddy:
    image: caddy:2.6.4
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
volumes:
  caddy_data:
  caddy_config:
EOF

docker compose up -d caddy

تحذير مهم: reverse_proxy المدمج في Caddy موجه أساسًا لـ HTTP، لذا سلوك البروكسي عند إعادة توجيه TCP الخام غير HTTP يعتمد على إصدار Caddy وخيارات النقل. عمليًا يستخدم كثيرون ميزات بروكسي TCP في Caddy 2.6 لإنهاء TLS لواجهات TCP عامة. إذا واجهت مشاكل في البروتوكول، استخدم الخيار (2) أعلاه: دع Caddy يدير الشهادات ومرّر ملفات الشهادة إلى طبقة TLS صغيرة مثل stunnel أو HAProxy stream التي تقوم بعد ذلك ببروكسي TCP عادي إلى rustdesk.

مثال: استخدام Caddy كمدير للشهادات + stunnel لإنهاء TLS (نظرة سريعة).

# 1) Ensure Caddy is running and has issued certs for rustdesk.example.com
# 2) Copy cert/key from Caddy storage into a place stunnel can read, or mount the same volume.
# 3) Run stunnel with a config that points TLS 443 -> 127.0.0.1:21115

# stunnel.conf snippet
[rustdesk]
accept = 443
connect = 127.0.0.1:21115
cert = /etc/stunnel/fullchain.pem
key = /etc/stunnel/privkey.pem

# In Docker world, mount Caddy's certificate files into the stunnel container path above.

كلتا الطريقتين تمنحك اسم مضيف (rustdesk.example.com) والمنفذ 443 للعملاء. اختبر الاتصال من جهاز آخر عبر: nc -vz rustdesk.example.com 443 — يجب أن يتم مصافحة TLS إذا كانت Caddy/stunnel مكوّنة بشكل صحيح.

الخطوة 3 — وجه العملاء إلى خادمك الذاتي

تسمح عملاء RustDesk بتعيين خوادم ID/relay مخصصة في الإعدادات. يختلف واجهة المستخدم حسب النظام والإصدار، لكن القيم الأساسية هي:

• ID Server / Rendezvous: rustdesk.example.com:443 (أو اسم النطاق والمنفذ الخاص بك)
• Relay Server: rustdesk.example.com:443

على Windows: افتح RustDesk > Settings > ID/Server واضبط Id server وRelay server على rustdesk.example.com:443. على Linux وmacOS توجد نفس الإعدادات في Preferences. في التثبيتات بدون واجهة، يمكن تزويد العميل أحيانًا بعلامات سطر أو ملف تكوين — راجع مستودع العميل للمزيد من التفاصيل.

تأكد أن العملاء محدثون (1.2.x أو أحدث وقت كتابة هذا الدليل). الإصدارات الأحدث تتضمن إصلاحات للبروتوكول وتحسينات في عبور NAT. إذا حاولت استخدام عميل أقدم كثيرًا فقد تختلف السلوكيات.

استكشاف الأخطاء والتشديد الأمني

مشكلات شائعة وكيفية استكشافها:

• جدار الحماية: تأكد من أن جدار VPS (ufw/iptables/مزود السحابة) يسمح بـ 80/443 واردة. بالنسبة لحاوية خادم RustDesk المستمعة محليًا على 21115، تحقق من وجود مقبس TCP (ss/netstat).
• إصدار الشهادة: إذا لم تتمكن Let's Encrypt من التحقق سيقوم Caddy بتسجيل خطأ. تحقق أن سجل DNS A يشير إلى VPS وأن المنفذ 80 متاح أثناء الإصدار الأولي.
• عدم تطابق البروتوكول: إذا رأيت نجاح مصافحة TLS لكن فشل الاتصالات من العميل، قد تكون قد بروكسيت HTTP فقط عبر Caddy عن طريق الخطأ. استخدم نهج stunnel في هذه الحالات.
• مرْسِل UDP: أداء RustDesk يتحسن باستخدام UDP لنقل الإطارات؛ إذا كان المسار الشبكي يحظر UDP فستتراجع إلى TCP relay. اعرض/وجه منافذ UDP فقط إذا كنت تتحكم في الشبكة وتعرف ما تفعل.

نصائح تشديد أمني:

• شغّل خادم rustdesk تحت مستخدم غير متميز مخصّص وحافظ على تحديث صور Docker.
• فعّل fail2ban أو أدوات مشابهة لخفض تكرار محاولات الاتصال الفاشلة، وراقب السجلات (docker compose logs -f rustdesk-server).
• احفظ نسخًا احتياطية لمجلد بيانات rustdesk server بانتظام (في المثال هو ./data).
• فكّر في تشغيل المرْسِل خلف شبكة خاصة أو VPC إذا كنت تدير عدة مرسلات.

ملاحظات حول التوسع: مرسل واحد يكفي للفرق الصغيرة. للنشر الأكبر، شغّل عمليات hbbr متعددة على آلات منفصلة واستخدم موازنة DNS أو موازن L4 مناسب. إذا احتجت ميزات مؤسسية مركزية مثل التدقيق، فقد تبرِز الحلول التجارية تفوّقًا. اطلع على مقالاتنا عن self-hosted-remote-desktop و rustdesk-vs-anydesk للمقارنات.

الصيانة والتكاليف والتوصيات النهائية

التكاليف التشغيلية هي في الغالب رسوم VPS ووقتك. يمكن العثور على VPS صغير شائع (1–2 CPU، 2–4 GB) بسعر $5–10/month (DigitalOcean, Vultr, Hetzner). Caddy و RustDesk server مفتوحا المصدر؛ التكلفة المتكررة الأساسية هي الاستضافة. إذا احتجت إلى فواتير بواجهة رسومية أو دعم مؤسسي، تفرض البائعون التجاريون رسومًا لكل مقعد أو لكل جلسة — راجع مقارنات الأسعار مثل anydesk-pricing-explained و godeskflow-vs-teamviewer-pricing للسياق.

التوصيات:

• ابدأ بـ VPS واحد وتخطيط Docker Compose أعلاه. اختبر الاتصالات من الشبكات نفسها التي سيكون عليها مستخدموك (مزودي إنترنت منزلية، جدران نارية للشركات).
• إذا كان العملاء غالبًا خلف جدران نارية مقيدة جدًا، ضع المرْسِل على 443 وتحقق من أن إنهاء TLS يعمل بمصداقية؛ استخدم Caddy+stunnel إذا تسبب بروكسي TCP الخاص بـ Caddy فقط بمشاكل.
• آتم نسخ احتياطية لدليل بيانات الخادم وتتبع تحديثات الصور. تصدر إصدارات RustDesk server تحديثات؛ اختبر التحديثات في بيئة تحضير إذا كنت تعتمد على توفر الإنتاج.

إذا أردت موجزًا أسرع لنماذج الوصول عن بُعد أو البدائل، اقرأ مقالاتنا ذات الصلة: remote-access-setup-guide و remote-desktop-security.

انتهيت من القراءة؟ إذا أردت تجربة سطح مكتب مفتوح المصدر يتكامل جيدًا مع الاستضافة الذاتية، حمّل GoDesk أو قارن تسعيرها — راجع GoDesk download و GoDesk pricing. إذا كنت جاهزًا لنشر هذا الإعداد لـ RustDesk، ابدأ بإنشاء docker-compose.yml و Caddyfile أعلاه وشغّل docker compose up -d. لبدء سريع، انتقل إلى /download لتحميل العملاء والاتصال.