Linux VPS-এ Remote Desktop চালানোর পদ্ধতি

Linux VPS-এ remote desktop বলতে আসলে কী বোঝায়

“Linux VPS-এ remote desktop” খুঁজলে সাধারণত দুই ধরনের product পাওয়া যায়। ভুলটি বেছে নিলে একটি বিকেল নষ্ট হতে পারে। প্রথমটি হলো remote-access broker। RustDesk-এর self-hosted server এর সাধারণ উদাহরণ। এটি আপনার মালিকানাধীন দুটি machine-এর মধ্যে session relay করে, যেমন আপনার laptop এবং বাড়ির PC। ভাড়া করা server-এ কোনো desktop চালু থাকে না। এটি দুই প্রান্তকে একে অপরের সঙ্গে পরিচয় করিয়ে দেয় এবং তারা সরাসরি একে অপরের কাছে পৌঁছাতে না পারলে packet forward করে। দ্বিতীয়টি হলো ভাড়া করা server-এ চলমান একটি বাস্তব graphical desktop। এই ক্ষেত্রে data centre-এ pixel তৈরি হয় এবং আপনার কাছে stream করা হয়। এর উদাহরণ হলো xrdp, VNC (virtual network computing) অথবা container workspace।

একটি প্রশ্ন এই দুই ধরনের ব্যবস্থাকে আলাদা করে। এটি কাজ করার পর mouse pointer কোথায় থাকে? আপনি যদি ইতিমধ্যে নিজের মালিকানাধীন কোনো machine-এ access করতে চান, তাহলে broker দরকার। VPS-এই যদি desktop চান, তাহলে VPS-এ desktop দরকার। নিচের আলোচনায় দ্বিতীয় ক্ষেত্রটিকে বেশি গুরুত্ব দেওয়া হয়েছে, কারণ অধিকাংশ guide এই ক্ষেত্রটি বাদ দেয়।

আপনার কাজের জন্য কোন বিকল্পটি উপযুক্ত

• নিজস্ব relay-সহ RustDesk। এটি session-কে অপরিচিত ব্যক্তিদের পরিচালিত public rendezvous server-এর মধ্য দিয়ে যেতে দেয় না, কারণ key pair আপনার নিয়ন্ত্রণে থাকে। এটি নিয়ন্ত্রিত machine-টিকে সুরক্ষিত করে না। আপনি যে PC-তে client install করেছেন, সেটি এবং সেই PC-র password যেমন আছে, তেমনই থাকে।
• SSH tunnel বা VPN-এর মাধ্যমে xrdp। এটি আপনাকে TCP 3389-এর বিরুদ্ধে চলমান Internet-wide scanning এবং RDP login box-এ password guessing থেকে সুরক্ষিত রাখে, কারণ ওই port কখনো Internet-এর দিকে উন্মুক্ত থাকে না। তবে tunnel-এ ইতিমধ্যে access থাকা কারও কাছ থেকে দুর্বল account password সুরক্ষিত থাকে না।
• একই tunnel-এর মাধ্যমে VNC। এটি এমন একটি desktop session দেয়, যা connection বিচ্ছিন্ন হলেও চালু থাকে। এখানে RDP-এর চেয়ে পুরোনো ও সরল protocol ব্যবহার করা হয়। একা ব্যবহার করলে এটি কোনো সুরক্ষা দেয় না। সব security কাজ tunnel-ই করে। তাই public port-এ একা VNC চালানো এই তালিকার সবচেয়ে খারাপ বিকল্প।
• Webtop বা Kasm-এর মতো container workspace। এটি এমন একটি container-এর মধ্যে browser বা সম্পূর্ণ desktop দেয়, যেটি আপনি মুছে ফেলে আবার তৈরি করতে পারেন। ফলে browser যে কাজই করুক, আপনার আসল machine সুরক্ষিত থাকে। তবে এটি host-কে সুরক্ষিত করে না। এই image-গুলো broad privilege নিয়ে চলে এবং এর ভেতরে password-বিহীন sudo থাকে। তাই hostile workload-এর ক্ষেত্রে container-কে নির্ভরযোগ্য boundary হিসেবে ব্যবহার করা উচিত নয়।

Ubuntu 24.04-এ xrdp এবং XFCE ইনস্টল করুন

একটি VPS server image-এ কোনো graphical desktop থাকে না। প্রথমে একটি desktop install করুন। এরপর xrdp install করুন। এটি একটি open-source server, যা RDP (remote desktop protocol) ব্যবহার করে। Windows client-ও একই protocol ব্যবহার করে। হালকা desktop বেছে নিন। সাধারণত XFCE-ই উপযুক্ত পছন্দ।

sudo apt update
sudo apt install -y xrdp xorgxrdp xfce4 xfce4-goodies dbus-x11
systemctl is-active xrdp

August 2026 অনুযায়ী Ubuntu 24.04-এর universe component-এ xrdp 0.9.24 এবং xorgxrdp রয়েছে। নাম দিয়ে xorgxrdp install করুন, যদিও এটি শুধু recommended package হিসেবে চিহ্নিত। এটি সেই X server backend, যা xrdp নতুন session-এর জন্য চালু করে। এটি না থাকলে login box আপনার password গ্রহণ করার পর আপনাকে সরাসরি আবার login box-এ ফিরিয়ে দেয়।

এখন session-কে কোন desktop চালু করতে হবে তা জানান। xrdp /etc/xrdp/startwm.sh চালায়। ওই file থাকলে এটি ~/.xsession চালায়।

echo "xfce4-session" > ~/.xsession
chmod 644 ~/.xsession

সবশেষে xrdp-কে client-দের জন্য দেওয়া TLS (transport layer security) key পড়তে হবে। ওই file-এর mode 640 এবং মালিকানা ssl-cert group-এর।

ls -l /etc/ssl/private/ssl-cert-snakeoil.key
id xrdp

Listing-এ -rw-r----- 1 root ssl-cert দেখা যায়। id xrdp চালিয়ে groups-এর মধ্যে ssl-cert না দেখালে sudo adduser xrdp ssl-cert চালিয়ে তারপর sudo systemctl restart xrdp চালান। এই ধাপ বাদ দিলে xrdp key-টি খুলতে পারবে না। তখন /var/log/xrdp.log ওই line-এ snakeoil filename-সহ failure record করবে।

ইন্টারনেটে port 3389 খোলা উচিত নয় কেন

Internet-এর সবকিছুই নিয়মিত TCP 3389 scan করে, এবং RDP login box প্রতিটি password attempt-এর উত্তর দেয়। এটি খুলবেন না। এর পরিবর্তে xrdp-কে loopback address-এ bind করুন এবং আগে থেকেই বিশ্বস্ত tunnel-এর মাধ্যমে এতে সংযোগ করুন।

/etc/xrdp/xrdp.ini সম্পাদনা করুন এবং [Globals] section-এ listener পরিবর্তন করুন।

[Globals]
port=tcp://.:3389

সিস্টেমে থাকা file-টির comment-এ এই syntax নথিভুক্ত আছে: tcp://.:3389 বলতে 127.0.0.1:3389 বোঝায়, আর tcp://:3389 বলতে প্রতিটি interface বোঝায়। Restart করে নিশ্চিত হন, কারণ এখানে typo থাকলে service নীরবে সব address-এ চালু থেকে যায়।

sudo systemctl restart xrdp
ss -tlnp | grep 3389

আপনার 127.0.0.1:3389 দেখা উচিত। 0.0.0.0:3389 দেখা গেলে xrdp আপনার পরিবর্তন উপেক্ষা করেছে। সাধারণত file-এর আরও নিচে থাকা অন্য section heading-এর অধীনে line চলে যাওয়ার কারণে এটি হয়।

এখন নিজের machine থেকে tunnel খুলুন।

ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com

-N বলতে “connection খুলুন, কিন্তু কোনো command চালাবেন না” বোঝায়। তাই session-টি শুধু port বহন করার জন্য চালু থাকে। ওই terminal চালু রাখুন এবং RDP client-কে 127.0.0.1:3389-এ নির্দেশ করুন। Linux client-এ software হলো FreeRDP 3। Ubuntu 24.04-এ এর binary-এর নাম xfreerdp3:

sudo apt install -y freerdp3-x11
xfreerdp3 /v:127.0.0.1:3389 /u:you /dynamic-resolution +clipboard /sound

Windows-এ built-in mstsc ব্যবহার করুন এবং computer হিসেবে 127.0.0.1 লিখুন। প্রথমবার connect করার সময় FreeRDP আপনাকে certificate trust করতে বলবে এবং Do you trust the above certificate? (Y/T/N) দেখাবে। self-signed snakeoil certificate ব্যবহারের ক্ষেত্রে এটি প্রত্যাশিত।

ssh bind [127.0.0.1]:3389: Address already in use উত্তর দিলে আপনার নিজের machine-এ কোনো কিছু ইতিমধ্যে 3389 দখল করে আছে। ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com ব্যবহার করে local end পরিবর্তন করুন এবং 127.0.0.1:13389-এ connect করুন।

প্রতিটি ব্যক্তির জন্য একটি করে tunnel ব্যবহার করা ক্লান্তিকর। তাই team-এর জন্য private network ব্যবহার করাই ভালো। একটি self-hosted WireGuard VPN-এর পেছনে machine-টি রাখুন, এর tunnel address হিসেবে 10.8.0.1 দিন, এবং port=tcp://10.8.0.1:3389 নির্ধারণ করুন যাতে xrdp শুধু VPN-এর ভেতর উত্তর দেয়। যেকোনো ক্ষেত্রেই 3389-এর firewall rule একেবারেই থাকা উচিত নয়। বর্তমান rule-গুলো কী অনুমতি দিচ্ছে তা নিশ্চিত না হলে VPS-এ ufw firewall-এর মৌলিক বিষয় থেকে শুরু করুন এবং connect করার আগে পরীক্ষা করুন, পরে নয়।

2 GB VPS-এ remote desktop কত RAM ব্যবহার করে

আপনি যে desktop বেছে নেবেন, সেটিই নির্ধারণ করবে 2 GB plan ব্যবহারযোগ্য হবে নাকি কার্যত অচল হয়ে যাবে। নিচের সংখ্যাগুলো Ubuntu 24.04-এ login করার ঠিক পর memory ব্যবহারের সাধারণ আনুমানিক মান। এগুলো আপনার মেশিনে মাপা নয়; প্রকাশিত তুলনা থেকে নেওয়া। সংযোগ করার পরপরই free -m ব্যবহার করে নিজের মেশিনের ব্যবহার মাপুন।

[
  {
    "label": "LXQt",
    "idle_ram_mb": 300
  },
  {
    "label": "XFCE",
    "idle_ram_mb": 400
  },
  {
    "label": "MATE",
    "idle_ram_mb": 500
  },
  {
    "label": "KDE Plasma",
    "idle_ram_mb": 800
  },
  {
    "label": "GNOME",
    "idle_ram_mb": "1,200"
  }
]

এই 5টি desktop-এর মধ্যে ব্যবহারের পার্থক্যই মূল বিষয়। LXQt প্রায় 300 MB এবং XFCE প্রায় 400 MB RAM ব্যবহার করে। তাই 2 GB server-এ browser চালানোর জন্য উভয় ক্ষেত্রেই কিছু RAM অবশিষ্ট থাকে। একটি window খোলার আগেই GNOME-এর প্রয়োজন হয় প্রায় 1,200 MB। ফলে 2 GB-এ অবশিষ্ট RAM-এর জন্য browser-কে desktop-এর সঙ্গে প্রতিযোগিতা করতে হয়।

আসল খরচ desktop shell নয়, browser। একটি আধুনিক browser প্রতি active tab-এ সাধারণত 150 থেকে 400 MB ব্যবহার করে। তাই XFCE-সহ 2 GB VPS কয়েকটি tab সামলানোর পর swapping শুরু করে। Process বন্ধ না করে মেশিনকে ধীর করার জন্য swap যোগ করুন: sudo fallocate -l 2G /swapfile, এরপর sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile চালান এবং reboot-এর পরেও swap সক্রিয় রাখতে /etc/fstab-এ একটি মিল থাকা line যোগ করুন। কোনো কিছু কোনো warning ছাড়াই বন্ধ হয়ে গেলে dmesg | grep -i "killed process" চালান। এর অর্থ kernel-এর out-of-memory killer সেটিকে বন্ধ করেছে। সাধারণত browser-ই এর শিকার হয়।

CPU-ও একটি সীমা, এবং এটি কম করে অনুমান করা সহজ। VPS-এ GPU থাকে না। তাই X llvmpipe-এর মাধ্যমে software rendering ব্যবহার করে, অর্থাৎ CPU-কে প্রতিটি pixel আঁকতে হয়। ভারী page scroll করা এবং video চালানো—উভয় ক্ষেত্রেই সাধারণ CPU load দেখা যায়। তখন মেশিন পুরোপুরি আটকে না গিয়ে frame rate কমে যায়। VPS-এ game চালানো যায় কি না জানতে চাইলে এটিই একই সীমা: 3D কাজের ক্ষেত্রে উত্তর হলো না, এবং কারণটিও ঠিক এটাই।

xrdp সেশনে শব্দ ও ক্লিপবোর্ড

Ubuntu 24.04 অডিওর জন্য PipeWire ব্যবহার করে, কিন্তু xrdp-এর sound redirection PulseAudio-কে লক্ষ্য করে লেখা হয়েছে। তাই নতুন ইনস্টলেশনে ভিডিও কাজ করলেও শব্দ থাকে না। Ubuntu-এর প্যাকেজগুলো এই bridge সরবরাহ করে।

sudo apt install -y pipewire-module-xrdp pulseaudio-utils alsa-utils

RDP session থেকে সম্পূর্ণভাবে log out করে আবার log in করুন, কারণ session শুরু হওয়ার সময় module-টি load হয়। শুধু reconnect করলে যথেষ্ট নয়। এরপর session-এর ভেতর থেকে পরীক্ষা করুন:

pactl list short sinks
speaker-test -c 2 -t wav -l 1

আপনার একটি sink দেখা উচিত, যার নামের মধ্যে xrdp আছে। আপনার client-এর মাধ্যমে test tone-ও শোনা উচিত। xrdp sink না থাকলে module-টি এই session-এ load হয়নি। আপনার client-কে অডিও ব্যবহারের অনুরোধও করতে হবে। Windows client-এ এটি হলো /sound-এর xfreerdp3 flag, অথবা Local Resources-এর অধীনে "Remote audio" setting।

xrdp-chansrv আপনার session-এর জন্য চলমান থাকলে text clipboard উভয় দিকেই কাজ করে। xrdp এটি আপনার হয়ে start করে। pgrep -a xrdp-chansrv দিয়ে এটি নিশ্চিত করুন। session চলাকালে copy ও paste কাজ করা বন্ধ হলে ওই process-টি বন্ধ হয়ে গেছে। Reconnect করলে এটি আবার start হয়। Text-এর পরিবর্তে file copy করা আলাদা channel-এর মাধ্যমে হয়, যাকে drive redirection বলা হয়। xfreerdp3-এ /drive:home,/home/you একটি local folder-কে remote session-এর মধ্যে mount করে।

polkit পপআপ এবং প্রথম লগইনের অন্যান্য ব্যর্থতা

প্রথম লগইনের সময় সবচেয়ে সাধারণ বিস্ময় হলো Authentication is required to create a color managed device লেখা একটি ডায়ালগ। এর কারণ নির্দিষ্ট। colord service অনুমতির জন্য polkit-এর কাছে অনুরোধ করে। polkit নীরবে সেই action-এর অনুমতি দেয় শুধু যে session-কে সে locally seated হিসেবে বিবেচনা করে। RDP session seated নয়। তাই polkit আপনার কাছে password চাওয়ার fallback আচরণ করে। Ubuntu 24.04-এ polkit 124 সরবরাহ করা হয়েছে। এই সংস্করণ পুরোনো local authority .pkla files সরিয়ে দিয়েছে। তাই /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla লেখার নির্দেশনা দেওয়া সব guide-এর কোনো প্রভাবই 24.04-এ নেই। এর পরিবর্তে একটি JavaScript rule লিখুন।

/* /etc/polkit-1/rules.d/45-allow-colord.rules */
polkit.addRule(function(action, subject) {
    if (action.id.indexOf("org.freedesktop.color-manager.") === 0 &&
        subject.isInGroup("sudo")) {
        return polkit.Result.YES;
    }
});

sudo systemctl restart polkit চালিয়ে আবার সংযোগ করুন। আরও দুটি ব্যর্থতা তাদের লক্ষণ দেখে শনাক্ত করা যায়।

Login box আপনার password গ্রহণ করে সঙ্গে সঙ্গে আবার ফিরে আসে। Session শুরু হয়ে বন্ধ হয়ে গেছে। প্রথমে /var/log/xrdp-sesman.log পড়ুন। এরপর আপনার home directory-তে ~/.xsession-errors পড়ুন। xorgxrdp না থাকা, ইনস্টল করা নেই এমন desktop-এর নাম উল্লেখ করা ~/.xsession, যে home directory-তে আপনি লিখতে পারেন না, অথবা disk পূর্ণ হয়ে যাওয়া—সব ক্ষেত্রেই সমস্যা এখানে প্রকাশ পায়।

আপনি সংযোগ করে X cursor-সহ একটি ধূসর screen দেখেন। X শুরু হয়েছে, কিন্তু desktop শুরু হয়নি। এটিও আবার ~/.xsession-এর সমস্যা। SSH-এর মাধ্যমে হাতে করে xfce4-session চালান এবং এটি যে error দেখায় তা পড়ুন।

self-hosted RustDesk সার্ভার কী করে

RustDesk দুটি process-এ বিভক্ত। hbbs হলো ID ও rendezvous server, যেখানে client-গুলো register করে। hbbr হলো relay, যা সরাসরি peer-to-peer connection ব্যর্থ হলে session-এর network traffic বহন করে। কোনোটিই desktop চালায় না। দুটিই একটি image থেকে আসে। নিচে project-এর প্রকাশিত compose file দেওয়া হলো, যেখানে relay address আপনার নিজের host name-এ পরিবর্তন করা হয়েছে:

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r rustdesk.example.com:21117
    ports:
      - 21115:21115
      - 21116:21116
      - 21116:21116/udp
      - 21118:21118
    volumes:
      - ./data:/root
    restart: unless-stopped
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - 21117:21117
      - 21119:21119
    volumes:
      - ./data:/root
    restart: unless-stopped

এটি চালু করুন। এরপর প্রথমবার start হওয়ার সময় server যে public key তৈরি করেছে, তা পড়ুন:

sudo docker compose up -d
sudo cat ./data/id_ed25519.pub

প্রতিটি client-এ আপনার host name এবং ওই public key প্রয়োজন। RustDesk client-এর Network settings-এ দুটিই লিখুন। সংশ্লিষ্ট private key ./data/id_ed25519-এ থাকে। data directory মুছে ফেললে server নতুন key pair তৈরি করবে। তখন প্রতিটি client-এ নতুন key দিয়ে আবার configuration করতে হবে। ওই directory-এর backup রাখুন। এটি যদি weekend experiment-এর বদলে আপনার team-এর প্রতিটি machine-এ access করার নিয়মিত পদ্ধতি হয়ে ওঠে, তাহলে RustDesk relay-এর dedicated build অনুসরণ করা উপযোগী। এতে Ed25519 key handling, latest-এর বদলে pinned image tags এবং আপনার plan অনুযায়ী relay bandwidth-এর খরচ বিবেচনা করা যায়।

Firewall-এ এই port-গুলোতে সরাসরি traffic অনুমোদন করতে হবে। hbbs TCP 21115, 21116 এবং 21118, পাশাপাশি UDP 21116 ব্যবহার করে। hbbr TCP 21117 এবং 21119 ব্যবহার করে।

sudo ufw allow 21115/tcp
sudo ufw allow 21116/tcp
sudo ufw allow 21116/udp
sudo ufw allow 21117/tcp
sudo ufw allow 21118/tcp
sudo ufw allow 21119/tcp

nginx বা Traefik-এর পেছনে RustDesk কেন কাজ করবে না

যেসব পাঠক ইতিমধ্যে একটি reverse proxy-তে সবকিছুর TLS termination করেন, তারা সাধারণত এই পদ্ধতি ব্যবহার করে ব্যর্থ হন। hbbs এবং hbbr HTTP নয়; এগুলো TCP ও UDP-এর ওপর নিজস্ব binary protocol ব্যবহার করে। routing করার জন্য কোনো Host header নেই এবং পরীক্ষা করার মতো কোনো HTTP request-ও নেই। তাই nginx-এর server block বা Traefik HTTP router-এর match করার মতো কিছু থাকে না। 21116 port-এর UDP listener কোনো স্তরেই HTTP নয়।

দুটি পদ্ধতি কাজ করে। nginx stream block ব্যবহার করে TCP port forward করতে পারে। এটি সাধারণ অর্থে reverse proxy নয়; এটি সরাসরি layer 4 forwarding। অন্যদিকে, 21118 এবং 21119 port-এ RustDesk web client ব্যবহৃত websocket চলে। এটি সাধারণ HTTP, তাই এই দুটি port আপনার proxy-এর পেছনে রাখা যায়। এভাবে configure করলে firewall rule যোগ করুন, যাতে শুধু proxy 21118 এবং 21119-এ পৌঁছাতে পারে। কারণ websocket connection-এ আসল client address নির্ধারণের জন্য hbbs X-Real-IP header-এর ওপর নির্ভর করে।

একটি কনটেইনারে disposable browser

কখনও আপনার প্রয়োজন হয় এমন একটি পরিষ্কার browser, যার IP পরিবর্তিত হয় না এবং যা আপনার নিজের মেশিন থেকে আলাদা রাখা থাকে। কনটেইনার workspace অনেক কম software install করেই এই সুবিধা দেয়। LinuxServer-এর Webtop হলো হালকা বিকল্প:

services:
  webtop:
    image: lscr.io/linuxserver/webtop:latest
    container_name: webtop
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - /path/to/data:/config
    ports:
      - 127.0.0.1:3000:3000
      - 127.0.0.1:3001:3001
    shm_size: "1gb"
    restart: unless-stopped

Port 3000 HTTP পরিবেশন করে এবং 3001 HTTPS পরিবেশন করে। কোনো RDP client ছাড়াই browser tab-এ desktop খোলা যায়। Image tag-গুলো বিভিন্ন base distribution-এ XFCE, KDE, MATE এবং i3 সমর্থন করে। প্রকল্পটির নিজস্ব documentation ঝুঁকিটি স্পষ্টভাবে উল্লেখ করে: কনটেইনারটির host-এ privileged access থাকে এবং এতে password ছাড়াই sudo চালানোর সুবিধাসহ একটি terminal থাকে। তাই সুরক্ষা ছাড়া এটিকে Internet-এর মুখোমুখি করা উচিত নয়। এই কারণেই উপরের port-গুলো সব address-এ publish না করে 127.0.0.1-এ bind করা হয়েছে। xrdp-এর জন্য যে SSH tunnel বা VPN ব্যবহার করেছেন, একই উপায়ে এটিতে পৌঁছান।

Kasm Workspaces একই ধারণার অনেক বড় রূপ। এতে web console, user account এবং session শেষ হলে reset হওয়া per-session container থাকে। ছোট VPS-এর তুলনায় এতে বেশি machine resource প্রয়োজন। August 2026 অনুযায়ী documentation-এ ন্যূনতম প্রয়োজন হিসেবে 2 CPU core, 4 GB memory এবং 50 GB SSD উল্লেখ করা হয়েছে। এর সঙ্গে প্রতিটি user session-এর জন্য default হিসেবে আরও 2 core এবং 2768 MB নির্ধারিত থাকে। 2 GB plan-এ এটি চলবে না। Installation-এর জন্য একটি download এবং একটি script যথেষ্ট:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.17.0.7f020d.tar.gz
tar -xf kasm_release_1.17.0.7f020d.tar.gz
sudo bash kasm_release/install.sh

VNC এবং যেখানে এটি এখনও উপযোগী

VNC drawing command পাঠানোর বদলে framebuffer update পাঠায়। তাই ধীর সংযোগে এটি RDP-এর চেয়ে বেশি ভারী মনে হয়। এতে sound channel-ও নেই। একটি নির্দিষ্ট পরিস্থিতিতে এটি উপযোগী: আপনি চান disconnect করার পরেও desktop session চলতে থাকুক এবং ফিরে এলে একই session আবার পেতে চান। TigerVNC এটি করতে পারে। vncserver -localhost yes :1 Xvnc-কে TCP 5901-এর উপর 127.0.0.1-এ bind করে এবং অন্য কোনো স্থান থেকে আসা connection প্রত্যাখ্যান করে। তাই ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com ব্যবহার করে এটিকে xrdp-এর মতো tunnel করুন। কখনও VNC port public করবেন না। অধিকাংশ VNC server handshake চলাকালীন password সুরক্ষিত রাখে, কিন্তু এরপর আর কিছু সুরক্ষিত করে না। তাই public port ব্যবহার করলে session-এর বিষয়বস্তু network wire-এ পড়া যায়।

VPS কি ভালো desktop?

দৈনন্দিন ব্যবহারের জন্য নয়। এর কারণ একাধিক। GPU নেই, তাই CPU-কেই সবকিছু render করতে হয়। প্রতিটি keystroke-এর জন্য network round trip অপেক্ষা করতে হয়। SSH-এ 40 ms latency স্বাভাবিক মনে হলেও text editor-এ তা বোঝা যায়। Video দুবার compress হয়—একবার site, আরেকবার RDP encoder। আপনার file এমন একটি disk-এ থাকে, যেটি আপনার নিয়ন্ত্রণে নেই। ভারী desktop ব্যবহার web server-এর জন্য নির্ধারিত monthly bandwidth allowance দ্রুত শেষ করে।

তবে অস্থায়ী machine হিসেবে এটি খুব ভালো। একই বৈশিষ্ট্যগুলিই এর কারণ। IP address স্থির এবং data centre-এর সঙ্গে যুক্ত। কোনো service-এর consistent address প্রয়োজন হলে এটিই উপযোগী। Machine কয়েক মিনিটে image থেকে rebuild করা যায়। তাই কোনো session-এ ক্ষতিকর কিছু ঢুকে গেলে তার খরচ থাকে না। এটি আপনার প্রকৃত hardware থেকে isolated থাকে। Laptop বন্ধ থাকলেও এটি চলতে থাকে। Hourly billing-এর কারণে ফেলে দেওয়ার মতো desktop সস্তা।

আপনি যদি এখনও নির্ধারণ করে থাকেন box-টি কী কাজে ব্যবহার করবেন, desktop install করার আগে VPS কোন কাজে ভালো তার ব্যবহারিক তালিকা পড়ে নেওয়া উপযোগী। আর desktop চাওয়ার কারণ যদি একটি Windows application হয়, তাহলে আগে Linux এবং Windows Server-এর প্রকৃত পার্থক্য বিবেচনা করুন। কারণ licence-এর ওপর সমাধানের খরচ বদলে যায়।

FAQ

আমি কি 2 GB VPS-এ remote desktop চালাতে পারি?

হ্যাঁ, হালকা desktop ব্যবহার করলে। Login করার পর XFCE বা LXQt আনুমানিক 300 থেকে 400 MB ব্যবহার করে, ফলে কয়েকটি tab-সহ একটি browser চালানোর মতো memory অবশিষ্ট থাকে। 2 GB RAM-এ GNOME বা KDE Plasma চালালে application-এর জন্য প্রায় কোনো memory অবশিষ্ট থাকে না। একটি 2 GB swap file যোগ করুন, যাতে memory pressure process বন্ধ না করে machine-কে ধীর করে। কোনো কিছু কোনো message ছাড়াই অদৃশ্য হয়ে গেলে kernel out-of-memory killer-এর জন্য dmesg | grep -i "killed process" পরীক্ষা করুন।

আমার VPS firewall-এ কি port 3389 খুলব?

না। TCP 3389 নিয়মিত scan করা হয়, এবং exposed RDP login box password guessing-এর সুযোগ তৈরি করে। /etc/xrdp/xrdp.ini-এ port=tcp://.:3389 সেট করুন, যাতে xrdp শুধু 127.0.0.1-এ listen করে। ss -tlnp | grep 3389 দিয়ে সেটিংটি নিশ্চিত করুন এবং ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com দিয়ে সংযোগ করুন। এক বা দুইজনের বেশি ব্যবহারকারী থাকলে loopback-এর পরিবর্তে WireGuard address-এ xrdp bind করুন।

xrdp কেন "Authentication is required to create a color managed device" বার্তা দেখায়?

colord service permission-এর জন্য polkit-কে অনুরোধ করে, আর polkit শুধু locally seated session-কে সেই action-এর অনুমতি নীরবে দেয়। RDP session seated নয়, তাই প্রতিটি login-এ password prompt দেখা যায়। Ubuntu 24.04-এ পুরোনো .pkla fix কোনো কাজ করে না, কারণ polkit 124 local authority file বাদ দিয়েছে। /etc/polkit-1/rules.d/45-allow-colord.rules তৈরি করে তাতে এমন একটি JavaScript rule রাখুন, যা org.freedesktop.color-manager. দিয়ে শুরু হওয়া action id-এর জন্য polkit.Result.YES ফেরত দেয়। এরপর sudo systemctl restart polkit চালান।

আমি কি self-hosted RustDesk server-কে nginx বা Traefik-এর পিছনে রাখতে পারি?

মূল service-কে নয়। hbbs এবং hbbr HTTP-এর পরিবর্তে নিজেদের binary protocol ব্যবহার করে। তাই routing করার জন্য কোনো Host header নেই, এবং UDP 21116 কোনো HTTP proxy পার হতে পারে না। Firewall-এ TCP 21115 থেকে 21119 এবং UDP 21116 খুলে দিন, যাতে client সরাসরি সংযোগ করতে পারে। Web client ব্যবহৃত websocket port 21118 এবং 21119 HTTP, তাই এগুলো proxy-এর পিছনে রাখা যায়। এমন করলে firewall-এ এগুলো কেবল proxy-এর জন্য উন্মুক্ত রাখুন, কারণ ওই connection-গুলোতে hbbs X-Real-IP-এর ওপর trust করে।

আমার xrdp session-এ sound নেই কেন?

Ubuntu 24.04-এ PipeWire ব্যবহার করা হয়, আর xrdp-এর sound redirection PulseAudio-এর জন্য তৈরি। তাই bridge install না করা পর্যন্ত audio পাওয়া যায় না। sudo apt install -y pipewire-module-xrdp চালান। এরপর session থেকে সম্পূর্ণ log out করে আবার log in করুন, কারণ module session শুরু হওয়ার সময় load হয় এবং reconnect করলে এটি load হয় না। xrdp নামযুক্ত sink আছে কি না, তা pactl list short sinks দিয়ে পরীক্ষা করুন। Client যেন audio request করে, সেটিও নিশ্চিত করুন। এটি xfreerdp3-এ /sound flag, অথবা Windows client-এ "Remote audio"।