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। এখানে pixel data centre-এ render হয় এবং আপনার কাছে stream করা হয়। এর উদাহরণ হলো xrdp, VNC (virtual network computing) অথবা একটি container workspace।

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

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

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

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

একটি VPS server image-এ কোনো graphical desktop থাকে না। প্রথমে একটি desktop ইনস্টল করুন। এরপর xrdp ইনস্টল করুন। এটি একটি 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-কে নাম দিয়ে ইনস্টল করুন, যদিও এটি কেবল একটি recommended package। এটি সেই X server backend, যা নতুন session-এর জন্য xrdp চালু করে। এটি না থাকলে login box আপনার password গ্রহণ করার পর আবার সরাসরি login box-এ ফিরিয়ে দেয়।

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

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

সবশেষে, client-দের দেওয়া TLS (transport layer security) key পড়তে xrdp-এর অনুমতি প্রয়োজন। ফাইলটির 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 চালানোর পর groupগুলোর মধ্যে ssl-cert না দেখালে sudo adduser xrdp ssl-cert চালান। এরপর sudo systemctl restart xrdp চালান। এই ধাপ বাদ দিলে xrdp key খুলতে পারবে না। তখন /var/log/xrdp.log ওই line-এ snakeoil filename-সহ ব্যর্থতাটি record করবে।

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

ইন্টারনেটের সব ধরনের সিস্টেম ক্রমাগত TCP 3389 scan করে। RDP login box প্রতিটি password attempt-এর উত্তর দেয়। এটি খুলবেন না। পরিবর্তে xrdp-কে loopback address-এ bind করুন এবং আগে থেকেই trusted একটি 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। পরিবর্তনের পরে service 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-এ ইতিমধ্যে কোনো process 3389 ধরে রেখেছে। ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com ব্যবহার করে local end-এর port পরিবর্তন করুন এবং 127.0.0.1:13389-এ connect করুন।

প্রতি ব্যক্তির জন্য একটি করে tunnel ব্যবহার করা দ্রুত অসুবিধাজনক হয়ে যায়। তাই team-এর জন্য private network ভালো সমাধান। নিজে পরিচালিত WireGuard VPN-এর আড়ালে server-টি রাখুন, তাকে 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 usage-এর সাধারণ, rounded মান। এগুলো আপনার মেশিনে মাপা নয়; প্রকাশিত তুলনা থেকে নেওয়া। Connect করার পরপরই free -m ব্যবহার করে আপনার নিজের usage মাপুন।

[
  {
    "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 ব্যবহার করে। তাই 2 GB server-এ browser চালানোর জন্য উভয় ক্ষেত্রেই কিছু memory অবশিষ্ট থাকে। GNOME একটি window খোলার আগেই প্রায় 1,200 MB চায়। ফলে 2 GB server-এ বাকি memory নিয়ে browser-কে desktop-এর সঙ্গে প্রতিযোগিতা করতে হয়।

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

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

xrdp সেশনে শব্দ ও clipboard

Ubuntu 24.04 অডিওর জন্য PipeWire ব্যবহার করে, কিন্তু xrdp-এর sound redirection PulseAudio-কে ভিত্তি করে তৈরি। তাই fresh install-এ video কাজ করলেও শব্দ শোনা যায় না। Ubuntu এই সংযোগের জন্য bridge package দেয়।

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

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

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

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

xrdp-chansrv আপনার session-এর জন্য চলমান থাকলে text clipboard দুই দিকেই কাজ করে। xrdp এটি আপনার হয়ে চালু করে। pgrep -a xrdp-chansrv দিয়ে এটি নিশ্চিত করুন। Session চলাকালীন copy ও paste কাজ করা বন্ধ হলে ওই process বন্ধ হয়ে গেছে; reconnect করলে এটি আবার চালু হবে। 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 কেবল যে session-কে স্থানীয়ভাবে উপস্থিত বলে বিবেচনা করে, সেই session-এর জন্য ওই action-এর অনুমতি নীরবে দেয়। RDP session স্থানীয়ভাবে উপস্থিত হিসেবে গণ্য হয় না। তাই polkit আপনার কাছে password চায়। Ubuntu 24.04-এ polkit 124 রয়েছে। এই সংস্করণ পুরোনো local authority .pkla file সরিয়ে দিয়েছে। তাই 24.04-এ /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla লিখতে বলেছে এমন কোনো guide-এর কোনো প্রভাব নেই। এর পরিবর্তে একটি 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 server কী করে

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

এটি চালু করুন। এরপর 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 রাখুন।

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

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

যেসব পাঠক ইতিমধ্যে একটি reverse proxy-তে সবকিছুর TLS termination করেন, তারা সাধারণত এই পদ্ধতি চেষ্টা করে ব্যর্থ হন। hbbs এবং hbbr HTTP নয়; তারা TCP ও UDP-এর মাধ্যমে নিজেদের binary protocol ব্যবহার করে। রাউট করার জন্য কোনো 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-এর পেছনে রাখা যায়। এভাবে সেটআপ করলে firewall rule যোগ করুন, যাতে শুধু proxy 21118 এবং 21119-এ পৌঁছাতে পারে। কারণ websocket connection-এ প্রকৃত client address নির্ধারণ করতে hbbs X-Real-IP header-এর ওপর নির্ভর করে।

কনটেইনারে একটি অস্থায়ী browser

কখনও আপনার প্রয়োজন হয় এমন একটি পরিষ্কার browser, যার IP পরিবর্তন হয় না এবং যা আপনার নিজের machine থেকে আলাদা থাকে। কনটেইনার 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-এর তুলনায় এতে বেশি resource প্রয়োজন। August 2026 অনুযায়ী documentation-এ ন্যূনতম প্রয়োজন হিসেবে 2 CPU core, 4 GB memory এবং 50 GB SSD উল্লেখ করা হয়েছে। এর ওপর প্রতিটি user session-এর জন্য default হিসেবে আরও 2 core এবং 2768 MB বরাদ্দ থাকে। 2 GB plan-এ এটি চলবে না। Install করার জন্য একটি 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 নেই। একটি পরিস্থিতিতে এটি উপযোগী: আপনি এমন একটি desktop session চান, যা disconnect করার পরও চলতে থাকবে এবং ফিরে এলে একই 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-এ থাকে, যার ওপর আপনার সরাসরি নিয়ন্ত্রণ নেই। Heavy desktop ব্যবহার web server-এর জন্য নির্ধারিত monthly bandwidth allowance দ্রুত শেষ করে।

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

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

FAQ

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

হ্যাঁ, হালকা desktop ব্যবহার করলে পারেন। XFCE বা LXQt login-এর পরে প্রায় 300 থেকে 400 MB ব্যবহার করে, ফলে কয়েকটি tab-সহ browser চালানোর জন্য যথেষ্ট memory অবশিষ্ট থাকে। 2 GB memory-তে 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 করা হয়, এবং বাইরে উন্মুক্ত 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 দিয়ে সংযোগ করুন। এক বা দুইজনের বেশি ব্যবহারকারী থাকলে xrdp-কে loopback-এর পরিবর্তে WireGuard address-এ 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 সমাধানটি কোনো কাজ করে না, কারণ 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-এর ওপর আস্থা রাখে।

আমার 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 করুন, কারণ session শুরু হওয়ার সময় module load হয় এবং reconnect করলে এটি load হবে না। xrdp নামযুক্ত sink-এর জন্য pactl list short sinks দিয়ে পরীক্ষা করুন। Client যেন audio চায়, তা নিশ্চিত করুন। এটি xfreerdp3-এর /sound flag অথবা Windows client-এর "Remote audio" option।