آموزش راه اندازی سرور رله RustDesk روی VPS

سرور رله RustDesk که به صورت self-hosted میزبانی می‌شود چیست

یک سرور رله RustDesk که به صورت self-hosted میزبانی می‌شود، شامل دو دیمون (daemon) روی یک VPS است. hbbs سرور ID و rendezvous است: این بخش شناسه هر کلاینت را ثبت کرده و دو کلاینت را به یکدیگر معرفی می‌کند. hbbr سرور رله است: این بخش بایت‌های نشست (session) را منتقل می‌کند، اما فقط برای نشست‌هایی که امکان برقراری ارتباط مستقیم بین آن‌ها وجود نداشته است. اکثر راهنماها هر دو را نصب می‌کنند، شما را به هم متصل می‌کنند و در همان‌جا متوقف می‌شوند. آنچه در ادامه می‌آید، باقی کار است: کلیدی که کنترل دسترسی شماست، پورت‌ها، ارتقاء و پهنای باند.

هر دو دیمون در یک ایمیج واحد به نام rustdesk/rustdesk-server عرضه می‌شوند و هر دو یک جفت‌کلید Ed25519 را از یک دایرکتوری یکسان می‌خوانند. Ed25519 یک طرح امضای کلید عمومی است. آن جفت‌کلید تعیین می‌کند که سرور شما با کدام کلاینت‌ها ارتباط برقرار کند و هیچ پایگاه داده کاربری در پشت آن وجود ندارد.

hbbs و hbbr: کدام دیمون پهنای باند مصرف می‌کند

ترافیک hbbs کم و ثابت است: ثبت ID و سیگنال‌های heartbeat، به‌علاوه تبادل کوتاهی که دو کلاینت را به هم معرفی می‌کند. این دیمون در تمام طول روز فعال است و هزینه پهنای باند آن تقریباً صفر است.

ترافیک hbbr مربوط به خود نشست (session) است. فریم‌های تصویر در یک جهت و داده‌های کیبورد و ماوس در جهت دیگر منتقل می‌شوند؛ هر بایتی که relay می‌شود، ابتدا به VPS شما می‌رسد و سپس از آن خارج می‌شود. اگر ارائه‌دهندهٔ خدمات شما فقط ترافیک خروجی (egress) را محاسبه می‌کند، یک نشست relay شده هزینه‌ای معادل نرخ انتقال همان نشست برای شما دارد. اگر کل ترافیک (ورودی و خروجی) محاسبه شود، هزینه تقریباً دو برابر خواهد بود.

قابلیت relay یک مسیر جایگزین (fallback) است، نه مسیر اصلی. hbbs ابتدا تلاش می‌کند دو کلاینت را مستقیماً به هم متصل کند؛ این کار با استفاده از hole punching از طریق هر نوع NAT (ترجمه آدرس شبکه) که در مقابل هر یک از آن‌ها قرار دارد، انجام می‌شود. وقتی این روش موفق باشد، نشست هرگز با hbbr تماس پیدا نمی‌کند و سهمیه انتقال داده شما دست‌نخورده باقی می‌ماند. زمانی که یک سمت پشت NAT باشد که برای هر مقصد پورت جدیدی اختصاص می‌دهد، یا فایروالی داشته باشد که مسیر ایجاد شده را مسدود کند، نشست به hbbr منتقل می‌شود و تمام فریم‌ها از VPS شما عبور می‌کنند.

یک متغیر محیطی این انتخاب را حذف می‌کند. ALWAYS_USE_RELAY=Y در hbbs، تمام نشست‌ها را مجبور می‌کند از طریق hbbr عبور کنند. مستندات RustDesk این متغیر را در یکی از نمونه‌های Compose خود نشان داده است، به همین دلیل زیاد کپی می‌شود. این کار باعث می‌شود اتصالات قابل‌پیش‌بینی‌تر شوند و ترافیک خروجی شما واقعی شود. این متغیر را تنها زمانی تنظیم کنید که خودتان تصمیم به این کار گرفته باشید، نه به این دلیل که آن را کپی کرده‌اید.

کدام پورت‌ها برای سرور RustDesk خودمیزبان (self-hosted) مورد نیاز هستند

شماره پورت‌های زیر بر اساس مستندات سرور RustDesk و مخزن rustdesk-server در تاریخ 17 اوت 2026 بررسی شده‌اند.

• پورت TCP 21115 روی hbbs: برای تست نوع NAT.
• پورت UDP 21116 روی hbbs: برای ثبت شناسه (ID) و heartbeat. بدون این پورت، کلاینت هرگز آنلاین نمی‌شود، صرف‌نظر از اینکه چه پورت‌های دیگری باز باشند.
• پورت TCP 21116 روی hbbs: برای TCP hole punching و سرویس اتصال.
• پورت TCP 21117 روی hbbr: برای relay. این پورتی است که داده‌های نشست (session) را منتقل می‌کند و بنابراین پورتی است که مصرف پهنای باند شما را تعیین می‌کند.
• پورت TCP 21118 روی hbbs و پورت TCP 21119 روی hbbr: برای WebSocket که توسط کلاینت مرورگر استفاده می‌شود. اگر از آن استفاده نمی‌کنید، هر دو را بسته نگه دارید.
• پورت TCP 21114 مربوط به کنسول وب در RustDesk Server Pro است. نسخه متن‌باز (open source) روی این پورت گوش نمی‌دهد.

نصب 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 را بخوانند. پیش از تغییر در فایروال، از وجود listenerها اطمینان حاصل کنید.

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

شما باید listenerهای TCP را روی پورت‌های 21115، 21116 و 21117، و یک listener از نوع UDP را روی پورت 21116 مشاهده کنید. نبود خط مربوط به UDP به این معناست که hbbs در حال اجرا نیست، زیرا کلاینت‌ها از طریق همین listener ثبت‌نام می‌کنند.

چهار مورد در این فایل تعمداً لحاظ شده‌اند. تگ مورد استفاده 1.1.16 است؛ یعنی نسخه فعلی تا اوت 2026 که در تاریخ 20 ژوئیه 2026 منتشر شده است. استفاده از این تگ به جای latest به این دلیل است که latest به معنای آخرین نسخه ارسال‌شده است و ممکن است docker compose pull در شش ماه آینده، نسخه‌ای را در اختیار شما قرار دهد که هرگز آن را تست نکرده‌اید. network_mode: "host" اینترفیس‌های میزبان را مستقیماً bind می‌کند که همان توصیه‌ مستندات RustDesk است و نحوه عملکرد فایروال شما را تعیین می‌کند. ./data:/root دایرکتوری کاری ایمیج را روی میزبان نگاشت می‌کند تا جفت‌کلیدها در محلی ذخیره شوند که امکان پشتیبان‌گیری از آن‌ها وجود داشته باشد. و hbbr -k _ تنها تغییری است که نسبت به نمونه اصلی (upstream) اعمال شده، زیرا تنظیمات پیش‌فرض، رله شما را برای همه باز می‌گذارد. اگر با Compose آشنا نیستید، اجرای Docker Compose روی VPS فرمت فایل و دستورات چرخه حیات آن را پوشش می‌دهد.

اگر hbbr به سرور دیگری منتقل شود، باید به hbbs اطلاع دهید که به کجا رفته است: از -r relay.example.com:21117 استفاده کنید یا متغیر محیطی RELAY-SERVERS را تنظیم نمایید. در یک سرور واحد، نیازی به این کار نیست.

جفت‌کلید Ed25519 کنترل دسترسی است

در اولین اجرا، hbbs فایل‌های id_ed25519 و id_ed25519.pub را در دایرکتوری کاری خود تولید می‌کند. با استفاده از mount بالا، هر دو فایل روی میزبان (host) ظاهر می‌شوند.

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 متکی بودید.

این کلید، رمز عبور نشست (session password) نیست و اشتباه گرفتن این دو باعث می‌شود افراد یکی از آن‌ها را نادیده بگیرند. کلید تعیین می‌کند که سرور شما با کدام کلاینت‌ها ارتباط برقرار کند. رمز عبور دائمی یا کد یک‌بارمصرف روی دستگاه مقصد، تعیین می‌کند چه کسی اجازه دارد یک نشست را روی آن دستگاه باز کند. شما به هر دو نیاز دارید و داشتن یکی، ضعف دیگری را جبران نمی‌کند.

چرا رله بدون احراز هویت یک مشکل است

به‌صورت پیش‌فرض، hbbr هیچ‌چیزی را بررسی نمی‌کند. مستندات پیکربندی RustDesk مستقیماً به این موضوع اشاره دارد: یک کلید خالی به کلاینت‌ها اجازه می‌دهد بدون داشتن کلید منطبق، از رله استفاده کنند. این مقدار پیش‌فرض خالی وجود دارد تا کاربران جدید در اولین اجرا با خطای عدم تطابق کلید مواجه نشوند. هزینه این کار این است که هر کسی که آدرس شما را روی پورت TCP 21117 پیدا کند، می‌تواند ترافیک نشست خود را از طریق VPS شما، با استفاده از سهمیه انتقال داده شما و از آدرس IP شما عبور دهد.

command: hbbr -k _ این مشکل را برطرف می‌کند. آرگومان _ به hbbr می‌گوید که یک جفت‌کلید را از دایرکتوری کاری خود بارگذاری کند، و از آنجا که هر دو کانتینر، ./data یکسانی را mount می‌کنند، این همان جفتی است که hbbs قبلاً تولید کرده است. هیچ‌چیزی به‌صورت دستی کپی نمی‌شود، بنابراین هیچ‌گونه ناهماهنگی رخ نمی‌دهد.

volume مشترک بخشی است که افراد در آن دچار اشتباه می‌شوند. اگر به hbbr دایرکتوری اختصاصی خودش را بدهید، یک جفت‌کلید متفاوت تولید می‌کند. در این صورت hbbs و hbbr با هم اختلاف پیدا می‌کنند، تمام نشست‌های رله‌شده با شکست مواجه می‌شوند و نشست‌های مستقیم همچنان کار می‌کنند. نشانه این مشکل گیج‌کننده است: RustDesk به برخی از همتایان (peers) متصل می‌شود و به برخی دیگر نه، که این بستگی به موفقیت‌آمیز بودن یا نبودن hole punching دارد. یک ls -l ~/rustdesk/data/ که یک جفت id_ed25519 واحد را نشان دهد، این احتمال را رد می‌کند.

تنظیم کلاینت‌ها برای اتصال به سرور شما

در هر دستگاه، RustDesk را باز کرده و به مسیر Settings و سپس Network و در نهایت ID/Relay Server بروید.

• ID Server: نام میزبان (hostname) خود را وارد کنید، برای مثال rustdesk.example.com. کلاینت از پورت 21116 استفاده می‌کند، مگر آنکه پورت دیگری را مشخص کنید.
• Relay Server: اگر hbbr روی همان میزبانی اجرا می‌شود که hbbs قرار دارد، این فیلد را خالی بگذارید.
• API Server: این فیلد را خالی بگذارید. نسخه متن‌باز (open source) این سرور، API ارائه نمی‌دهد.
• Key: رشته base64 حاصل از id_ed25519.pub را دقیقاً و بدون هیچ فضای خالی (space) در انتها، در این قسمت کپی کنید.

پس از این مراحل، پنجره اصلی باید وضعیت آماده‌به‌کار بودن کلاینت را گزارش دهد. اگر چنین نشد، به این معناست که ترافیک UDP روی پورت 21116 به hbbs نمی‌رسد؛ زیرا عملیات ثبت (registration) و heartbeat از طریق پروتکل UDP انجام می‌شود و بدون آن، ID سرور آنلاین نخواهد شد.

محدودسازی پورت‌ها برای جلوگیری از تبدیل شدن relay به یک سرویس باز

از آنجا که کانتینرها از شبکه میزبان (host networking) استفاده می‌کنند، هیچ قانون 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 را اضافه کنید. هنگام فعال‌سازی ufw، یک نشست SSH دوم باز نگه دارید تا در صورت بروز اشتباه در قانون SSH، دسترسی شما به سرور قطع نشود. اصول اولیه فایروال ufw برای VPS سیاست‌های پیش‌فرض و ترتیب قوانین را پوشش می‌دهد.

و اما نکته حساس: اگر به استفاده از انتشار پورت‌ها با بلوک ports: روی بیاورید—که در مثال جایگزین تصویر supervisor برای RustDesk استفاده شده است—داکر قوانین DNAT مخصوص خود را می‌نویسد و بسته‌ها بدون عبور از زنجیره‌ای که قوانین ufw شما در آن قرار دارند، به کانتینر می‌رسند. در این حالت، یک دستور ufw deny روی پورت 21117 بی‌اثر خواهد بود و relay در حالی که ufw status خلاف آن را نشان می‌دهد، برای اینترنت باز می‌ماند. دور زدن ufw توسط پورت‌های منتشر شده داکر ترتیب زنجیره‌ها را توضیح می‌دهد. استفاده از شبکه میزبان این مشکل را به‌طور کامل برطرف می‌کند. اگر پورت خاصی را منتشر می‌کنید، آن را مانند "127.0.0.1:21118:21118" پشت یک reverse proxy، فقط به یک آدرس مشخص bind کنید.

محدودسازی بر اساس آدرس مبدأ تنها زمانی کارآمد است که کلاینت‌های شما آدرس‌های ثابت داشته باشند.

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. یادداشت‌های انتشار (release notes) مربوط به تگ جدید را در صفحه انتشار 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 مهم‌ترین بخش بررسی است، زیرا تغییر کلید در سمت سرور بدون هیچ هشداری رخ می‌دهد و باعث از کار افتادن هم‌زمان تمام کلاینت‌ها می‌شود. برای بازگشت به نسخه قبلی (rollback)، تگ قدیمی را جایگزین کرده و دوباره up -d را اجرا کنید. این کار تنها در صورتی ممکن است که نسخه را ثابت (pin) کرده باشید: با استفاده از latest، دستور docker compose pull نام تگ را به ایمیج جدید منتقل می‌کند و دیگر تگی باقی نمی‌ماند که به ایمیج قدیمی اشاره کند.

روش معمول برای از دست دادن کلید، استفاده از docker compose down نیست، چرا که این دستور bind mount را دست‌نخورده باقی می‌گذارد. این اتفاق معمولاً هنگام مهاجرت به یک VPS جدید و کپی کردن تنها compose.yml رخ می‌دهد. حتماً ./data را نیز همراه با آن کپی کنید.

نظارت بر ترافیک خروجی (egress) در پلن‌های دارای محدودیت انتقال داده

برنامه hbbr تنها بخش از این پشته است که می‌تواند از سهمیه انتقال داده استفاده کند. طبق FAQ مربوط به RustDesk، یک اتصال رله‌شده با رزولوشن 1920x1080 بین 30 KB/s تا 3 MB/s مصرف دارد و کارهای اداری معمولی حدود 100 KB/s ترافیک ایجاد می‌کنند. این ارقام برای یک نشست (session) واحد منتشر شده‌اند و لزوماً اندازه‌گیری دقیق محیط شما نیستند. اگر این مقادیر را برای 60 ساعت در ماه (دو ساعت در روز) محاسبه کنیم، نتایج به شرح زیر است:

[
  {
    "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 گیگابایت در ماه مصرف می‌کند که در هیچ پلنی قابل‌توجه نیست. در بالاترین حد بازه اعلام‌شده، همان 60 ساعت حدود 648 گیگابایت مصرف دارد و دو نشست همزمان با این نرخ، سهمیه 1 ترابایتی را در طول ماه تمام می‌کنند. پایین‌ترین حد مصرف نیز 6.5 گیگابایت است. در اینجا هر گیگابایت معادل 1000 مگابایت در نظر گرفته شده است که روش استاندارد محاسبه سهمیه‌های انتقال داده است.

ابزار docker stats این آمار را برای شما تفکیک نمی‌کند، زیرا کانتینری که از شبکه میزبان (host networking) استفاده می‌کند، فضای نام شبکه میزبان را به اشتراک می‌گذارد و شمارنده‌های آن با شمارنده‌های کل میزبان یکی است. دو ابزار دیگر برای این کار مناسب هستند. vnstat کل سرور را اندازه‌گیری می‌کند:

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

اندازه‌گیری کل سرور یعنی کل سرور: اگر این VPS سرویس دیگری هم اجرا می‌کند که داده‌های حجیمی جابه‌جا می‌کند، مثلاً یکی از سرورهای عکس self-hosted که هر شب کتابخانه‌های گوشی را آپلود می‌کند، ترافیک آپلود آن در همان گزارش ماهانه ترافیک رله شما لحاظ می‌شود. در مورد سرورهای رسانه‌ای نیز وضعیت مشابه است؛ مثلاً 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 نداشته باشد. این شمارنده دائمی نیست: اگر می‌خواهید پس از reboot باقی بماند، همان خطوط را در /etc/nftables.conf قرار دهید. این شمارنده فقط زمانی افزایش می‌یابد که یک نشست در حال رله شدن باشد. اگر شمارنده در زمانی که هیچ‌کدام از دستگاه‌های شما متصل نیستند همچنان بالا می‌رود، یعنی شخص دیگری رله شما را پیدا کرده است؛ این همان وضعیتی است که hbbr -k _ برای جلوگیری از آن وجود دارد. از آنجا که شما هر روز nft list را چک نخواهید کرد، یک cron job تنظیم کنید که تعداد بایت‌ها را با یک آستانه مقایسه کند و در صورت عبور از آن، یک هشدار push ارسال کند؛ این کار وظیفه سرور ntfy شخصی شما است.

برنامه hbbr محدودیت‌های نرخ (rate limits) نیز دارد که می‌توانید آن‌ها را کاهش دهید. مقدار پیش‌فرض SINGLE_BANDWIDTH برابر با 128 Mb/s برای هر اتصال رله و TOTAL_BANDWIDTH برابر با 1024 Mb/s برای مجموع آن‌هاست. تنظیم SINGLE_BANDWIDTH=8 باعث می‌شود هر نشست در حدود 1 MB/s محدود شود. این تنظیم سرعت را محدود می‌کند، نه مجموع مصرف ماهانه را؛ بنابراین از آن به عنوان ابزاری برای جلوگیری از اشباع لینک توسط یک نشست استفاده کنید، نه به عنوان ابزاری برای کنترل بودجه مصرفی.

زمانی که اصلاً به relay نیاز ندارید

برای یک راه‌اندازی شخصی، پاسخ صادقانه این است که ممکن است به هیچ‌کدام از این‌ها نیاز نداشته باشید. هر دو دستگاه را در یک mesh VPN قرار دهید و مستقیماً به آدرس تونل متصل شوید. در این حالت نه hbbs وجود دارد، نه hbbr، نه خروجی relay و نه کانتینری روی VPS که نیاز به به‌روزرسانی داشته باشد.

روی دستگاهی که می‌خواهید کنترل کنید، دسترسی مستقیم IP را در تنظیمات امنیتی RustDesk فعال کنید. فیلد پورت به‌صورت پیش‌فرض روی 21118 تنظیم شده است. پیش از تلاش برای اتصال، بررسی کنید که آیا پورت در حال گوش دادن است یا خیر:

ss -tlnp | grep 21118

سپس به‌جای استفاده از ID، به آدرس VPN آن همتا (peer) متصل شوید. در FAQ مربوط به RustDesk ذکر شده که در این حالت، اتصال رمزنگاری‌نشده است؛ بنابراین آن را فقط داخل تونل اجرا کنید و هرگز از طریق اینترنت آزاد از آن استفاده نکنید. تونل همان چیزی است که رمزنگاری را تأمین می‌کند.

انتخاب روش به مالکیت دستگاه‌ها بستگی دارد. استفاده از hbbs و hbbr شخصی‌سازی‌شده (self-hosted) زمانی مناسب است که از دستگاه‌هایی پشتیبانی می‌کنید که متعلق به شما نیستند، یا افرادی که هرگز کلاینت VPN نصب نمی‌کنند؛ زیرا در سمت آن‌ها، راه‌اندازی فقط شامل یک ID و یک رمز عبور است. استفاده از mesh VPN با دسترسی مستقیم IP زمانی مناسب است که تمام دستگاه‌ها متعلق به خودتان باشند و بتوانند کلید امنیتی را حمل کنند. مقایسه WireGuard با Tailscale دو روش معمول برای ساخت این شبکه mesh را پوشش می‌دهد و اجرای دسکتاپ از راه دور روی یک VPS لینوکسی حالت دیگر را بررسی می‌کند، یعنی زمانی که دستگاهی که می‌خواهید تصویر آن را داشته باشید، خودِ سرور است.

FAQ

آیا تمام نشست‌های RustDesk از طریق relay من عبور می‌کنند؟

خیر. hbbs ابتدا تلاش می‌کند با استفاده از hole punching از طریق NAT موجود در مقابل هر دو کلاینت، آن‌ها را مستقیماً به هم متصل کند. تنها نشست‌هایی که در این کار شکست می‌خورند به hbbr بازمی‌گردند و فقط همان‌ها پهنای باند شما را مصرف می‌کنند. استثنا در این مورد ALWAYS_USE_RELAY=Y در hbbs است که فارغ از در دسترس بودن مسیر مستقیم، تمام نشست‌ها را مجبور به عبور از hbbr می‌کند. اگر این متغیر در فایل Compose شما تنظیم شده باشد، تمام بایت‌های هر نشست در صورت‌حساب انتقال داده شما محاسبه خواهد شد.

کلید سرور RustDesk کجا ذخیره می‌شود و اگر آن را گم کنم چه می‌شود؟

hbbs در اولین اجرا id_ed25519 و id_ed25519.pub را در دایرکتوری کاری خود تولید می‌کند. این دایرکتوری در ایمیج رسمی /root است، بنابراین با mount کردن volume که در بالا نشان داده شد، فایل‌ها در ./data روی میزبان ظاهر می‌شوند. از هر دو فایل در خارج از سرور نسخه پشتیبان تهیه کنید. اگر این فایل‌ها گم شوند، hbbs در اجرای بعدی یک جفت جدید تولید می‌کند و تمام کلاینت‌هایی که هنوز کلید عمومی قدیمی را دارند، رد می‌شوند. هیچ راه بازیابی جز ویرایش دستی فیلد Key در تک‌تک کلاینت‌ها وجود ندارد.

برای یک سرور RustDesk که خودمان میزبانی می‌کنیم، کدام پورت‌ها را باید باز کنیم؟

پورت‌های TCP 21115، 21116 و 21117، به علاوه UDP 21116. hbbs از 21115 برای تست نوع NAT، و از 21116 برای ثبت ID و heartbeat روی UDP و برای hole punching روی TCP استفاده می‌کند. hbbr از 21117 برای relay استفاده می‌کند. پورت‌های TCP 21118 و 21119 پورت‌های WebSocket برای کلاینت مرورگر هستند، بنابراین اگر از آن استفاده نمی‌کنید، آن‌ها را بسته نگه دارید. پورت TCP 21114 مربوط به کنسول وب نسخه Pro است و نسخه متن‌باز نیازی به آن ندارد.

آیا افراد غریبه می‌توانند از relay سرور RustDesk من استفاده کنند؟

بله، اگر hbbr را با پیکربندی پیش‌فرض اجرا کنید. مستندات RustDesk بیان می‌کند که کلید خالی به کلاینت‌های بدون کلید منطبق اجازه می‌دهد از relay استفاده کنند، بنابراین هر کسی که نام میزبان و پورت 21117 شما را بداند می‌تواند ترافیک خود را از طریق سرور شما عبور دهد. hbbr را با -k _ اجرا کنید تا همان جفت کلیدی را بارگذاری کند که hbbs در volume مشترک ./data تولید کرده است. پس از آن، فقط کلاینت‌هایی که با کلید عمومی شما پیکربندی شده‌اند می‌توانند از طریق شما relay کنند.