كيفية إعداد خادم RustDesk Relay خاص بك على VPS

ما هو خادم الترحيل (Relay Server) المستضاف ذاتياً لـ RustDesk

خادم الترحيل المستضاف ذاتياً لـ RustDesk عبارة عن خدمتين (daemons) تعملان على خادم افتراضي خاص (VPS) واحد. hbbs هو خادم المعرّفات والالتقاء (ID and rendezvous server): يقوم بتسجيل معرّف كل عميل ويربط بين عميلين. hbbr هو خادم الترحيل: ينقل بيانات الجلسة، ولكن فقط للجلسات التي تعذر إجراؤها بشكل مباشر. تثبّت معظم الأدلة الخدمتين، وتصل بك إلى مرحلة الاقتران، ثم تتوقف. ما يلي هو بقية العمل: المفتاح الذي يمثل تحكمك في الوصول، والمنافذ، والترقية، وعرض النطاق الترددي.

تأتي الخدمتان في نفس الصورة البرمجية، rustdesk/rustdesk-server، وتقرآن نفس زوج مفاتيح Ed25519 من نفس المجلد. Ed25519 هو نظام توقيع بالمفتاح العام. يحدد زوج المفاتيح هذا العملاء الذين سيتحدث معهم خادمك، ولا توجد قاعدة بيانات مستخدمين خلفه.

hbbs و hbbr: أي خدمة تستهلك نطاقك الترددي

حركة مرور hbbs صغيرة ومستمرة: تسجيل المعرّفات ونبضات الاتصال، بالإضافة إلى التبادل القصير الذي يربط بين طرفين. تعمل هذه الخدمة طوال اليوم ولا تستهلك موارد تذكر.

حركة مرور hbbr هي الجلسة نفسها. تنتقل إطارات الشاشة في اتجاه، وتنتقل إشارات لوحة المفاتيح والفأرة في الاتجاه الآخر، وكل بايت يتم ترحيله يصل إلى خادمك الافتراضي (VPS) ثم يغادره مرة أخرى. إذا كان مزود الخدمة يحاسبك على حركة المرور الصادرة فقط، فإن الجلسة المُرَحَّلة تستهلك من رصيدك بمقدار معدل نقل بيانات الجلسة. أما إذا كان يحاسبك على إجمالي النقل، فإن التكلفة تتضاعف.

الترحيل هو خيار احتياطي، وليس المسار الطبيعي. يحاول hbbs أولاً ربط العميلين مباشرة، باستخدام تقنية ثقب الجدار الناري (hole punching) عبر أي NAT (ترجمة عنوان الشبكة) موجود أمام كل منهما. عندما تنجح هذه العملية، لا تمر الجلسة عبر hbbr ويبقى رصيد نقل البيانات لديك دون مساس. عندما يكون أحد الطرفين خلف NAT يخصص منفذاً جديداً لكل وجهة، أو خلف جدار ناري يسقط مسار الاتصال المثقوب، تتحول الجلسة إلى hbbr وتمر كل إطار بيانات عبر خادمك الافتراضي.

هناك متغير بيئة واحد يلغي هذا الخيار. يؤدي تعيين ALWAYS_USE_RELAY=Y في hbbs إلى إجبار كل الجلسات على المرور عبر hbbr. تظهر وثائق RustDesk هذا المتغير في أحد أمثلة Compose، لذا يتم نسخه بكثرة. هذا يجعل الاتصالات أكثر قابلية للتنبؤ ويجعل استهلاكك للنطاق الترددي حقيقياً. قم بتعيينه لأنك قررت ذلك، وليس لأنك قمت بنسخه ولصقه.

ما هي المنافذ التي يحتاجها خادم RustDesk ذاتي الاستضافة

تم التحقق من أرقام المنافذ أدناه مقابل وثائق خادم RustDesk ومستودع rustdesk-server في 17 أغسطس 2026.

• TCP 21115، على hbbs: اختبار نوع NAT.
• UDP 21116، على hbbs: تسجيل المعرّف (ID) ونبضات الاتصال (heartbeat). بدون هذا المنفذ، لن يتصل العميل أبداً، بغض النظر عن المنافذ الأخرى المفتوحة.
• TCP 21116، على hbbs: تقنية TCP hole punching وخدمة الاتصال.
• TCP 21117، على hbbr: الترحيل (relay). هذا هو المنفذ الذي ينقل بيانات الجلسة، وهو المنفذ الذي يستهلك موارد الشبكة لديك.
• TCP 21118 على hbbs وTCP 21119 على hbbr: بروتوكول WebSocket، المستخدم من قبل عميل المتصفح. اترك كلاهما مغلقاً إذا كنت لا تستخدمه.
• TCP 21114 هو منفذ لوحة التحكم عبر الويب في إصدار RustDesk Server Pro. إصدار المصدر المفتوح لا يستمع على هذا المنفذ.

تثبيت hbbs و hbbr مع تثبيت إصدار الصورة

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbr -k _
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

mkdir -p ~/rustdesk
cd ~/rustdesk
# save the block above as ~/rustdesk/compose.yml before this line
sudo docker compose up -d
sudo docker compose ps

يجب أن تقرأ كلتا الخدمتين running. تأكد من وجود المستمعين (listeners) قبل تعديل إعدادات جدار الحماية.

sudo ss -tlnp | grep -E ':2111[5-7]'
sudo ss -ulnp | grep ':21116'

يجب أن ترى مستمعي TCP على المنافذ 21115 و 21116 و 21117، ومستمع UDP على المنفذ 21116. غياب سطر UDP يعني أنّ hbbs لا يعمل، لأنّ هذا المستمع هو الذي تُسجّل العملاء أنفسهم عليه.

هناك أربعة أمور مقصودة في ذلك الملف. الوسم هو 1.1.16، وهو الإصدار الحالي اعتباراً من أغسطس 2026، والذي نُشر في 20 يوليو 2026، بدلاً من latest، لأنّ latest يعني أي نسخة تم دفعها مؤخراً، وقد يمنحك docker compose pull بعد ستة أشهر خادماً لم تختبره قط. يربط network_mode: "host" واجهات المضيف مباشرة، وهو ما توصي به وثائق RustDesk وهو ما يحدد كيفية عمل جدار الحماية الخاص بك. يقوم ./data:/root بتعيين دليل عمل الصورة على المضيف، بحيث يتم حفظ زوج المفاتيح في مكان يمكنك نسخ احتياطي له. و hbbr -k _ هو التغيير الوحيد عن المثال الأصلي، لأنّ الإعداد الافتراضي يترك خدمة الترحيل (relay) مفتوحة لأي شخص. إذا كان Docker Compose جديداً عليك، فإن تشغيل Docker Compose على خادم VPS يغطي تنسيق الملف وأوامر دورة الحياة.

إذا انتقلت خدمة hbbr إلى خادم ثانٍ، يجب إخبار hbbs بمكانها الجديد: مرر -r relay.example.com:21117، أو اضبط متغير البيئة RELAY-SERVERS. إذا كنت تستخدم خادماً واحداً، فلن تحتاج إلى ذلك.

زوج مفاتيح Ed25519 هو وسيلة التحكم في الوصول

عند التشغيل لأول مرة، يُنشئ hbbs الملفين id_ed25519 وid_ed25519.pub في دليل العمل الخاص به. بفضل نقطة الربط (mount) المذكورة أعلاه، يظهر كلا الملفين على المضيف.

ls -l ~/rustdesk/data/
sudo cat ~/rustdesk/data/id_ed25519.pub

يحتوي id_ed25519.pub على سلسلة نصية واحدة بتنسيق base64. يجب وضع هذه السلسلة في حقل Key على كل عميل. أما id_ed25519 فهو الجزء الخاص ولا يغادر الخادم أبداً. المفتاح العام ليس سراً، لأنك ستنسخه إلى إعدادات كل عميل على أي حال. المفتاح الخاص هو سر: أي شخص يمتلكه يمكنه تشغيل خادم ستثق به عملاؤك.

انسخ كلا الملفين احتياطياً الآن، قبل أن تقوم بتهيئة عشرين عميلاً.

sudo tar czf ~/rustdesk-keys.tgz -C ~/rustdesk/data id_ed25519 id_ed25519.pub
sudo chmod 600 ~/rustdesk-keys.tgz

انقل ذلك الأرشيف خارج الخادم. إليك سبب أهمية هذه الخطوة أكثر من أي خطوة أخرى. إذا حذفت ~/rustdesk/data، أو أعدت البناء على خادم VPS جديد دون نسخه، فسيقوم hbbs بإنشاء زوج مفاتيح جديد عند التشغيل التالي. سيظل كل عميل يحمل المفتاح العام القديم، لذا سيرفضه hbbs وسيفقد العميل اتصاله. شغّل sudo cat ~/rustdesk/data/id_ed25519.pub وقارنه بحقل Key على أي عميل: لن تتطابق السلسلتان، وهذا عدم التطابق هو سبب الفشل بالكامل. إصلاح ذلك يعني تعديل الإعدادات على كل جهاز يدوياً، بما في ذلك الأجهزة التي كنت تعتمد على RustDesk للوصول إليها.

المفتاح ليس كلمة مرور الجلسة، والخلط بينهما يدفع البعض لتجاهل أحدهما. يحدد المفتاح العملاء الذين سيتحدث معهم خادمك. أما كلمة المرور الدائمة أو الرمز المؤقت على الجهاز المُتحكَّم به، فهي تحدد من يُسمح له بفتح جلسة على ذلك الجهاز. أنت بحاجة إلى كليهما، وامتلاك أحدهما لا يعوض عن ضعف الآخر.

لماذا يُعدّ الـrelay غير الموثّق مشكلة

بشكل افتراضي، لا يتحقق hbbr من أي شيء. تنص وثائق إعداد RustDesk على ذلك بوضوح: المفتاح الفارغ يسمح للعملاء الذين لا يملكون مفتاحاً مطابقاً باستخدام الـrelay. وُجد هذا الإعداد الافتراضي الفارغ لكي لا يواجه المستخدمون الجدد أخطاء عدم تطابق المفاتيح عند التشغيل الأول. الثمن هو أن أي شخص يعثر على عنوانك على المنفذ TCP 21117 يمكنه تمرير حركة بيانات جلسته عبر الـVPS الخاص بك، مستهلكاً حصة نقل البيانات الخاصة بك، وصادراً من عنوان IP الخاص بك.

يغلق command: hbbr -k _ هذه الثغرة. يخبر الوسيط _ برنامج hbbr بتحميل زوج مفاتيح من دليل عمله، ولأن كلا الحاويتين تعملان على تثبيت (mount) نفس ./data، فهذا هو الزوج الذي أنشأه hbbs بالفعل. لا يتم نسخ أي شيء يدوياً، لذا لا يمكن أن يحدث أي تباين.

المجلد المشترك هو الجزء الذي يخطئ فيه الناس. إذا أعطيت hbbr دليله الخاص، فإنه سينشئ زوج مفاتيح مختلفاً. عندها يختلف hbbs وhbbr، فتفشل كل الجلسات التي تمر عبر الـrelay، بينما تستمر الجلسات المباشرة في العمل. العرض مربك: يتصل RustDesk ببعض الأقران دون غيرهم، اعتماداً على ما إذا كانت عملية ثقب الجدار الناري (hole punching) قد نجحت أم لا. إن فحص ls -l ~/rustdesk/data/ الذي يظهر زوج id_ed25519 واحداً ينهي هذا الاحتمال.

توجيه العملاء إلى خادمك

على كل جهاز، افتح RustDesk، ثم انتقل إلى Settings، ثم Network، ثم ID/Relay Server.

• ID Server: اسم المضيف الخاص بك، على سبيل المثال rustdesk.example.com. يستخدم العميل المنفذ 21116 ما لم تحدد منفذاً آخر.
• Relay Server: اتركه فارغاً عند تشغيل hbbr على نفس المضيف الذي يعمل عليه hbbs.
• API Server: اتركه فارغاً. النسخة مفتوحة المصدر من الخادم لا توفر واجهة برمجة تطبيقات.
• Key: سلسلة base64 من id_ed25519.pub، ألصقها بدقة دون أي مسافات زائدة في النهاية.

يجب أن تظهر النافذة الرئيسية بعد ذلك حالة جاهزية العميل. إذا لم يحدث ذلك، فهذا يعني أن حركة مرور UDP على المنفذ 21116 لا تصل إلى hbbs، لأن التسجيل ونبضات الاتصال (heartbeat) تعمل عبر بروتوكول UDP، ولا يوجد أي إجراء آخر يجعل المعرّف (ID) متصلاً بالإنترنت.

تقييد المنافذ لضمان عدم تحوّل المرحّل (relay) إلى خدمة مفتوحة

بما أنّ الحاويات تستخدم نمط الشبكة المضيفة (host networking)، لا توجد قاعدة NAT خاصة بـ Docker أمامها، لذا تُطبّق قواعد ufw كما تتوقع تماماً.

sudo ufw allow 22/tcp
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udp
sudo ufw enable
sudo ufw status numbered

أضف 21118:21119/tcp فقط إذا كنت تشغّل عميل المتصفح. أبقِ جلسة SSH ثانية مفتوحة أثناء تفعيل ufw، لضمان عدم حظر وصولك إلى خادمك في حال وقوع خطأ في قاعدة SSH. يغطي أساسيات جدار الحماية ufw لخوادم VPS السياسات الافتراضية وترتيب القواعد.

إليك الفخ: إذا انتقلت إلى نشر المنافذ باستخدام كتلة ports:، وهو الأسلوب الذي يستخدمه مثال صورة المشرف البديل RustDesk، فإن Docker يكتب قواعد DNAT الخاصة به، وتصل الحزم إلى الحاوية دون المرور بالسلسلة التي تقع فيها قواعد ufw الخاصة بك. في هذه الحالة، لن يكون لقاعدة ufw deny على المنفذ 21117 أي تأثير، وسيظل المرحّل مفتوحاً أمام الإنترنت بينما يدّعي ufw status خلاف ذلك. يشرح تجاوز المنافذ المنشورة عبر Docker لجدار الحماية ufw ترتيب السلاسل. يتجنب نمط الشبكة المضيفة هذه المشكلة تماماً. إذا قمت بنشر منفذ، اربطه بعنوان واحد، كما في "127.0.0.1:21118:21118" خلف وكيل عكسي (reverse proxy).

يعمل التقييد حسب عنوان المصدر فقط عندما يكون لعملائك عناوين ثابتة.

sudo ufw allow from 203.0.113.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 21116 proto udp

أجهزة الكمبيوتر المحمولة على شبكات الفنادق لا تملك عناوين ثابتة، وهذا هو السبب الدقيق في أنّ المفتاح الموجود على hbbr يقوم بعمل فعلي هنا أكثر مما يفعله جدار الحماية.

ترقية حزمة تحتوي على مفتاحك

يُحفظ المفتاح في الـ bind mount وليس داخل الحاوية، لذا فإن الترقية آمنة طالما تركت ./data دون تغيير.

1. انسخ دليل البيانات احتياطياً أولاً: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. اقرأ ملاحظات الإصدار للوسم (tag) الجديد على صفحة إصدارات rustdesk-server.
3. عدّل compose.yml وغيّر كلا سطري image: إلى الوسم الجديد.
4. نفّذ sudo docker compose pull، ثم sudo docker compose up -d.
5. نفّذ sudo cat ~/rustdesk/data/id_ed25519.pub وتأكد من أن السلسلة النصية هي نفسها التي تمتلكها عملاؤك حالياً.

الخطوة 5 هي التحقق الأهم، لأن تغيير المفتاح لا يظهر كخطأ في الخادم ولكنه يعطل جميع العملاء في اللحظة نفسها. التراجع عن الترقية يعني إعادة الوسم القديم وتنفيذ up -d مجدداً، وهذا لا ينجح إلا إذا قمت بتثبيت الإصدار (pinning): فمع latest، قام docker compose pull بنقل الاسم إلى الصورة الجديدة، لذا لم يعد هناك وسم يشير إلى الصورة القديمة.

الطريقة المعتادة لفقدان المفتاح ليست docker compose down، التي لا تمس الـ bind mount. بل هي الانتقال إلى خادم افتراضي (VPS) جديد ونسخ compose.yml فقط. انسخ ./data معها.

مراقبة حركة المرور الصادرة (Egress) في خطة ذات سعة نقل محدودة

يُعد hbbr الجزء الوحيد من هذه الحزمة الذي يستهلك سعة النقل المتاحة. تشير الأسئلة الشائعة لـ RustDesk إلى أن الاتصال المرحلي (relayed) لشاشة بدقة 1920x1080 يستهلك ما بين 30 KB/s و 3 MB/s، بينما يستهلك العمل المكتبي العادي حوالي 100 KB/s. هذه أرقام منشورة لجلسة واحدة، وليست قياساً لإعداداتك الخاصة. عند حسابها على مدار ستين ساعة في الشهر، بمعدل ساعتين يومياً، تبدو النتائج كالتالي:

[
  {
    "label": "Low end, 30 KB/s",
    "gb_per_month": 6.5
  },
  {
    "label": "Office work, 100 KB/s",
    "gb_per_month": 21.6
  },
  {
    "label": "High end, 3 MB/s",
    "gb_per_month": 648
  }
]

بمعدل العمل المكتبي، تستهلك الجلسة الواحدة حوالي 21.6 جيجابايت شهرياً، وهو رقم لا يؤثر على أي خطة. أما عند الحد الأعلى للنطاق المنشور، فإن الستين ساعة نفسها تستهلك 648 جيجابايت، بينما تؤدي جلستان متزامنتان بهذا المعدل إلى استنفاد سعة 1 تيرابايت خلال الشهر. الحد الأدنى هو 6.5 جيجابايت. الجيجابايت هنا يساوي 1000 ميجابايت، وهي الطريقة المعتادة لحساب سعات النقل.

لن يقوم docker stats بتفصيل هذه البيانات لك، لأن الحاوية التي تستخدم شبكة المضيف (host networking) تشترك في مساحة اسم الشبكة الخاصة بالمضيف، لذا فإن عداداتها هي عدادات المضيف نفسه. هناك أداتان أخريان تفيان بالغرض. يقيس vnstat الخادم بالكامل:

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

الخادم بالكامل يعني الخادم بالكامل: إذا كان هذا الـVPS يشغّل أيضاً شيئاً ينقل بيانات فعلية، مثل أحد خوادم الصور ذاتية الاستضافة التي تسحب مكتبات الهاتف كل ليلة، فإن عمليات الرفع الخاصة بها تظهر في نفس السجل الشهري لحركة مرور الترحيل (relay) الخاصة بك. خادم الوسائط هو نفس القصة من الطرف الآخر، حيث أن شيئاً مثل Halcyon، الذي يحوّل مكتبة Jellyfin إلى متجر فيديو من التسعينات يمكن تصفحه يبث البيانات لأي شخص يشاهد، وتلك الحركة الصادرة تشترك في السعة التي يسحب منها الترحيل الخاص بك.

يقيس عداد nftables حركة الترحيل بشكل خاص:

sudo nft add table inet relaymeter
sudo nft add chain inet relaymeter out '{ type filter hook output priority 0 ; }'
sudo nft add rule inet relaymeter out tcp sport 21117 counter
sudo nft list table inet relaymeter

هذه القاعدة لا تحمل حكماً (verdict)، لذا فهي تحسب الحزم والبايتات دون تغيير ما هو مسموح به، وتوضع في جدول خاص بها حتى لا تعطل ufw. هذه القاعدة ليست دائمة: ضع نفس الأسطر في /etc/nftables.conf إذا كنت تريد استعادتها بعد إعادة التشغيل. ينمو العداد فقط أثناء ترحيل جلسة ما فعلياً. إذا استمر العداد في الارتفاع بينما لا يوجد أي من أجهزتك متصلاً، فهذا يعني أن شخصاً آخر عثر على الترحيل الخاص بك، وهي الحالة التي وُجد hbbr -k _ لمنعها. بما أنك لن تقرأ nft list كل صباح، ضع مهمة cron تقوم بمقارنة عدد البايتات مقابل حد معين وترسل تنبيهاً فورياً عند تجاوزه، وهي مهمة مناسبة لـ خادم ntfy الخاص بك.

يحتوي hbbr أيضاً على حدود للسرعة يمكنك خفضها. القيمة الافتراضية لـ SINGLE_BANDWIDTH هي 128 Mb/s لكل اتصال ترحيل، و TOTAL_BANDWIDTH هي 1024 Mb/s لجميع الاتصالات مجتمعة. ضبط SINGLE_BANDWIDTH=8 يحدد سرعة الجلسة الواحدة بـ 1 MB/s تقريباً. هذا يحد من السرعة، وليس الإجمالي الشهري، لذا تعامل معه كوسيلة لمنع جلسة واحدة من إشباع الرابط بدلاً من كونه أداة للتحكم في الميزانية.

عندما لا تحتاج إلى مرحل (Relay) على الإطلاق

بالنسبة للإعدادات الشخصية، الإجابة الصريحة هي أنك قد لا تحتاج إلى أي من هذا. ضع كلا الجهازين على شبكة VPN شبكية (Mesh VPN) واتصل مباشرة بعنوان النفق (Tunnel address). في هذه الحالة، لا توجد حاجة إلى hbbs أو hbbr أو مخرج مرحل (Relay egress)، ولا توجد حاوية على خادم VPS تحتاج إلى تحديث.

على الجهاز الذي تريد التحكم به، فعّل الوصول المباشر عبر IP في إعدادات أمان RustDesk. حقل المنفذ مضبوط افتراضياً على 21118. تأكد من أن المنفذ في حالة استماع (Listening) قبل محاولة الاتصال:

ss -tlnp | grep 21118

بعد ذلك، اتصل بعنوان VPN الخاص بذلك النظير (Peer) بدلاً من استخدام المعرّف (ID). تذكر الأسئلة الشائعة (FAQ) لـ RustDesk حول هذا النمط أن الاتصال غير مشفر، لذا قم بتشغيله داخل النفق ولا تستخدمه أبداً عبر الإنترنت المفتوح. النفق هو المسؤول عن توفير التشفير.

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

FAQ

هل تمر كل جلسة RustDesk عبر خادم الترحيل (Relay) الخاص بي؟

لا. يحاول hbbs ربط العميلين ببعضهما مباشرة في البداية، باستخدام تقنية ثقب الجدار الناري (hole punching) عبر الـ NAT الموجود أمام كل منهما. فقط الجلسات التي تفشل في ذلك تعود لاستخدام hbbr، وهي فقط التي تستهلك نطاقك الترددي. الاستثناء هو ALWAYS_USE_RELAY=Y في hbbs، والذي يجبر كل الجلسات على المرور عبر hbbr بغض النظر عن توفر مسار مباشر. إذا تم ضبط هذا المتغير في ملف Compose الخاص بك، فسيتم احتساب كل بايت من كل جلسة ضمن فاتورة نقل البيانات الخاصة بك.

أين يتم تخزين مفتاح خادم RustDesk، وماذا يحدث إذا فقدته؟

يُنشئ hbbs ملفي id_ed25519 و id_ed25519.pub في دليل العمل الخاص به عند التشغيل لأول مرة. هذا الدليل هو /root داخل الصورة الرسمية، لذا مع ربط المجلد (volume mount) الموضح أعلاه، تظهر الملفات في ./data على المضيف. احتفظ بنسخة احتياطية من كلا الملفين خارج الخادم. إذا فُقدا، يُنشئ hbbs زوجاً جديداً عند التشغيل التالي، وسيتم رفض أي عميل لا يزال يحتفظ بالمفتاح العام القديم. لا توجد وسيلة استعادة سوى تعديل حقل المفتاح (Key) يدوياً على كل عميل.

ما هي المنافذ التي أحتاج لفتحها لخادم RustDesk ذاتي الاستضافة؟

TCP 21115 و 21116 و 21117، بالإضافة إلى UDP 21116. يستخدم hbbs المنفذ 21115 لاختبار نوع الـ NAT، والمنفذ 21116 لتسجيل المعرف (ID) ونبضات الاتصال عبر UDP ولثقب الجدار الناري عبر TCP. يستخدم hbbr المنفذ 21117 للترحيل. المنفذان TCP 21118 و 21119 هما منفذا WebSocket لعميل المتصفح، لذا اتركهما مغلقين إذا كنت لا تستخدمه. المنفذ TCP 21114 يخص وحدة تحكم الويب في نسخة Pro، ولا تحتاج إليه النسخة مفتوحة المصدر.

هل يمكن للغرباء استخدام خادم ترحيل RustDesk الخاص بي؟

نعم، إذا قمت بتشغيل hbbr بإعداداته الافتراضية. تنص وثائق RustDesk على أن المفتاح الفارغ يسمح للعملاء الذين لا يملكون مفتاحاً مطابقاً باستخدام خادم الترحيل، لذا يمكن لأي شخص يعرف اسم مضيفك والمنفذ 21117 تمرير حركة البيانات عبر خادمك. قم بتشغيل hbbr باستخدام -k _ ليقوم بتحميل نفس زوج المفاتيح الذي أنشأه hbbs في المجلد المشترك ./data. بعد ذلك، لن يتمكن من الترحيل عبر خادمك سوى العملاء الذين تم إعدادهم باستخدام مفتاحك العام.