নিজের 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-এর data বহন করে, তবে শুধু সেই session-গুলোর জন্য যেগুলো সরাসরি একে অপরের সঙ্গে যোগাযোগ করতে পারেনি। অধিকাংশ guide উভয়টি install করে, client-গুলোকে pair করিয়ে সেখানেই থেমে যায়। পরের অংশে বাকি কাজগুলো দেখানো হয়েছে: access control হিসেবে ব্যবহৃত key, port, upgrade এবং bandwidth।

উভয় daemon একই image-এ থাকে, rustdesk/rustdesk-server, এবং নিচের setup-এ উভয়টি একই directory থেকে একই Ed25519 key pair পড়ে। এটি আপনাকে configure করতে হবে; এটি default নয়: hbbs নিজে pair load বা generate করে, কিন্তু hbbr-কে একটি key দিয়ে start না করলে এটি key ব্যবহার করে না। 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 সার্ভারের কোন port প্রয়োজন

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

• TCP 21115, hbbs-এ: NAT type পরীক্ষা।
• UDP 21116, hbbs-এ: ID registration এবং heartbeat। Client ডিফল্টভাবে এই পথ ব্যবহার করে।
• TCP 21116, hbbs-এ: শুধু TCP ব্যবহারের জন্য সেট করা client-এর ID registration, পাশাপাশি 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-এর HTTP API server। open source build এই port-এ listen করে না।

পিন করা image tag ব্যবহার করে 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-এর লাইন না থাকলে hbbs চলছে না, কারণ hbbs চালু হওয়ার সময় এই listener খোলে এবং ডিফল্টভাবে client-গুলো এই listener-এর মাধ্যমেই register করে।

ওই ফাইলে চারটি বিষয় ইচ্ছাকৃতভাবে নির্ধারণ করা হয়েছে। Tag হলো 1.1.16, যা October 2026 পর্যন্ত বর্তমান 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 চালানো ফাইলের 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 ছাড়াই client-রা relay ব্যবহার করতে পারে। নতুন ব্যবহারকারীরা যাতে প্রথমবার চালানোর সময় key mismatch-এ ব্যর্থ না হন, তাই এই খালি ডিফল্ট রাখা হয়েছে। এর খরচ হলো, TCP 21117-এ আপনার address যে কেউ খুঁজে পেলে আপনার VPS-এর মাধ্যমে, আপনার transfer allowance ব্যবহার করে এবং আপনার IP address থেকে তাদের session traffic পাঠাতে পারে।

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

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

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

এতে hbbr -k _ দেখানো উচিত। শুধু hbbr থাকলে directory-তে যা-ই থাকুক, relay এখনও উন্মুক্ত।

ক্লায়েন্টগুলোকে আপনার সার্ভারে নির্দেশ করুন

প্রতিটি মেশিনে RustDesk খুলুন, তারপর Settings, এরপর Network, এবং সবশেষে ID/Relay Server খুলুন।

• ID Server: আপনার hostname, যেমন rustdesk.example.com। অন্য port উল্লেখ না করলে ক্লায়েন্ট 21116 port ব্যবহার করে।
• Relay Server: hbbr যদি hbbs-এর একই host-এ চলে, তাহলে এটি খালি রাখুন।
• API Server: খালি রাখুন। open source server এটি প্রদান করে না।
• Key: id_ed25519.pub থেকে নেওয়া base64 string হুবহু paste করুন। শেষে কোনো space রাখবেন না।

এরপর main window-তে ক্লায়েন্টটি ready বলে দেখানো উচিত। তা না হলে এবং ক্লায়েন্টটি default settings-এ চললে, সাধারণ কারণ হলো UDP 21116-এর traffic hbbs-এ পৌঁছাচ্ছে না। কারণ default client এই port-এ register করে এবং heartbeat পাঠায়। তবে শুধু offline ID দেখে নিশ্চিত হওয়া যায় না। disable-udp option-এর মান Y সেট করা ক্লায়েন্ট TCP 21116-এর মাধ্যমে register করে এবং UDP 21116 কখনো ব্যবহার করে না। তাই ওই ক্লায়েন্টের ক্ষেত্রে প্রথমে TCP 21116 পরীক্ষা করুন।

পোর্ট সীমিত করুন, যাতে 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 সক্রিয় করার সময় একটি দ্বিতীয় SSH session খোলা রাখুন, যাতে SSH rule-এ ভুল হলেও নিজের server-এ প্রবেশাধিকার বন্ধ না হয়ে যায়। VPS-এর ufw firewall-এর মৌলিক বিষয়-এ default policy এবং rule-এর ক্রম ব্যাখ্যা করা হয়েছে।

এখন মূল ঝুঁকিটি দেখুন। আপনি যদি ports: block ব্যবহার করে port publish করেন, যা অনেক single container RustDesk উদাহরণে করা হয়, তাহলে Docker নিজস্ব DNAT rule লিখে। এর ফলে packet আপনার ufw rule থাকা chain অতিক্রম না করেই container-এ পৌঁছে যায়। তাই 21117-এ 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 স্থিতিশীল থাকে না। তাই এই ক্ষেত্রে hbbr-এর key firewall-এর চেয়ে বেশি কার্যকর ভূমিকা পালন করে।

আপনার 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 সেশন কি আমার relay-এর মধ্য দিয়ে যায়?

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

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

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

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

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

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

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