rustdesk docker: دليل تشغيل خادم RustDesk داخل حاويات

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

لماذا استخدام Docker مع RustDesk

توفر الحاويات ميزتين مباشرتين لكومة الوصول عن بُعد المستضافة ذاتياً: نشرات قابلة لإعادة الإنتاج وعزل. بدلاً من تجميع hbbs/hbbr محلياً أو تشغيل حزم مخصصة بنظام التشغيل، تقوم بسحب صورة Docker، تركيب مجلد بيانات دائم وبدء الحاوية. هذا يبسط التحديثات، CI/CD وترحيل المضيف. إذا كنت تشغل خدمات أخرى في حاويات (NGINX، certbot، مراقبة)، فإن إضافة RustDesk بهذه الطريقة تحافظ على تماسك الكومة لديك.

متى لا تستخدم الحاويات: إذا احتجت إلى ثنائيات مُعدَّلة مخصصة أو تكامل عميق مع النواة لأجل مزودية relay عالية الأداء جداً، فقد يكون التثبيت الأصلي أفضل. كذلك، إذا احتجت إلى SLA مدعوم رسمياً من بائع تجاري، تحقق مما إذا كانت الحاويات مدعومة من ذلك البائع.

مكوّنات خادم RustDesk — لمحة موجزة

يقسم RustDesk دور الخادم إلى قطعتين على الأقل:

• hbbs — خادم الهوية/الإشارة. يتولى التسجيل والالتقاء للعملاء.
• hbbr — خادم الترحيل (relay) عندما يفشل اجتياز NAT. يقوم بتمرير حركة المرور بين الأطراف.

في البيئة الإنتاجية عادةً ما تشغل كلا الخدمتين. يمكن لمضيف خفيف واحد تشغيلهما؛ في نشرات أكبر تفصلهما وتضع مثيلات hbbr خلف موازن تحميل وتضيف autoscaling لسعات الترحيل.

البدء السريع: مثال نشر Docker Compose

المتطلبات المسبقة: Ubuntu 22.04 LTS (أو أي Linux مع Docker Engine 20.10+)، Docker Compose v2.x، اسم نطاق (مثال: rustdesk.example.com). خصص على الأقل 512 ميغابايت RAM لخادم اختبار صغير؛ يوصى بـ 1 جيجابايت فما فوق ليتعامل الترحيل مع جلسات نشطة متعددة.

فيما يلي مثال عملي لـ Docker Compose يشغل hbbs و hbbr كخدمات منفصلة، يركب بيانات دائمة، وينشر المنافذ القياسية لـ RustDesk. قبل التشغيل، تحقق من وسوم صور rustdesk/rustdesk-server:latest الرسمية لأحدث وسم مستقر واستبدل rustdesk/rustdesk-server:latest إذا رغبت بتثبيت وسم محدد.

version: '3.8'

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    command: ["hbbs", "--listen", "0.0.0.0:21115"]
    ports:
      - "21115:21115/tcp"
      - "21115:21115/udp"
    volumes:
      - ./data/hbbs:/data
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    command: ["hbbr", "--listen", "0.0.0.0:21116", "--relay", "0.0.0.0:21116"]
    ports:
      - "21116:21116/tcp"
      - "21116:21116/udp"
    volumes:
      - ./data/hbbr:/data
    restart: unless-stopped

networks:
  default:
    external: false

شرح:

• نشغّل hbbs على منفذ TCP/UDP رقم 21115 وhbbr على 21116 — هذه هي الافتراضيات الشائعة لبنيات خادم RustDesk. تأكد من مطابقة تعيين المنافذ للصورة التي تستخدمها (بعض البنيات المجتمعية تستخدم افتراضيات مختلفة).
• تحتفظ الحجوزات الدائمة ./data/hbbs و./data/hbbr ببيانات التسجيل والترحيل عبر إعادة التشغيل.
• استخدم restart: unless-stopped لمتانة أساسية؛ في الإنتاج اربط سياسات إعادة التشغيل بمنصة الأوركسترا لديك.

التعرية بشكل آمن: TLS، عكس الوكيل والجدار الناري

يمكن حماية إشارات RustDesk وحركة الترحيل عبر TLS وقواعد جدار ناري قياسية. هناك نهجان شائعان:

1. TLS مباشر مع وكيل أمام hbbs (مستحسن لإدارة شهادات على مستوى الويب).
2. الإبقاء على hbbr كممر TCP/UDP خام وتأمين شبكة المضيف (استخدم ufw/nftables) مع تأمين hbbs عبر TLS.

تستخدم معظم الإعدادات NGINX أو Traefik لإنهاء TLS وإعادة توجيه الحركة إلى hbbs. مثال كتلة خادم NGINX لإنهاء TLS لـ rustdesk.example.com:

server {
  listen 443 ssl;
  server_name rustdesk.example.com;

  ssl_certificate /etc/letsencrypt/live/rustdesk.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/rustdesk.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:21115;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

# Optional: redirect http to https
server {
  listen 80;
  server_name rustdesk.example.com;
  return 301 https://$host$request_uri;
}

استخدم certbot أو CA الخاص بك للحصول على الشهادات. إذا كان الترحيل (hbbr) يعمل عبر UDP/TCP علنياً، افتح تلك المنافذ مباشرة مع تقييد الوصول عبر الجدار الناري إلى نطاقات IP المتوقعة، أو ضع عقد الترحيل في شبكة فرعية خاصة خلف موازن تحميل.

DNS، العملاء واجتياز NAT

إذا تحكمت بأجهزة العميل داخل LAN، يمكنك تشغيل DNS داخلي أو توزيع ملف تهيئة يوجّه العملاء إلى عنوان IP الداخلي لـ hbbs لاتصالات محلية أسرع.

التوسيع وإرشادات الموارد

كم يحتاج الترحيل من CPU/RAM؟ يعتمد ذلك على الجلسات المتزامنة ونوع الجلسة:

• خادم اختبار صغير: 1 vCPU، 512 MB RAM — عدد قليل من الاتصالات الخاملة.
• ترحيل إنتاجي (استخدام خفيف): 2 vCPU، 1–2 GB RAM — عشرات الجلسات المتزامنة.
• ترحيل عالي النطاق: 4+ vCPU، 4+ GB RAM وسعة شبكة مطابقة لعرض النطاق المتوقع (مثلاً 100+ Mbps).

نوصي بالتحجيم التلقائي لمثيلات hbbr خلف موازن تحميل إذا توقعت تقلبات (التحكم عن بُعد بكثافة الوسائط، مشاركة شاشة). استخدم أوركسترا حاويات (Kubernetes، Docker Swarm) أو توسعة أفقية بسيطة مع موازن تحميل TCP/UDP (haproxy، موازن سحابي) يحافظ على عناوين IP للعملاء.

النسخ الاحتياطي، التحديثات وتثبيت النسخ

ركّب دائماً مجلدات دائمة للبيانات وقم بعمل نسخ احتياطية منتظمة. مثال نصي بسيط للنسخ الاحتياطي:

# daily-backup.sh
TIMESTAMP=$(date +%F)
mkdir -p /backups/rustdesk/$TIMESTAMP
rsync -a ./data /backups/rustdesk/$TIMESTAMP/
# rotate: keep 14 days
find /backups/rustdesk -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;

للتحديثات، ثبّت صورة Docker بوسم بدلاً من :latest. اختبر في بيئة staging عند ترقية صورة الخادم. مثال سير عمل:

1. اسحب الصورة الجديدة: docker pull rustdesk/rustdesk-server:1.3.0 (كمثال).
2. شغّل حاوية اختبار بنفس الحجوزات ونفّذ اختبارات تدخّل.
3. جدول نافذة صيانة واستبدل الحاويات على مضيف الإنتاج.

استكشاف الأخطاء والمشكلات الشائعة

ابدأ بالسجلات: docker logs rustdesk-hbbs وdocker logs rustdesk-hbbr. القضايا النموذجية:

• عدم قدرة العملاء على التسجيل: تحقق من إمكانية الوصول إلى hbbs عبر النطاق وأن TLS صالح.
• الجلسات تنتقل إلى الترحيل ولكن الأداء ضعيف: افحص CPU/الذاكرة وشبكة مضيف الترحيل. حزم الترحيل عادةً تكون عبر UDP؛ تأكد من سماح UDP عبر الجدار الناري ومجموعة أمان السحابة.
• عرض اختلاف إصدارات بين العملاء والخادم: استخدم إصدارات متطابقة أو متوافقة لعميل/خادم RustDesk. إذا ثبّتت صورة الخادم، تأكد أن العملاء لا يستخدمون ميزات بروتوكول مهجورة.

إذا فشل اجتياز NAT باستمرار لعدد كبير من العملاء، فالمشكلة عادة NAT متماثل أو جدران حماية مؤسسية. في هذه الحالات، اعتمد على relays hbbr وراقب الكمون/عرض النطاق لضمان تجربة مستخدم مقبولة.

الاعتبارات الأمنية

الاستضافة الذاتية تنقل المسؤولية إليك. خطوات أساسية:

• نهي TLS عند عكس الوكيل واستخدم شفرات قوية. احصل على شهادات من Let's Encrypt أو CA موثوق.
• قوِّ مضيف النظام: شغّل المنافذ الضرورية فقط، فعِّل التحديثات الأمنية التلقائية على نظام التشغيل، واستخدم جدار ناري (ufw/nftables).
• قَيِّد الوصول إلى واجهات الإدارة وراقب السجلات لمحاولات القوة الغاشمة. فكّر في تجزئة الشبكة؛ ضع عقد الترحيل في شبكة فرعية منفصلة إن أمكن.

إذا رغبت في نقاش أوسع حول تشديد الوصول عن بُعد، اطلع على مقالاتنا عن أمان سطح المكتب البعيد والتنازلات العملية في الاستضافة الذاتية للوصول عن بعد.

متى يكون البائع المدار أفضل

الاستضافة الذاتية عبر docker تمنحك السيطرة والخصوصية، لكن إذا احتجت إلى SLA مُدار بالكامل، ميزات مؤسسة رسمية (إدارة المستخدمين، فوترة مركزية)، أو تكامل Windows AD جاهز، قد تكون حلول تجارية مثل TeamViewer أو AnyDesk خيارات أفضل. كن صريحاً بشأن الموازنات: الاستضافة الذاتية توفر في الرسوم المتكررة وتعطي موضعية للبيانات، لكنها تتطلب وقت عمليات للصيانة، المراقبة والتأمين.

الخطوات التالية والمراجع

قائمة تحقق للانتقال من المختبر إلى الإنتاج:

1. اختر مضيفاً مع Docker Engine 20.10+ وDocker Compose v2.x.
2. أنشئ مجلدات دائمة وجدول نسخ احتياطي يومي.
3. ثبّت وسم صورة الخادم وحقق التحديثات في بيئة staging.
4. انهِ TLS عبر NGINX/Traefik واحصل على شهادات من Let's Encrypt.
5. راقب مضيفي الترحيل وقم بتوسيع hbbr عندما تصل CPU أو عرض النطاق إلى عتبات الصحة.

هل تريد تنزيل نظيف للمقارنة جنباً إلى جنب مع نهج الحاويات؟ احصل على ثنائيات أو مثبتات Tenvo من /download/pricing لخيارات النشر. إذا فضلت اتباع إعداد وصول عن بُعد أوسع، يغطي دليلنا إعداد الوصول عن بُعد مواضيع الشبكة، المصادقة وسهولة الاستخدام عبر الأدوات.

تشغيل RustDesk تحت Docker هو نهج ثابت وقابل للصيانة لمعظم المستضيفين الذاتيين: يبسط التحديثات ويتكامل جيداً مع بنية الحاويات الحالية. إذا احتجت إلى ملف compose أو مساعدة لتكييف هذا إلى Kubernetes، عد وسأوفر مثال manifest لـ K8s ومخطط Helm.

هل أنت مستعد لتجربته؟ حمّل العملاء اللازمين أو صور الاختبار من /download