RustDesk relay server को VPS पर कैसे host करें

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

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

दोनों daemons एक ही image, rustdesk/rustdesk-server में आते हैं, और नीचे दिए गए setup में दोनों एक ही directory से एक ही Ed25519 key pair को पढ़ते हैं। यह वह है जिसे आप configure करते हैं, न कि कोई default: hbbs खुद ही pair को load या generate करता है, लेकिन hbbr keys को तब तक ignore करता है जब तक आप उसे किसी key के साथ start न करें। Ed25519 एक public key signature scheme है। वह key pair तय करता है कि आपका सर्वर किन clients से बात करेगा, और इसके पीछे कोई user database नहीं होता है।

hbbs और hbbr: कौन सा daemon bandwidth खर्च करता है

hbbs का traffic कम और निरंतर होता है: ID registration और heartbeats, साथ ही दो peers को जोड़ने वाला संक्षिप्त exchange। यह पूरे दिन चलता है और लगभग कुछ भी खर्च नहीं करता है।

hbbr का traffic स्वयं session का होता है। Screen frames एक दिशा में जाते हैं, keyboard और mouse दूसरी दिशा में, और हर relayed byte आपके VPS पर पहुँचता है और फिर वहाँ से बाहर निकलता है। यदि आपका provider केवल egress को मापता है, तो एक relayed session की लागत session rate के बराबर होती है। यदि यह कुल transfer को मापता है, तो लागत लगभग दोगुनी हो जाती है।

Relay एक fallback है, सामान्य रास्ता नहीं। hbbs पहले दोनों clients को सीधे जोड़ने का प्रयास करता है, इसके लिए वह प्रत्येक client के सामने मौजूद NAT (network address translation) के माध्यम से hole punching का उपयोग करता है। जब यह काम करता है, तो session कभी भी hbbr को नहीं छूता है और आपका transfer allowance सुरक्षित रहता है। जब एक पक्ष ऐसे NAT के पीछे होता है जो प्रति destination एक नया port assign करता है, या किसी firewall के पीछे होता है जो punched path को drop कर देता है, तो session hbbr पर fallback हो जाता है और हर frame आपके VPS से होकर गुजरता है।

एक environment variable इस विकल्प को हटा देता है। hbbs पर ALWAYS_USE_RELAY=Y हर session को hbbr के माध्यम से जाने के लिए मजबूर करता है। RustDesk documentation इसे अपने एक Compose उदाहरण में दिखाता है, इसलिए इसे बहुत अधिक copy किया जाता है। यह connections को अधिक predictable बनाता है और आपके egress को वास्तविक बनाता है। इसे इसलिए set करें क्योंकि आपने ऐसा करने का निर्णय लिया है, न कि इसलिए कि आपने इसे copy-paste किया है।

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

नीचे दिए गए port numbers को 10 October 2026 को RustDesk सर्वर documentation और rustdesk-server repository के अनुसार जाँचा गया था।

• TCP 21115, hbbs पर: NAT टाइप टेस्ट।
• UDP 21116, hbbs पर: ID रजिस्ट्रेशन और हार्टबीट। यह वह path है जिसका उपयोग client डिफ़ॉल्ट रूप से करता है।
• TCP 21116, hbbs पर: केवल TCP पर सेट किए गए clients के लिए ID रजिस्ट्रेशन, साथ ही TCP होल पंचिंग और कनेक्शन सर्विस।
• TCP 21117, hbbr पर: रिले। यह वह port है जो सेशन डेटा को स्थानांतरित करता है, इसलिए यही वह port है जिस पर आपका खर्च (बैंडविड्थ) होता है।
• TCP 21118 (hbbs पर) और TCP 21119 (hbbr पर): WebSocket, जिसका उपयोग ब्राउज़र client द्वारा किया जाता है। यदि आप इसका उपयोग नहीं करते हैं, तो दोनों को बंद रखें।
• TCP 21114, RustDesk Server Pro में HTTP API सर्वर है। ओपन सोर्स बिल्ड इस पर listen नहीं करता है।

hbbs और hbbr को pinned image tag के साथ इंस्टॉल करें

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 लाइन का न होना यह दर्शाता है कि hbbs नहीं चल रहा है, क्योंकि hbbs शुरू होने पर ही उस listener को खोलता है और डिफ़ॉल्ट रूप से clients इसी पर register करते हैं।

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

यदि hbbr कभी किसी दूसरे सर्वर पर जाता है, तो hbbs को बताना होगा कि वह कहाँ गया है: -r relay.example.com:21117 पास करें, या RELAY-SERVERS environment variable सेट करें। एक ही 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 को box से बाहर 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 अब मेल नहीं खाती हैं, और यही विफलता का मुख्य कारण है। इसे ठीक करने का मतलब है हर machine पर settings को मैन्युअल रूप से edit करना, जिसमें वे machines भी शामिल हैं जिन्हें access करने के लिए आप RustDesk पर निर्भर थे।

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

अनधिकृत रिले (unauthenticated relay) एक समस्या क्यों है

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

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

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

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

इसे hbbr -k _ प्रिंट करना चाहिए। एक खाली hbbr का मतलब है कि रिले अभी भी खुला है, चाहे डायरेक्टरी में कुछ भी मौजूद हो।

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

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

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

इसके बाद मुख्य विंडो में यह दिखाई देना चाहिए कि क्लाइंट तैयार है। यदि ऐसा नहीं होता है, और क्लाइंट default सेटिंग्स पर चल रहा है, तो इसका सामान्य कारण यह है कि UDP 21116, hbbs तक नहीं पहुँच पा रहा है, क्योंकि डिफ़ॉल्ट क्लाइंट यहीं रजिस्टर होता है और अपना heartbeat भेजता है। हालाँकि, केवल एक offline ID होने का मतलब यह नहीं है कि समस्या यही है। जिस क्लाइंट में disable-udp विकल्प को Y पर सेट किया गया है, वह TCP 21116 के माध्यम से रजिस्टर होता है और कभी भी UDP 21116 का उपयोग नहीं करता है, इसलिए ऐसे क्लाइंट के लिए पहले TCP 21116 की जाँच करें।

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 के कई single container उदाहरण करते हैं, तो Docker अपने स्वयं के DNAT rules लिखता है और packets आपके ufw rules वाली chain से गुजरे बिना सीधे container तक पहुँच जाते हैं। ऐसी स्थिति में 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 की तुलना में अधिक प्रभावी ढंग से काम करती है।

ऐसी stack को अपग्रेड करना जिसमें आपकी key मौजूद हो

Key bind mount के अंदर रहती है, न कि container के भीतर, इसलिए यदि आप ./data को नहीं बदलते हैं तो अपग्रेड सुरक्षित है।

1. सबसे पहले data directory का backup लें: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data।
2. rustdesk-server releases page पर नए tag के लिए release notes पढ़ें।
3. compose.yml को edit करें और दोनों image: lines को नए tag में बदलें।
4. sudo docker compose pull चलाएं, फिर sudo docker compose up -d चलाएं।
5. sudo cat ~/rustdesk/data/id_ed25519.pub चलाएं और पुष्टि करें कि string वही है जो आपके clients के पास पहले से मौजूद है।

Step 5 सबसे महत्वपूर्ण जाँच है, क्योंकि server पर key बदलने का पता नहीं चलता और यह एक ही समय में सभी clients का connection तोड़ देती है। Roll back करने का अर्थ है पुराने tag को वापस लगाना और फिर से up -d चलाना, और यह केवल इसलिए काम करता है क्योंकि आपने इसे pin किया था: latest के साथ, docker compose pull ने name को नई image पर move कर दिया है, इसलिए अब ऐसा कोई tag नहीं बचा है जो पुरानी image को point करे।

Key खोने का सामान्य कारण docker compose down नहीं है, जो bind mount को प्रभावित नहीं करता। इसका मुख्य कारण किसी नए VPS पर migrate करना और केवल compose.yml को copy करना है। इसके साथ ./data को भी copy करें।

ट्रांसफर अलाउंस वाले प्लान पर egress को मॉनिटर करना

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

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

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

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

एक 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 को बाधित न करे। यह persistent नहीं है: यदि आप चाहते हैं कि reboot के बाद भी यह बना रहे, तो इन्हीं लाइनों को /etc/nftables.conf में डालें। काउंटर केवल तभी बढ़ता है जब कोई सेशन वास्तव में रिले किया जा रहा हो। यदि काउंटर तब भी बढ़ रहा है जब आपकी अपनी कोई मशीन कनेक्टेड नहीं है, तो इसका मतलब है कि किसी और ने आपके रिले को ढूंढ लिया है, और इसी स्थिति को रोकने के लिए hbbr -k _ मौजूद है। चूंकि आप हर सुबह nft list नहीं पढ़ेंगे, इसलिए इस पर एक cron job लगाएं जो बाइट काउंट की तुलना एक थ्रेशोल्ड से करे और सीमा पार होने पर पुश अलर्ट भेजे, जिसके लिए your own ntfy server का उपयोग किया जा सकता है।

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

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

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

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

ss -tlnp | grep 21118

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

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

FAQ

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

नहीं। hbbs पहले दोनों clients को सीधे जोड़ने का प्रयास करता है, जिसके लिए वह दोनों के सामने मौजूद NAT के माध्यम से hole punching का उपयोग करता है। केवल वे sessions जिनमें यह प्रक्रिया विफल हो जाती है, वे hbbr पर वापस आ जाते हैं, और केवल उन्हीं के लिए आपको bandwidth खर्च करनी पड़ती है। इसका अपवाद hbbs पर ALWAYS_USE_RELAY=Y है, जो सीधा रास्ता उपलब्ध होने पर भी हर session को hbbr के माध्यम से जाने के लिए मजबूर करता है। यदि आपके Compose file में यह variable 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 कर लेगा, और पुरानी public key रखने वाले हर client को access देने से मना कर दिया जाएगा। इसके बाद हर client पर जाकर Key field को हाथ से edit करने के अलावा कोई recovery विकल्प नहीं है।

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

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

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

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