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

ما هو خادم الترحيل RustDesk المستضاف ذاتياً

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

تتوفر الخدمتان في الصورة نفسها، rustdesk/rustdesk-server، وفي الإعداد أدناه تقرأ كلتاهما زوج مفاتيح Ed25519 نفسه من الدليل نفسه. هذا إعداد يجب أن تحدده، وليس سلوكاً افتراضياً: يحمّل hbbs الزوج تلقائياً أو ينشئه، بينما يتجاهل hbbr المفاتيح ما لم تبدأه باستخدام مفتاح. 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 في 10 October 2026.

• TCP 21115، على hbbs: اختبار نوع NAT.
• UDP 21116، على hbbs: تسجيل المعرّف وإرسال نبضات الحياة. هذا هو المسار الذي يستخدمه العميل افتراضياً.
• TCP 21116، على hbbs: تسجيل المعرّف للعملاء المضبوطين على TCP فقط، إضافة إلى اختراق NAT عبر TCP وخدمة الاتصالات.
• TCP 21117، على hbbr: خدمة الترحيل. ينقل هذا المنفذ بيانات الجلسة، ولذلك فهو المنفذ الذي يستهلك مواردك المدفوعة.
• TCP 21118 على hbbs وTCP 21119 على hbbr: WebSocket، ويستخدمه عميل المتصفح. اترك المنفذين مغلقين إذا لم تستخدمه.
• TCP 21114 هو خادم HTTP API في 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. تأكد من وجود منافذ الاستماع قبل تعديل إعدادات الجدار الناري.

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

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

هناك أربعة عناصر في هذا الملف مقصودة. الوسم هو 1.1.16، وهو الإصدار الحالي أيضاً حتى أكتوبر 2026، وقد نُشر في 20 July 2026، بدلاً من latest، لأن latest يعني أي إصدار نُشر حديثاً، وقد يمنحك docker compose pull بعد ستة أشهر خادماً لم تختبره. يربط network_mode: "host" واجهات المضيف مباشرة، وهذا ما توصي به وثائق RustDesk، كما أنه يحدد سلوك الجدار الناري لديك. يربط ./data:/root دليل العمل في الصورة بالمضيف، لذلك يُحفظ زوج المفاتيح في مكان يمكنك إجراء نسخ احتياطي له. أما hbbr -k _ فهو التغيير الوحيد عن المثال الأصلي، لأن الإعداد الافتراضي يترك relay مفتوحاً لأي شخص. إذا كان 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 يحمّل زوج مفاتيح من دليل العمل الخاص به، أو ينشئه إذا لم يكن موجوداً. وبما أن كلا الحاويتين تربطان ./data نفسه، فهذا هو الزوج نفسه الذي يستخدمه hbbs. لا شيء يُنسخ يدوياً، لذلك لا يمكن أن يحدث اختلاف بينهما.

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

ps -eo args | grep '[h]bbr'

يجب أن يطبع ذلك hbbr -k _. أما hbbr المجرد فيعني أن relay ما زال مفتوحاً، بغض النظر عما يوجد في الدليل.

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

على كل جهاز، افتح 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، لأن العميل الافتراضي يسجّل هناك ويرسل نبضات الحالة. لكن عدم اتصال ID لا يثبت ذلك وحده. فالعميل الذي تكون قيمة الخيار disable-udp فيه مضبوطة على Y يسجّل عبر TCP 21116 بدلاً من ذلك، ولا يستخدم UDP 21116 مطلقاً. لذلك افحص TCP 21116 أولاً لهذا العميل.

قيِّد المنافذ حتى لا يكون relay خدمة مفتوحة

بما أن الحاويات تستخدم شبكة المضيف، فلا توجد قاعدة Docker NAT أمامها، ولذلك تُطبَّق قواعد 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 للمنفذ 21117 أي تأثير، ويصبح relay متاحاً على الإنترنت بينما يدّعي 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

لا تملك أجهزة الكمبيوتر المحمولة على شبكات الفنادق عناوين ثابتة، ولهذا تؤدي key الموجودة على 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 عبر خادم الترحيل الخاص بي؟

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

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

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

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

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

هل يستطيع الغرباء استخدام مرحّل RustDesk المستضاف ذاتياً؟

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