RustDesk relay server कैसे सेटअप करें

Self-hosted RustDesk relay server क्या है

Self-hosted RustDesk relay server एक VPS पर चलने वाले दो daemons हैं। hbbs ID और rendezvous सर्वर है: यह प्रत्येक client ID को रजिस्टर करता है और दो clients को एक-दूसरे से जोड़ता है। hbbr relay सर्वर है: यह session bytes को ले जाता है, लेकिन केवल उन sessions के लिए जिन्हें सीधे आपस में बात करने के लिए नहीं जोड़ा जा सका। अधिकांश guides दोनों को install करवाती हैं, आपको pair करवाती हैं और वहीं रुक जाती हैं। आगे का काम यह है: वह key जो आपका access control है, ports, upgrade और bandwidth।

दोनों daemons एक ही image, rustdesk/rustdesk-server में आते हैं, और दोनों एक ही directory से एक ही Ed25519 key pair को पढ़ते हैं। Ed25519 एक public key signature scheme है। वह key pair तय करता है कि आपका सर्वर किन clients से बात करेगा, और इसके पीछे कोई user database नहीं होता है।

hbbs और hbbr: कौन सा daemon बैंडविड्थ की खपत करता है

hbbs का ट्रैफिक कम और निरंतर होता है: ID रजिस्ट्रेशन और हार्टबीट्स, साथ ही वह संक्षिप्त आदान-प्रदान जो दो पीयर्स को आपस में जोड़ता है। यह पूरे दिन चलता है और लगभग कुछ भी खर्च नहीं करता।

hbbr का ट्रैफिक स्वयं सेशन का होता है। स्क्रीन फ्रेम्स एक दिशा में जाते हैं, कीबोर्ड और माउस के इनपुट दूसरी दिशा में, और प्रत्येक रिले किया गया बाइट आपके VPS पर आता है और फिर वहां से बाहर निकल जाता है। यदि आपका प्रोवाइडर केवल egress (बाहर जाने वाले ट्रैफिक) को मापता है, तो एक रिले किए गए सेशन की लागत लगभग सेशन रेट के बराबर होती है। यदि वह कुल ट्रांसफर को मापता है, तो लागत लगभग दोगुनी हो जाती है।

रिले एक बैकअप विकल्प है, सामान्य मार्ग नहीं। hbbs पहले दोनों क्लाइंट्स को सीधे जोड़ने का प्रयास करता है, जिसके लिए वह प्रत्येक के सामने मौजूद NAT (नेटवर्क एड्रेस ट्रांसलेशन) के माध्यम से होल पंचिंग का उपयोग करता है। जब यह सफल होता है, तो सेशन कभी भी hbbr को नहीं छूता और आपका ट्रांसफर कोटा सुरक्षित रहता है। जब एक पक्ष ऐसे NAT के पीछे होता है जो प्रति डेस्टिनेशन एक नया पोर्ट असाइन करता है, या किसी ऐसे फायरवॉल के पीछे जो पंच किए गए पाथ को ड्रॉप कर देता है, तो सेशन hbbr पर वापस आ जाता है और हर फ्रेम आपके VPS से होकर गुजरता है।

एक एनवायरनमेंट वेरिएबल इस विकल्प को हटा देता है। hbbs पर ALWAYS_USE_RELAY=Y हर सेशन को hbbr के माध्यम से जाने के लिए मजबूर करता है। RustDesk का डॉक्यूमेंटेशन इसे अपने एक Compose उदाहरण में दिखाता है, इसलिए इसे अक्सर कॉपी कर लिया जाता है। यह कनेक्शन को अधिक पूर्वानुमानित बनाता है और आपके egress को वास्तविक बना देता है। इसे तभी सेट करें जब आपने स्वयं ऐसा निर्णय लिया हो, न कि इसलिए क्योंकि आपने इसे कहीं से पेस्ट किया है।

RustDesk सर्वर को किन ports की आवश्यकता होती है

नीचे दिए गए port numbers की जाँच 17 August 2026 को RustDesk सर्वर documentation और rustdesk-server repository के आधार पर की गई है।

• TCP 21115, hbbs पर: NAT type test के लिए।
• UDP 21116, hbbs पर: ID registration और heartbeat के लिए। इसके बिना client कभी online नहीं आता, चाहे बाकी कोई भी port खुला हो।
• TCP 21116, hbbs पर: TCP hole punching और connection service के लिए।
• TCP 21117, hbbr पर: relay के लिए। यह वह port है जो session data को स्थानांतरित करता है, इसलिए यही वह port है जिसके लिए आपको bandwidth का खर्च उठाना पड़ता है।
• TCP 21118 (hbbs पर) और TCP 21119 (hbbr पर): WebSocket, जिसका उपयोग browser client द्वारा किया जाता है। यदि आप इसका उपयोग नहीं करते हैं, तो दोनों को बंद रखें।
• TCP 21114: RustDesk Server Pro में web console के लिए है। open source build इस पर listen नहीं करता है।

hbbs और hbbr को pinned image tag के साथ install करें

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

दोनों services को running पढ़ना चाहिए। Firewall में बदलाव करने से पहले पुष्टि करें कि listeners मौजूद हैं।

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

आपको 21115, 21116 और 21117 पर TCP listeners और 21116 पर एक UDP listener दिखाई देना चाहिए। UDP line का न होना यह दर्शाता है कि hbbs नहीं चल रहा है, क्योंकि clients इसी listener पर register करते हैं।

इस file में चार चीजें जानबूझकर की गई हैं। Tag 1.1.16 है, जो अगस्त 2026 तक का current release है और 20 जुलाई 2026 को publish हुआ था, न कि latest। इसका कारण यह है कि latest का अर्थ है जो भी सबसे हाल ही में push किया गया है, और छह महीने बाद का docker compose pull आपको ऐसा server दे सकता है जिसे आपने कभी test नहीं किया। network_mode: "host" host interfaces को सीधे bind करता है, जैसा कि RustDesk documentation में अनुशंसित है और यही तय करता है कि आपका firewall कैसे व्यवहार करेगा। ./data:/root image की working directory को host पर map करता है, ताकि key pair ऐसी जगह सुरक्षित रहे जिसका आप backup ले सकें। और hbbr -k _ upstream example से किया गया एकमात्र बदलाव है, क्योंकि default setting आपके relay को किसी के भी उपयोग के लिए खुला छोड़ देती है। यदि Compose आपके लिए नया है, तो VPS पर Docker Compose चलाना file format और lifecycle commands को कवर करता है।

यदि hbbr कभी किसी दूसरे server पर move होता है, तो hbbs को बताना होगा कि वह कहाँ गया है: -r relay.example.com:21117 pass करें, या RELAY-SERVERS environment variable set करें। एक ही box पर आपको इसकी आवश्यकता नहीं है।

Ed25519 key pair ही access control है

पहली बार start होने पर hbbs अपने working directory में id_ed25519 और id_ed25519.pub generate करता है। ऊपर दिए गए mount के साथ, ये दोनों files host पर दिखाई देती हैं।

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

id_ed25519.pub में एक base64 string होती है। वह string हर client के Key field में डाली जाती है। id_ed25519 private हिस्सा है और यह कभी भी server से बाहर नहीं जाना चाहिए। Public key secret नहीं है, क्योंकि इसे वैसे भी हर client config में copy किया जाता है। Private key एक secret है: जिसके पास भी यह होगी, वह ऐसा server खड़ा कर सकता है जिस पर आपके clients भरोसा करेंगे।

बीस clients configure करने से पहले ही, अभी इन दोनों files का backup ले लें।

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

उस archive को server से बाहर copy कर लें। यही कारण है कि यह किसी भी अन्य step से अधिक महत्वपूर्ण है। यदि आप ~/rustdesk/data को delete कर देते हैं, या इसे copy किए बिना किसी नए VPS पर rebuild करते हैं, तो hbbs अगली बार start होने पर एक नया key pair generate कर लेगा। हर client के पास अभी भी पुरानी public key होगी, इसलिए hbbs उसे स्वीकार करने से मना कर देगा और client offline हो जाएगा। sudo cat ~/rustdesk/data/id_ed25519.pub चलाएं और किसी भी client के Key field के साथ उसकी तुलना करें: दोनों strings अब मेल नहीं खाएंगी, और यही mismatch पूरी विफलता का कारण है। इसे ठीक करने का मतलब है हर machine पर settings को मैन्युअल रूप से edit करना, जिसमें वे machines भी शामिल हैं जिन्हें access करने के लिए आप RustDesk पर निर्भर थे।

यह key session password नहीं है, और दोनों के बीच भ्रमित होने के कारण लोग एक को छोड़ देते हैं। यह key तय करती है कि आपका server किन clients से बात करेगा। controlled machine पर मौजूद permanent password या one time code यह तय करता है कि उस machine पर session कौन खोल सकता है। आपको दोनों की आवश्यकता है, और एक का होना दूसरे की कमजोरी की भरपाई नहीं करता है।

बिना प्रमाणीकरण के relay एक समस्या क्यों है

डिफ़ॉल्ट रूप से hbbr किसी चीज़ की जाँच नहीं करता है। RustDesk कॉन्फ़िगरेशन दस्तावेज़ इसे सीधे स्पष्ट करता है: एक खाली key उन क्लाइंट्स को relay का उपयोग करने की अनुमति देती है जिनके पास matching key नहीं है। खाली डिफ़ॉल्ट इसलिए रखा गया है ताकि नए उपयोगकर्ता पहली बार चलाने पर key mismatch की विफलताओं का सामना न करें। इसकी कीमत यह है कि जो कोई भी TCP 21117 पर आपका पता ढूँढ लेता है, वह आपके IP पते से और आपके ट्रांसफर अलाउंस का उपयोग करके अपना सेशन ट्रैफ़िक आपके VPS के माध्यम से भेज सकता है।

command: hbbr -k _ इसे बंद कर देता है। _ तर्क hbbr को अपनी वर्किंग डायरेक्टरी से key pair लोड करने के लिए कहता है, और चूंकि दोनों कंटेनर एक ही ./data को माउंट करते हैं, इसलिए यह वही pair है जिसे hbbs पहले ही जनरेट कर चुका है। कुछ भी हाथ से कॉपी नहीं किया जाता है, इसलिए कुछ भी अलग (drift) नहीं हो सकता है।

शेयर्ड वॉल्यूम वह हिस्सा है जिसे लोग गलत समझते हैं। यदि आप hbbr को अपनी अलग डायरेक्टरी देते हैं, तो यह एक अलग key pair जनरेट कर देता है। hbbs और hbbr तब असहमत हो जाते हैं, हर relayed सेशन विफल हो जाता है, और डायरेक्ट सेशन काम करते रहते हैं। इसका लक्षण भ्रमित करने वाला है: RustDesk कुछ साथियों (peers) तक पहुँचता है और कुछ तक नहीं, यह इस पर निर्भर करता है कि hole punching सफल हुआ या नहीं। एक ls -l ~/rustdesk/data/ जो केवल एक id_ed25519 pair दिखाता है, इस समस्या की संभावना को समाप्त कर देता है।

Clients को अपने सर्वर पर पॉइंट करें

प्रत्येक मशीन पर RustDesk खोलें, फिर Settings, फिर Network, और उसके बाद ID/Relay Server पर जाएँ।

• ID Server: अपना hostname डालें, उदाहरण के लिए rustdesk.example.com। जब तक आप कोई अन्य port न लिखें, client port 21116 का उपयोग करता है।
• Relay Server: यदि hbbr और hbbs एक ही host पर चल रहे हैं, तो इसे खाली छोड़ दें।
• API Server: इसे खाली छोड़ दें। Open source सर्वर इसे प्रदान नहीं करता है।
• Key: id_ed25519.pub से प्राप्त base64 string को यहाँ पेस्ट करें। ध्यान रखें कि अंत में कोई अतिरिक्त space न हो।

इसके बाद मुख्य window में यह दिखना चाहिए कि client तैयार है। यदि ऐसा नहीं होता है, तो इसका अर्थ है कि UDP 21116, hbbs तक नहीं पहुँच पा रहा है, क्योंकि registration और heartbeat केवल UDP पर चलते हैं और इसके बिना ID online नहीं हो सकती।

Ports को restrict करें ताकि relay एक open service न रहे

चूंकि containers host networking का उपयोग करते हैं, इसलिए उनके सामने कोई Docker NAT rule नहीं होता है, अतः ufw rules आपकी अपेक्षा के अनुसार काम करते हैं।

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 को केवल तभी जोड़ें यदि आप browser client चला रहे हैं। ufw enable करते समय एक दूसरा SSH session खुला रखें, ताकि SSH rule में गलती होने पर आप अपने ही सर्वर से बाहर न हो जाएं। VPS के लिए ufw firewall की बुनियादी जानकारी में default policies और rule ordering के बारे में बताया गया है।

अब मुख्य समस्या यह है। यदि आप ports: block का उपयोग करके ports publish करते हैं, जैसा कि वैकल्पिक RustDesk supervisor image उदाहरण में किया गया है, तो Docker अपने स्वयं के DNAT rules लिखता है। इसके बाद packets उस chain से गुजरे बिना container तक पहुँच जाते हैं जहाँ आपके ufw rules स्थित हैं। ऐसी स्थिति में 21117 पर ufw deny का कोई प्रभाव नहीं पड़ता है, और relay internet के लिए open रहता है, जबकि ufw status कुछ और ही दावा करता है। Docker published ports ufw को bypass करते हैं में chain order को समझाया गया है। Host networking इस समस्या से पूरी तरह बचाती है। यदि आप कोई port publish करते हैं, तो उसे एक ही address पर bind करें, जैसा कि reverse proxy के पीछे "127.0.0.1:21118:21118" में किया गया है।

Source address द्वारा restriction केवल तभी काम करती है जब आपके clients के पास stable addresses हों।

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

Hotel networks पर मौजूद laptops के पास stable addresses नहीं होते हैं, और यही कारण है कि hbbr पर मौजूद key यहाँ firewall की तुलना में अधिक प्रभावी सुरक्षा प्रदान करती है।

Upgrading a stack that holds your key

The key lives in the bind mount, not inside the container, so an upgrade is safe as long as you leave ./data alone.

1. Back up the data directory first: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. Read the release notes for the new tag on the rustdesk-server releases page.
3. Edit compose.yml and change both image: lines to the new tag.
4. Run sudo docker compose pull, then sudo docker compose up -d.
5. Run sudo cat ~/rustdesk/data/id_ed25519.pub and confirm the string is the one your clients already hold.

Step 5 is the check that matters, because a changed key is silent on the server and breaks every client at the same moment. Rolling back is putting the old tag back and running up -d again, and that only works because you pinned it: with latest, docker compose pull moved the name onto the new image, so there is no tag left that names the old one.

The usual way to lose the key is not docker compose down, which leaves a bind mount alone. It is migrating to a new VPS and copying only compose.yml. Copy ./data with it.

Transfer allowance वाले प्लान पर egress को मॉनिटर करना

hbbr इस स्टैक का एकमात्र हिस्सा है जो transfer allowance का उपयोग कर सकता है। RustDesk का FAQ बताता है कि 1920x1080 स्क्रीन पर एक relayed connection 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 GB प्रति माह होता है, जिसे कोई भी प्लान आसानी से संभाल सकता है। प्रकाशित रेंज के उच्चतम स्तर पर, वही साठ घंटे 648 GB खर्च करते हैं, और उसी दर पर दो concurrent sessions एक महीने के भीतर 1 TB की allowance को खत्म कर सकते हैं। निचली सीमा 6.5 GB है। यहाँ गीगाबाइट का अर्थ 1000 MB है, जो कि transfer allowance की गणना का मानक तरीका है।

docker stats आपके लिए इसका विवरण नहीं देगा, क्योंकि host networking का उपयोग करने वाला container host network namespace को साझा करता है, इसलिए इसके counters host के ही counters होते हैं। दो अन्य टूल्स काम करते हैं। vnstat पूरे बॉक्स को मापता है:

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

पूरे बॉक्स का मतलब पूरा बॉक्स है: यदि यह VPS कुछ ऐसा भी चलाता है जो वास्तविक डेटा ट्रांसफर करता है, जैसे कि self-hosted photo servers जो हर रात फोन की लाइब्रेरी को सिंक करते हैं, तो उनका अपलोड भी आपके relay traffic के साथ उसी मासिक डेटा में जुड़ जाता है। मीडिया सर्वर के साथ भी यही स्थिति है, क्योंकि Halcyon, जो Jellyfin लाइब्रेरी को 90 के दशक के वीडियो स्टोर जैसा बनाता है किसी भी दर्शक को स्ट्रीम करता है, और वह egress उसी allowance का उपयोग करता है जिसे आपका relay खर्च कर रहा है।

एक nftables counter विशेष रूप से relay को मापता है:

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

उस rule का कोई verdict नहीं है, इसलिए यह अनुमति में बदलाव किए बिना packets और bytes को गिनता है, और यह अपनी खुद की table में रहता है ताकि ufw में कोई बाधा न आए। यह persistent नहीं है: यदि आप चाहते हैं कि reboot के बाद यह वापस आ जाए, तो वही लाइनें /etc/nftables.conf में डालें। counter केवल तभी बढ़ता है जब कोई सेशन वास्तव में relay हो रहा हो। यदि counter तब भी बढ़ रहा है जब आपकी अपनी कोई मशीन कनेक्टेड नहीं है, तो इसका मतलब है कि किसी और ने आपके relay को ढूंढ लिया है, और इसी स्थिति को रोकने के लिए hbbr -k _ मौजूद है। चूंकि आप हर सुबह nft list नहीं पढ़ेंगे, इसलिए इस पर एक cron job लगाएं जो byte count की तुलना एक threshold से करे और सीमा पार होने पर push alert भेजे, जिसके लिए आपका अपना ntfy server सबसे उपयुक्त है।

hbbr में rate limits भी हैं जिन्हें आप कम कर सकते हैं। SINGLE_BANDWIDTH का डिफ़ॉल्ट मान प्रति relay connection 128 Mb/s है और TOTAL_BANDWIDTH का मान सभी के लिए 1024 Mb/s है। SINGLE_BANDWIDTH=8 को सेट करने से एक सेशन लगभग 1 MB/s पर सीमित हो जाता है। यह गति को सीमित करता है, न कि मासिक कुल डेटा को, इसलिए इसे बजट नियंत्रण के बजाय इस तरह देखें कि एक सेशन लिंक को पूरी तरह saturate न कर पाए।

जब आपको किसी relay की बिल्कुल भी आवश्यकता न हो

व्यक्तिगत सेटअप के लिए, ईमानदार उत्तर यह है कि आपको इनमें से किसी की भी आवश्यकता नहीं हो सकती है। दोनों मशीनों को एक mesh VPN पर रखें और सीधे tunnel address से कनेक्ट करें। इसमें न तो hbbs है, न hbbr, न relay egress, और न ही upgrade करने के लिए VPS पर कोई container है।

जिस मशीन को आप नियंत्रित करना चाहते हैं, उस पर RustDesk की security settings में direct IP access को enable करें। port field का default मान 21118 होता है। कनेक्ट करने का प्रयास करने से पहले जाँच लें कि क्या यह listening मोड में है:

ss -tlnp | grep 21118

फिर ID के बजाय उस peer के VPN address से कनेक्ट करें। RustDesk का FAQ इस मोड के बारे में कहता है कि connection unencrypted होता है, इसलिए इसे tunnel के भीतर चलाएं और कभी भी open internet पर न चलाएं। encryption tunnel द्वारा प्रदान किया जाता है।

यह चुनें कि मशीनों का स्वामी कौन है। self-hosted hbbs और hbbr तब सही होता है जब आप ऐसी मशीनों को support करते हैं जो आपकी नहीं हैं, या ऐसे लोगों को जो कभी भी VPN client install नहीं करेंगे, क्योंकि उनकी तरफ का सेटअप केवल एक ID और password है। direct IP access वाला mesh VPN तब सही होता है जब हर मशीन आपकी हो और उसमें key रखी जा सके। WireGuard की Tailscale के साथ तुलना उस mesh को बनाने के दो सामान्य तरीकों को कवर करती है, और Linux VPS पर remote desktop चलाना दूसरे मामले को कवर करता है, जहाँ वह मशीन जिस पर आप screen चाहते हैं, वह स्वयं server है।

FAQ

क्या हर RustDesk session मेरे relay से होकर गुजरता है?

नहीं। hbbs पहले दोनों clients को सीधे जोड़ने का प्रयास करता है, जिसके लिए वह उनके सामने मौजूद NAT के माध्यम से hole punching का उपयोग करता है। केवल वे sessions जिनमें यह प्रक्रिया विफल हो जाती है, वे hbbr पर वापस आते हैं, और केवल उन्हीं के लिए आपको bandwidth खर्च करनी पड़ती है। इसका अपवाद hbbs पर ALWAYS_USE_RELAY=Y है, जो इस बात की परवाह किए बिना कि सीधा रास्ता उपलब्ध था या नहीं, हर session को hbbr से होकर गुजरने के लिए मजबूर करता है। यदि वह variable आपकी Compose file में set है, तो हर session का हर byte आपके transfer bill में जुड़ेगा।

RustDesk server key कहाँ store होती है, और यदि मैं इसे खो दूँ तो क्या होगा?

hbbs पहली बार start होने पर अपनी working directory में id_ed25519 और id_ed25519.pub generate करता है। official image के भीतर वह directory /root है, इसलिए ऊपर दिखाए गए volume mount के साथ ये files host पर ./data में दिखाई देती हैं। दोनों files का server से बाहर backup लें। यदि वे खो जाती हैं, तो hbbs अगली बार start होने पर एक नया pair generate करेगा, और जिन clients के पास पुरानी public key है, उन्हें access देने से मना कर दिया जाएगा। इसके बाद हर client पर जाकर Key field को manually edit करने के अलावा कोई recovery विकल्प नहीं है।

self-hosted RustDesk server के लिए मुझे कौन से ports open करने होंगे?

TCP 21115, 21116 और 21117, साथ ही UDP 21116। hbbs NAT type test के लिए 21115 का उपयोग करता है, और ID registration तथा heartbeat के लिए UDP पर, और hole punching के लिए TCP पर 21116 का उपयोग करता है। hbbr relay के लिए 21117 का उपयोग करता है। TCP 21118 और 21119 browser client के लिए WebSocket ports हैं, इसलिए यदि आप उनका उपयोग नहीं करते हैं तो उन्हें बंद रखें। TCP 21114 Pro web console के लिए है और open source build को इसकी आवश्यकता नहीं होती है।

क्या अजनबी मेरे self-hosted RustDesk relay का उपयोग कर सकते हैं?

हाँ, यदि आप hbbr को उसकी default configuration के साथ चलाते हैं। RustDesk documentation के अनुसार, एक empty key उन clients को relay का उपयोग करने की अनुमति देती है जिनके पास matching key नहीं है, इसलिए कोई भी व्यक्ति जिसे आपका hostname और port 21117 पता चल जाए, वह आपके server के माध्यम से traffic भेज सकता है। hbbr को -k _ के साथ चलाएं ताकि वह उसी key pair को load करे जिसे hbbs ने shared ./data volume में generate किया था। उसके बाद, केवल वही clients आपके माध्यम से relay कर पाएंगे जिन्हें आपकी public key के साथ configure किया गया है।