নিজের VPS-এ RustDesk relay server চালানোর নিয়ম

একটি self-hosted RustDesk relay server কী

একটি self-hosted RustDesk relay server একই VPS-এ চলা দুটি daemon নিয়ে গঠিত। hbbs হলো ID ও rendezvous server: এটি প্রতিটি client ID নিবন্ধন করে এবং দুটি client-কে একে অপরের সঙ্গে সংযুক্ত করে। hbbr হলো relay server: এটি session-এর bytes বহন করে, তবে কেবল যেসব session সরাসরি যোগাযোগ স্থাপন করতে পারেনি সেগুলোর জন্য। অধিকাংশ গাইড দুটিই install করে, client pair করিয়ে, সেখানেই থেমে যায়। বাকি কাজের মধ্যে রয়েছে access control হিসেবে ব্যবহৃত key, port, upgrade এবং bandwidth ব্যবস্থাপনা।

দুটি daemon একই image, rustdesk/rustdesk-server-এর মধ্যে থাকে এবং একই directory থেকে একই Ed25519 key pair পড়ে। Ed25519 হলো public key signature scheme। এই key pair নির্ধারণ করে আপনার server কোন client-এর সঙ্গে যোগাযোগ করবে। এর পেছনে কোনো user database নেই।

hbbs ও hbbr: কোন daemon আপনার bandwidth খরচ করে

hbbs-এর traffic কম এবং স্থির: ID registration ও heartbeat, আর দুটি peer-কে পরিচয় করিয়ে দেওয়ার সংক্ষিপ্ত আদান-প্রদান। এটি সারা দিন চলে এবং প্রায় কোনো খরচ হয় না।

hbbr-এর traffic-ই মূল session। Screen frame একদিকে যায়, keyboard ও mouse input অন্যদিকে যায়, এবং relay করা প্রতিটি byte প্রথমে আপনার VPS-এ আসে, তারপর আবার সেখান থেকে বের হয়। আপনার provider শুধু egress মাপলে relayed session-এর খরচ প্রায় session rate-এর সমান। মোট transfer মাপলে খরচ প্রায় দ্বিগুণ।

Relay হলো fallback, স্বাভাবিক পথ নয়। hbbs প্রথমে প্রতিটি client-এর সামনে থাকা NAT (network address translation) অতিক্রম করে hole punching ব্যবহার করে দুই client-কে সরাসরি সংযোগ করানোর চেষ্টা করে। এটি সফল হলে session কখনও hbbr-এ যায় না এবং আপনার transfer allowance অক্ষত থাকে। কোনো একটি দিক যদি এমন NAT-এর পেছনে থাকে যা প্রতিটি destination-এর জন্য নতুন port বরাদ্দ করে, অথবা এমন firewall-এর পেছনে থাকে যা punched path বাদ দেয়, তাহলে session hbbr-এ fallback করে এবং প্রতিটি frame আপনার VPS-এর মধ্য দিয়ে যায়।

একটি environment variable এই পছন্দ সরিয়ে দেয়। ALWAYS_USE_RELAY=Y hbbs-এ সেট করলে প্রতিটি session hbbr-এর মধ্য দিয়ে যায়। RustDesk documentation-এর একটি Compose উদাহরণে এটি দেখানো আছে, তাই অনেকেই এটি কপি করেন। এতে connection আরও পূর্বানুমানযোগ্য হয় এবং আপনার egress-এর প্রকৃত খরচ দেখা যায়। আপনি সিদ্ধান্ত নিয়েছেন বলে এটি সেট করুন, শুধু কপি-পেস্ট করেছেন বলে নয়।

Self-hosted RustDesk server-এর কোন port প্রয়োজন

নিচের port নম্বরগুলো 17 August 2026 তারিখে RustDesk server-এর documentation এবং rustdesk-server repository-এর সঙ্গে মিলিয়ে যাচাই করা হয়েছে।

• TCP 21115, hbbs-এ: NAT type পরীক্ষা।
• UDP 21116, hbbs-এ: ID registration এবং heartbeat। এটি খোলা না থাকলে অন্য port খোলা থাকলেও client কখনো online হয় না।
• TCP 21116, hbbs-এ: TCP hole punching এবং connection service।
• TCP 21117, hbbr-এ: relay। এই port দিয়ে session data স্থানান্তরিত হয়, তাই এই port-ই আপনার খরচ তৈরি করে।
• hbbs-এ TCP 21118 এবং hbbr-এ TCP 21119: WebSocket, browser client ব্যবহার করে। এটি ব্যবহার না করলে দুটিই বন্ধ রাখুন।
• TCP 21114 হলো RustDesk Server Pro-এর web console। open source build এই port-এ listen করে না।

image tag pin করে 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

উভয় service-এর running পড়া উচিত। firewall পরিবর্তন করার আগে listener-গুলো সক্রিয় আছে কি না নিশ্চিত করুন।

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

আপনার 21115, 21116 এবং 21117-এ TCP listener এবং 21116-এ একটি UDP listener দেখা উচিত। UDP line না থাকলে hbbs চলছে না, কারণ client-রা এই listener-এ register করে।

ওই file-এ চারটি বিষয় ইচ্ছাকৃতভাবে নির্ধারণ করা হয়েছে। tag হলো 1.1.16, যা August 2026 অনুযায়ী current release এবং 20 July 2026-এ প্রকাশিত হয়েছে। এটি latest নয়, কারণ latest-এর অর্থ হলো সর্বশেষ push করা যেকোনো version। ছয় মাস পরে একটি docker compose pull এমন server দিতে পারে, যা আপনি কখনও পরীক্ষা করেননি। network_mode: "host" সরাসরি host interface-এ bind করে। RustDesk documentation-এ এটিই সুপারিশ করা হয়েছে এবং firewall কীভাবে আচরণ করবে, তা এটিই নির্ধারণ করে। ./data:/root image-এর working directory-কে host-এর ওপর map করে, যাতে key pair এমন জায়গায় সংরক্ষিত হয় যেখানে আপনি backup নিতে পারেন। আর hbbr -k _ হলো upstream example থেকে একমাত্র পরিবর্তন, কারণ default configuration যে কারও জন্য আপনার relay উন্মুক্ত রাখে। Compose আপনার জন্য নতুন হলে VPS-এ Docker Compose চালানো-এ file format এবং lifecycle command ব্যাখ্যা করা হয়েছে।

hbbr কখনও দ্বিতীয় server-এ সরানো হলে hbbs-কে সেটি কোথায় গেছে তা জানাতে হবে: -r relay.example.com:21117 pass করুন, অথবা RELAY-SERVERS environment variable সেট করুন। একটি server-এ সব চালালে এটি প্রয়োজন নেই।

Ed25519 key pair-ই access control

প্রথমবার চালু হলে hbbs তার working directory-তে id_ed25519 এবং id_ed25519.pub তৈরি করে। উপরের mount ব্যবহারের ফলে দুটি ফাইলই 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 গোপন নয়, কারণ এটি এমনিতেই প্রতিটি client configuration-এ কপি করা হয়। private key গোপনীয়। যার কাছে এটি থাকবে, সে এমন একটি server চালু করতে পারবে যেটিকে আপনার client-গুলো বিশ্বাস করবে।

এখনই দুটি ফাইলের backup নিন, 20টি client configure করার আগে।

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

সেই archive-টি server-এর বাইরে কপি করুন। অন্য যেকোনো ধাপের চেয়ে এটি বেশি গুরুত্বপূর্ণ কেন, তা নিচে বলা হলো। ~/rustdesk/data মুছে ফেললে, অথবা এটি কপি না করে নতুন VPS-এ rebuild করলে, পরবর্তী start-এর সময় hbbs নতুন key pair তৈরি করবে। প্রতিটি client-এ তখনও পুরোনো public key থাকবে। তাই hbbs client-টিকে প্রত্যাখ্যান করবে এবং client offline হয়ে যাবে। sudo cat ~/rustdesk/data/id_ed25519.pub চালিয়ে যেকোনো client-এর Key field-এর সঙ্গে তুলনা করুন। দুটি string আর মিলবে না। এই অমিলই পুরো সমস্যার কারণ। এটি ঠিক করতে প্রতিটি machine-এ settings হাতে edit করতে হবে। যেসব machine-এ পৌঁছানোর জন্য আপনি RustDesk-এর ওপর নির্ভর করছিলেন, সেগুলোকেও বাদ দেওয়া যাবে না।

এই key session password নয়। দুটি গুলিয়ে ফেললে অনেকে একটি বাদ দিয়ে দেন। key নির্ধারণ করে কোন client আপনার server-এর সঙ্গে যোগাযোগ করতে পারবে। controlled machine-এ থাকা permanent password বা one time code নির্ধারণ করে কে সেই machine-এ session খুলতে পারবে। আপনার দুটিই প্রয়োজন। একটির উপস্থিতি অন্যটির দুর্বলতা পূরণ করে না।

অনুমোদনহীন relay কেন সমস্যা

ডিফল্টভাবে hbbr কোনো যাচাই করে না। RustDesk configuration documentation-এ বিষয়টি সরাসরি বলা আছে: খালি key থাকলে matching key ছাড়াই clients relay ব্যবহার করতে পারে। নতুন users যাতে প্রথমবার চালানোর সময় key mismatch-এর কারণে ব্যর্থ না হয়, সে জন্য এই খালি default রাখা হয়েছে। এর খরচ হলো, TCP 21117-এ আপনার address খুঁজে পাওয়া যেকেউ আপনার VPS-এর মাধ্যমে, আপনার transfer allowance ব্যবহার করে এবং আপনার IP address থেকে তাদের session traffic পাঠাতে পারে।

command: hbbr -k _ এটি বন্ধ করে। _ argument hbbr-কে তার working directory থেকে একটি key pair load করতে বলে। উভয় container একই ./data mount করে বলে এটি hbbs-এর আগে তৈরি করা সেই pair-ই। হাতে করে কিছু copy করতে হয় না, তাই কোনো অমিলও তৈরি হয় না।

Shared volume-ই সেই অংশ, যেখানে অনেকে ভুল করে। hbbr-কে আলাদা directory দিলে এটি একটি ভিন্ন key pair তৈরি করে। এরপর hbbs এবং hbbr-এর key মেলে না, ফলে প্রতিটি relayed session ব্যর্থ হয়, কিন্তু direct session কাজ করতে থাকে। লক্ষণটি বিভ্রান্তিকর: hole punching সফল হয়েছে কি না তার ওপর নির্ভর করে RustDesk কিছু peer-এ পৌঁছাতে পারে, অন্যগুলোর ক্ষেত্রে পারে না। একটি ls -l ~/rustdesk/data/-এ একটি মাত্র id_ed25519 pair দেখা গেলে এই কারণটি বাদ দেওয়া যায়।

ক্লায়েন্টগুলোকে আপনার server-এ নির্দেশ করুন

প্রতিটি machine-এ 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 server এটি সরবরাহ করে না।
• Key: id_ed25519.pub থেকে পাওয়া base64 string হুবহু paste করুন। শেষে কোনো space রাখবেন না।

এরপর main window-তে client প্রস্তুত আছে বলে দেখানো উচিত। তা না হলে UDP 21116 hbbs-এ পৌঁছাচ্ছে না, কারণ registration এবং heartbeat UDP-এর মাধ্যমে চলে এবং অন্য কোনো কিছু ID-কে online করে না।

Port সীমিত করুন, যাতে relay উন্মুক্ত service না থাকে

Container-গুলো host networking ব্যবহার করে। তাই তাদের সামনে Docker NAT rule থাকে না এবং ufw rule আপনার প্রত্যাশামতো প্রয়োগ হয়।

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

Browser client চালালে তবেই 21118:21119/tcp যোগ করুন। ufw enable করার সময় দ্বিতীয় একটি SSH session খোলা রাখুন, যাতে SSH rule-এ ভুল হলে আপনি নিজের server থেকে বিচ্ছিন্ন না হয়ে যান। VPS-এর জন্য ufw firewall-এর মৌলিক বিষয়-এ default policy এবং rule-এর ক্রম ব্যাখ্যা করা হয়েছে।

এখন গুরুত্বপূর্ণ সমস্যাটি দেখুন। আপনি যদি ports: block ব্যবহার করে port publish করেন, যা বিকল্প RustDesk supervisor image উদাহরণে ব্যবহার করা হয়েছে, Docker নিজস্ব DNAT rule লিখবে। তখন packet সেই chain অতিক্রম না করেই container-এ পৌঁছাবে, যেখানে আপনার ufw rule কার্যকর হয়। ফলে 21117 port-এ ufw deny কোনো প্রভাব ফেলবে না। ufw status বিপরীত দাবি করলেও relay Internet-এর জন্য উন্মুক্ত থাকবে। Docker-এর published port ufw এড়িয়ে যায়-এ chain-এর ক্রম ব্যাখ্যা করা হয়েছে। Host networking এই সমস্যা সম্পূর্ণ এড়ায়। Port publish করতেই হলে একটি নির্দিষ্ট address-এ bind করুন, যেমন reverse proxy-এর পেছনে "127.0.0.1:21118:21118"।

Source address অনুযায়ী সীমাবদ্ধতা কার্যকর হবে কেবল তখনই, যখন client-গুলোর address স্থিতিশীল থাকবে।

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 network-এ থাকা laptop-এর address স্থিতিশীল নয়। তাই এখানে firewall-এর চেয়ে hbbr-এ থাকা key-টি বেশি কার্যকর সুরক্ষা দেয়।

আপনার key ধারণকারী stack আপগ্রেড করা

key-টি container-এর ভিতরে নয়, bind mount-এ থাকে। তাই ./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 সম্পাদনা করে উভয় image: line-এ নতুন tag বসান।
4. sudo docker compose pull চালান, তারপর sudo docker compose up -d চালান।
5. sudo cat ~/rustdesk/data/id_ed25519.pub চালান এবং নিশ্চিত করুন যে string-টি আপনার client-গুলোতে ইতিমধ্যে থাকা string-এর সঙ্গে মিলে।

Step 5-ই গুরুত্বপূর্ণ পরীক্ষা। কারণ server-এ key পরিবর্তিত হলেও তা নীরবে ঘটে এবং একই সময়ে প্রতিটি client-এর সংযোগ বিচ্ছিন্ন করে। rollback করতে পুরনো tag ফিরিয়ে বসিয়ে আবার up -d চালান। এটি কেবল তখনই কাজ করে যখন tag নির্দিষ্ট করে রেখেছিলেন। latest ব্যবহারের ক্ষেত্রে docker compose pull name-টিকে নতুন image-এ সরিয়ে দিয়েছে, তাই পুরনোটির নাম নির্দেশ করে এমন কোনো tag আর থাকে না।

key হারানোর সাধারণ কারণ docker compose down নয়, কারণ এটি bind mount অপরিবর্তিত রাখে। সাধারণত নতুন VPS-এ migration করার সময় শুধু compose.yml copy করলেই key হারায়। এর সঙ্গে ./data-ও copy করুন।

অনুমোদিত ট্রান্সফার-সীমার পরিকল্পনায় egress পর্যবেক্ষণ

এই stack-এর একমাত্র অংশ, যা ট্রান্সফার-সীমা ব্যবহার করতে পারে, সেটি হলো hbbr। RustDesk-এর FAQ অনুযায়ী 1920x1080 screen-এ একটি relayed connection-এর খরচ 30 KB/s থেকে 3 MB/s-এর মধ্যে হতে পারে। সাধারণ office work-এর জন্য প্রায় 100 KB/s ধরা হয়। এগুলো একটি session-এর প্রকাশিত পরিসংখ্যান; আপনার setup-এর পরিমাপ নয়। মাসে প্রতিদিন দুই ঘণ্টা করে মোট ষাট ঘণ্টার হিসাবে এগুলো এমন দেখায়।

[
  {
    "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
  }
]

Office work-এর হারে একটি session-এর মাসিক খরচ প্রায় 21.6 GB, যা কোনো plan-ই লক্ষ করবে না। প্রকাশিত সর্বোচ্চ হারে একই ষাট ঘণ্টার খরচ 648 GB। ওই হারে একসঙ্গে দুটি session চললে মাসের মধ্যেই 1 TB allowance অতিক্রম করবে। সর্বনিম্ন হার হলো 6.5 GB। এখানে Gigabytes বলতে 1000 MB বোঝানো হয়েছে, কারণ transfer allowance সাধারণত এভাবেই গণনা করা হয়।

docker stats আপনার জন্য এই হিসাব আলাদা করে দেখাবে না। কারণ host networking ব্যবহার করা container host-এর network namespace ভাগ করে নেয়। তাই এর counter-গুলো host-এর counter। অন্য দুটি tool কাজে আসে। vnstat পুরো box-এর পরিমাপ করে:

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

পুরো box বলতে সত্যিই পুরো box বোঝায়। এই VPS-এ যদি এমন কোনো service-ও চলে, যা প্রকৃত data স্থানান্তর করে—যেমন প্রতি রাতে phone library টেনে নেওয়া self-hosted photo server—তাহলে তার upload আপনার relay traffic-এর সঙ্গে একই মাসিক হিসাবের অন্তর্ভুক্ত হবে। উল্টো দিক থেকেও media server-এর ক্ষেত্রে একই বিষয় প্রযোজ্য। যেমন Halcyon, যা Jellyfin library-কে browse করা যায় এমন 90s video store-এ রূপান্তর করে, দেখছে এমন ব্যবহারকারীদের কাছে stream পাঠায়। সেই egress-ও আপনার relay যে allowance ব্যবহার করছে, সেটিই ভাগ করে নেয়।

একটি 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 নেই। তাই অনুমোদিত traffic পরিবর্তন না করে এটি packet ও byte গণনা করে। এটি আলাদা table-এ রাখা হয়েছে, যাতে ufw-তে কোনো প্রভাব না পড়ে। এটি persistent নয়। Reboot-এর পর আবার চালু রাখতে একই lines /etc/nftables.conf-এ যোগ করুন। Session বাস্তবে relay হওয়ার সময়ই counter বাড়ে। আপনার নিজের কোনো machine connected না থাকা অবস্থায় counter বাড়তে থাকলে বুঝবেন অন্য কেউ আপনার relay খুঁজে পেয়েছে। এটি ঠেকাতেই hbbr -k _ রয়েছে। আপনি প্রতিদিন সকালে nft list পড়বেন না। তাই এতে একটি cron job যোগ করুন, যা byte count একটি threshold-এর সঙ্গে তুলনা করবে এবং threshold অতিক্রম করলে push alert পাঠাবে। এই কাজের জন্য আপনার নিজস্ব ntfy server ব্যবহার করুন।

hbbr-এ rate limit-ও রয়েছে, যা আপনি কমাতে পারেন। প্রতি relay connection-এর জন্য SINGLE_BANDWIDTH-এর default 128 Mb/s এবং সব connection মিলিয়ে TOTAL_BANDWIDTH-এর default 1024 Mb/s। SINGLE_BANDWIDTH=8 সেট করলে একটি session-এর গতি প্রায় 1 MB/s-এ সীমাবদ্ধ হবে। এতে গতি কমে, মাসিক মোট পরিমাণ নয়। তাই এটিকে মাসিক budget নিয়ন্ত্রণের উপায় হিসেবে নয়, বরং একটি session যাতে পুরো link saturate না করে তা নিশ্চিত করার উপায় হিসেবে ব্যবহার করুন।

রিলে একেবারেই প্রয়োজন না হলে

ব্যক্তিগত ব্যবহারের ক্ষেত্রে সৎ উত্তর হলো, আপনার এগুলোর কোনোটি প্রয়োজন নাও হতে পারে। উভয় মেশিনকে একটি mesh VPN-এ যুক্ত করুন এবং tunnel address ব্যবহার করে সরাসরি সংযোগ করুন। এখানে hbbs বা hbbr-এর প্রয়োজন নেই, relay egress নেই, এবং আপগ্রেড করার জন্য VPS-এ কোনো container-ও নেই।

যে মেশিনটি নিয়ন্ত্রণ করতে চান, তার RustDesk-এর security settings-এ direct IP access সক্রিয় করুন। port field-এর default মান 21118। সংযোগের চেষ্টা করার আগে এটি listening অবস্থায় আছে কি না যাচাই করুন:

ss -tlnp | grep 21118

এরপর ID-এর পরিবর্তে ওই peer-এর VPN address ব্যবহার করে সংযোগ করুন। RustDesk-এর FAQ অনুযায়ী, এই mode-এ connection encrypted নয়। তাই এটি tunnel-এর ভিতরে চালান এবং কখনো open Internet-এর মাধ্যমে ব্যবহার করবেন না। Encryption সরবরাহ করে tunnel-ই।

মেশিনগুলোর মালিকানা অনুযায়ী পদ্ধতি বেছে নিন। যেসব মেশিন আপনার মালিকানাধীন নয়, অথবা যেসব ব্যবহারকারী কখনো VPN client install করবেন না, সেগুলো support করলে self-hosted hbbs এবং hbbr উপযুক্ত। কারণ তাদের দিকের setup-এ শুধু একটি ID এবং password লাগে। যখন প্রতিটি মেশিন আপনার মালিকানাধীন এবং প্রতিটি মেশিনে একটি key ব্যবহার করা যায়, তখন mesh VPN এবং direct IP access উপযুক্ত। Tailscale-এর সঙ্গে WireGuard-এর তুলনা-এ এই mesh তৈরির দুটি প্রচলিত পদ্ধতি ব্যাখ্যা করা হয়েছে। আর Linux VPS-এ remote desktop চালানো অংশে সেই পরিস্থিতি ব্যাখ্যা করা হয়েছে, যেখানে screen-সহ যে মেশিনটি ব্যবহার করতে চান সেটিই server।

FAQ

প্রতিটি RustDesk session কি আমার relay-এর মাধ্যমে যায়?

না। hbbs প্রথমে দুইটি client-এর মধ্যে সরাসরি সংযোগ স্থাপনের চেষ্টা করে। এ জন্য প্রতিটি client-এর সামনে থাকা NAT-এর মধ্য দিয়ে hole punching ব্যবহার করা হয়। এই প্রচেষ্টা ব্যর্থ হলে শুধু সেই session-গুলো hbbr-এ fallback করে। শুধু এসব session-ই আপনার bandwidth ব্যবহার করে। ব্যতিক্রম হলো hbbs-এর ALWAYS_USE_RELAY=Y, যা সরাসরি path উপলভ্য থাকলেও প্রতিটি session-কে hbbr-এর মাধ্যমে পাঠায়। আপনার Compose file-এ এই variable সেট করা থাকলে প্রতিটি session-এর প্রতিটি byte আপনার data transfer bill-এ যুক্ত হবে।

RustDesk server key কোথায় সংরক্ষিত হয়, এবং এটি হারালে কী হবে?

প্রথমবার চালু হলে hbbs তার working directory-তে id_ed25519 এবং id_ed25519.pub তৈরি করে। Official image-এ ওই directory হলো /root। তাই উপরে দেখানো volume mount ব্যবহার করলে host-এ file দুটির অবস্থান হবে ./data। Server-এর বাইরে file দুটির backup রাখুন। এগুলো হারালে পরবর্তী start-এর সময় hbbs নতুন একটি key pair তৈরি করবে। পুরোনো public key সংরক্ষণকারী প্রতিটি client তখন প্রত্যাখ্যাত হবে। প্রতিটি client-এর Key field হাতে সম্পাদনা করা ছাড়া পুনরুদ্ধারের আর কোনো উপায় নেই।

Self-hosted RustDesk server-এর জন্য কোন port খুলতে হবে?

TCP 21115, 21116 এবং 21117, পাশাপাশি UDP 21116। NAT type test-এর জন্য hbbs port 21115 ব্যবহার করে। ID registration এবং UDP-এর মাধ্যমে heartbeat-এর জন্য এটি 21116 ব্যবহার করে। TCP-এর মাধ্যমে hole punching-এর জন্যও 21116 ব্যবহৃত হয়। Relay-এর জন্য hbbr port 21117 ব্যবহার করে। TCP 21118 এবং 21119 browser client-এর WebSocket port। এটি ব্যবহার না করলে port দুটির inbound access বন্ধ রাখুন। TCP 21114 Pro web console-এর জন্য ব্যবহৃত হয়; open source build-এ এটি প্রয়োজন হয় না।

অপরিচিত ব্যক্তি কি আমার self-hosted RustDesk relay ব্যবহার করতে পারে?

হ্যাঁ, যদি আপনি default configuration-সহ hbbr চালান। RustDesk documentation অনুযায়ী empty key থাকলে matching key ছাড়া client-ও relay ব্যবহার করতে পারে। তাই আপনার hostname এবং port 21117 জানা যে কেউ আপনার server-এর মাধ্যমে traffic পাঠাতে পারে। hbbs যে shared ./data volume-এ key pair তৈরি করেছে, সেখান থেকে একই key pair load করার জন্য hbbr-কে -k _-সহ চালান। এরপর শুধু আপনার public key দিয়ে configured client-ই আপনার server-এর মাধ্যমে relay করতে পারবে।