Linux VPSలో xrdp, XFCEతో remote desktop ఎలా నడపాలి

Linux VPSలో remote desktop అంటే వాస్తవంగా ఏమిటి

"Linux VPSలో remote desktop" కోసం శోధించినప్పుడు రెండు వేర్వేరు ఉత్పత్తులు కనిపిస్తాయి. తప్పు ఉత్పత్తిని ఎంచుకుంటే మీ సమయం వృథా అవుతుంది. మొదటిది remote-access broker. RustDesk యొక్క self-hosted server దీనికి సాధారణ ఉదాహరణ. ఇది మీకు ఇప్పటికే చెందిన రెండు యంత్రాల మధ్య sessionను relay చేస్తుంది. ఉదాహరణకు, మీ laptop మరియు ఇంటి PC మధ్య. అద్దెకు తీసుకున్న serverలో ఎలాంటి desktop నడవదు. ఇది రెండు endpointsను పరస్పరం పరిచయం చేసి, అవి నేరుగా చేరుకోలేనప్పుడు packetsను forward చేస్తుంది. రెండవది అద్దెకు తీసుకున్న serverపైనే నడిచే నిజమైన graphical desktop. ఇందులో pixels data centreలో render అవుతాయి, తరువాత మీకు stream అవుతాయి. దీనికి xrdp, VNC (virtual network computing), లేదా container workspace ఉపయోగించవచ్చు.

వాటిని వేరు చేసే ఒక ప్రశ్న ఉంది. ఇది పనిచేసిన తరువాత mouse pointer ఎక్కడ ఉంటుంది? మీకు ఇప్పటికే చెందిన యంత్రంలో ఉంటే broker కావాలి. VPSపైనే ఉంటే VPSలో desktop కావాలి. దిగువ భాగంలో ఎక్కువ వివరణ రెండవ సందర్భానికే ఉంటుంది, ఎందుకంటే చాలా guides ఈ సందర్భాన్ని వదిలివేస్తాయి.

మీ పని కోసం సరైన ఎంపిక

• మీ స్వంత relay తో RustDesk. అపరిచితులు నిర్వహించే public rendezvous server ద్వారా session వెళ్లకుండా ఇది రక్షిస్తుంది, ఎందుకంటే key pair మీ నియంత్రణలో ఉంటుంది. ఇది నియంత్రించబడుతున్న machine ను రక్షించదు. మీరు client install చేసిన అదే PC, దానిలో ఉన్న అదే password తో కొనసాగుతుంది.
• SSH tunnel లేదా VPN పై xrdp. TCP 3389 పై ప్రపంచవ్యాప్తంగా నిరంతరం జరిగే internet scanning నుంచి, RDP login box పై password guessing నుంచి ఇది రక్షిస్తుంది, ఎందుకంటే ఆ port internet కు ఎప్పుడూ కనిపించదు. Tunnel ఇప్పటికే అందుబాటులో ఉన్న వ్యక్తి నుంచి బలహీనమైన account password ను ఇది రక్షించదు.
• అదే tunnel పై VNC. RDP కంటే పాతది, సరళమైన protocol ఉపయోగించి, disconnection తర్వాత కూడా కొనసాగగల desktop session ను ఇది అందిస్తుంది. స్వతంత్రంగా ఇది ఏదీ రక్షించదు. మొత్తం security పని tunnel చేస్తుంది. అందువల్ల public port పై మాత్రమే VNC నడపడం ఇక్కడి అత్యంత చెడు ఎంపిక.
• Webtop లేదా Kasm వంటి container workspace. మీరు తొలగించి మళ్లీ నిర్మించగల container లో browser లేదా పూర్తి desktop ను ఇది అందిస్తుంది. అందువల్ల ఆ browser తాకే వాటి నుంచి మీ నిజమైన machine రక్షించబడుతుంది. ఇది host ను రక్షించదు. ఈ images విస్తృత privileges తో, password లేకుండా sudo లో నడుస్తాయి. కాబట్టి hostile workload కు container ను నమ్మదగిన boundary గా పరిగణించకూడదు.

Ubuntu 24.04లో xrdp మరియు XFCE ఇన్‌స్టాల్ చేయండి

VPS సర్వర్ ఇమేజ్‌లో graphical desktop ఉండదు. ముందుగా ఒక desktopను ఇన్‌స్టాల్ చేయాలి. తరువాత RDP (remote desktop protocol)లో కమ్యూనికేట్ చేసే open-source server అయిన xrdpను ఇన్‌స్టాల్ చేయాలి. 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 మాత్రమే అయినప్పటికీ దాని పేరుతోనే ఇన్‌స్టాల్ చేయండి. కొత్త session కోసం xrdp ప్రారంభించే X server backend అదే. ఇది లేకపోతే login box మీ passwordను అంగీకరించిన తరువాత మళ్లీ login boxకే తీసుకెళ్తుంది.

ఇప్పుడు ప్రారంభించాల్సిన desktopను sessionకు తెలియజేయండి. xrdp /etc/xrdp/startwm.shను అమలు చేస్తుంది. ఆ ఫైల్ ఉన్నప్పుడు అది ~/.xsessionను అమలు చేస్తుంది.

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

చివరగా, clientsకు అందించే 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 groupsలో ssl-certను చూపించకపోతే, sudo adduser xrdp ssl-certను అమలు చేసి తరువాత sudo systemctl restart xrdpను అమలు చేయండి. ఈ దశను వదిలేస్తే xrdp keyను తెరవలేడు. /var/log/xrdp.log ఆ వైఫల్యాన్ని snakeoil filenameతో ఉన్న lineలో నమోదు చేస్తుంది.

ఇంటర్నెట్‌కు port 3389 ను ఎందుకు తెరవకూడదు

ఇంటర్నెట్‌లోని ప్రతి వ్యవస్థ TCP 3389 ను నిరంతరం scan చేస్తుంది. RDP login box ప్రతి password ప్రయత్నానికి స్పందిస్తుంది. దీన్ని తెరవకండి. బదులుగా xrdp ను loopback address కు bind చేసి, మీరు ఇప్పటికే విశ్వసించే tunnel ద్వారా దాన్ని చేరుకోండి.

/etc/xrdp/xrdp.ini ను సవరించి, [Globals] section లో listener ను మార్చండి.

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

ఆ syntax ను shipped file తన comments లోనే వివరిస్తుంది: tcp://.:3389 అంటే 127.0.0.1:3389, tcp://:3389 అంటే ప్రతి interface. Restart చేసి నిర్ధారించండి. ఇక్కడ typo ఉంటే service అన్ని addresses పై listening చేస్తూనే ఉంటుంది, కానీ అది స్పష్టంగా కనిపించకపోవచ్చు.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

మీకు కావాల్సింది 127.0.0.1:3389. 0.0.0.0:3389 కనిపిస్తే xrdp మీ edit ను పట్టించుకోలేదని అర్థం. సాధారణంగా 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 కు point చేయండి. 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 ఉపయోగిస్తున్నప్పుడు ఇది expected.

ssh bind [127.0.0.1]:3389: Address already in use అని స్పందిస్తే, మీ స్వంత machine లో ఇప్పటికే ఏదో ఒకటి 3389 ను ఉపయోగిస్తోంది. local end ను ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com కు మార్చి, 127.0.0.1:13389 కు connect చేయండి.

ప్రతి వ్యక్తికి ఒక tunnel నిర్వహించడం ఇబ్బందికరంగా మారుతుంది. అందువల్ల team కోసం private network మెరుగైన పరిష్కారం. box ను self-hosted WireGuard VPN వెనుక ఉంచి, దానికి tunnel address 10.8.0.1 ఇవ్వండి. తరువాత xrdp VPN లోపల మాత్రమే స్పందించేలా port=tcp://10.8.0.1:3389 ను set చేయండి. ఏ పద్ధతి ఎంచుకున్నా, 3389 కోసం firewall rule అసలు ఉండకూడదు. మీ ప్రస్తుత rules ఏమి allow చేస్తున్నాయో తెలియకపోతే, VPS లో ufw firewall ప్రాథమికాలు నుంచి ప్రారంభించి connect చేసే ముందు తనిఖీ చేయండి, తరువాత కాదు.

2 GB VPSలో remote desktop ఎంత RAM ఉపయోగిస్తుంది

మీరు ఎంచుకునే desktop వల్ల 2 GB plan సౌకర్యవంతంగా ఉంటుందా లేదా పూర్తిగా సరిపోదా అనేది నిర్ణయించబడుతుంది. కింది సంఖ్యలు Ubuntu 24.04లో login చేసిన వెంటనే ఉపయోగంలో ఉండే memoryకి సంబంధించిన సాధారణ, rounded విలువలు. ఇవి మీ machineలో కొలిచినవి కాకుండా ప్రచురించిన comparisons ఆధారంగా తీసుకున్నవి. Connect అయిన వెంటనే free -m ఉపయోగించి మీ machineలోనే కొలవండి.

[
  {
    "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 desktops మధ్య ఉన్న తేడానే ముఖ్యమైన విషయం. LXQt దాదాపు 300 MB వద్ద, XFCE దాదాపు 400 MB వద్ద ఉంటుంది. అందువల్ల రెండింటిలోనూ 2 GB machineలో browserకు కొంత memory మిగులుతుంది. ఒక్క window కూడా తెరవకముందే GNOMEకు సుమారు 1,200 MB అవసరం. కాబట్టి 2 GBలో మిగిలిన memory కోసం browser మరియు desktop పోటీ పడతాయి.

నిజమైన ఖర్చు desktop shellది కాదు, browserదే. ఆధునిక browser ప్రతి active tabకు సాధారణంగా 150 నుంచి 400 MB వరకు ఉపయోగిస్తుంది. అందువల్ల XFCE నడుస్తున్న 2 GB VPS కొన్ని tabsను మాత్రమే నిర్వహించి, తరువాత swapping ప్రారంభిస్తుంది. Processలను terminate చేయడానికి బదులుగా machine నెమ్మదించేందుకు swap జోడించండి: sudo fallocate -l 2G /swapfile, తరువాత sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile అమలు చేయండి. Reboot తర్వాత కూడా ఇది అందుబాటులో ఉండేందుకు /etc/fstabలో సరిపోలే line జోడించండి. ఏదైనా warning లేకుండా అదృశ్యమైతే dmesg | grep -i "killed process" అమలు చేయండి. ఆ line kernel యొక్క out-of-memory killer దాన్ని terminate చేసిందని సూచిస్తుంది. సాధారణంగా victim browser అవుతుంది.

CPU మరో పరిమితి. దీన్ని తక్కువగా అంచనా వేయడం సులభం. VPSలో GPU ఉండదు. అందువల్ల X, llvmpipe ద్వారా software renderingకు మారుతుంది. ప్రతి pixelను CPU render చేయాల్సి ఉంటుంది. భారమైన pageను scroll చేయడం మరియు video play చేయడం రెండూ సాధారణ CPU loadగా కనిపిస్తాయి. Machine freeze కాకుండా frame rate తగ్గుతుంది. VPSలో gaming చేయవచ్చా అని మీరు ఆలోచించినప్పుడు ఎదురయ్యే పరిమితి ఇదే. 3D పనులకు సమాధానం లేదు. కారణం కూడా ఇదే.

xrdp session లో ధ్వని మరియు clipboard

Ubuntu 24.04 ఆడియో కోసం PipeWire ను ఉపయోగిస్తుంది. అయితే xrdp యొక్క sound redirection, PulseAudio ఆధారంగా రూపొందించబడింది. అందువల్ల కొత్త install లో video పనిచేసినా ధ్వని వినిపించదు. Ubuntu ఈ రెండింటి మధ్య bridge ను package గా అందిస్తుంది.

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

RDP session నుంచి పూర్తిగా log out చేసి, మళ్లీ log in చేయండి. Module session ప్రారంభమైనప్పుడు load అవుతుంది. కేవలం reconnect చేయడం సరిపోదు. తరువాత session లోపల ఈ విధంగా తనిఖీ చేయండి:

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

పేరు xrdp ను సూచించే sink కనిపించాలి. Test tone మీ client ద్వారా వినిపించాలి. xrdp sink కనిపించకపోతే module ఈ session లో load కాలేదు. మీ client కూడా audio కోసం అభ్యర్థన పంపాలి. దీనికి /sound లోని xfreerdp3 flag లేదా Windows client లోని Local Resources కింద ఉన్న "Remote audio" setting ఉపయోగించాలి.

మీ session కోసం xrdp-chansrv నడుస్తున్నప్పుడు text clipboard రెండు దిశల్లో పనిచేస్తుంది. xrdp దీన్ని మీ కోసం ప్రారంభిస్తుంది. pgrep -a xrdp-chansrv తో దీన్ని నిర్ధారించండి. Session మధ్యలో copy and paste పనిచేయడం ఆగిపోతే, ఆ process ముగిసిందని అర్థం. Reconnect చేయడం ద్వారా అది మళ్లీ ప్రారంభమవుతుంది. Text కు బదులుగా files ను copy చేయడం ప్రత్యేక channel అయిన drive redirection ద్వారా జరుగుతుంది: xfreerdp3 పై /drive:home,/home/you local folder ను remote session లో mount చేస్తుంది.

polkit popup మరియు మొదటి login సమయంలో ఎదురయ్యే ఇతర వైఫల్యాలు

మొదటి login సమయంలో సాధారణంగా ఎదురయ్యే ఆశ్చర్యం Authentication is required to create a color managed device అనే సందేశం చూపించే dialog. దీనికి నిర్దిష్ట కారణం ఉంది. colord service అనుమతి కోసం polkit ను అడుగుతుంది. locally seated session గా polkit పరిగణించే session కు మాత్రమే ఆ చర్యకు అనుమతిని నిశ్శబ్దంగా ఇస్తుంది. RDP session seated గా పరిగణించబడదు. అందువల్ల polkit మీ password ను అడుగుతుంది. 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 ను అమలు చేసి మళ్లీ connect అవ్వండి. లక్షణాల ఆధారంగా గుర్తించగల మరో రెండు వైఫల్యాలు ఉన్నాయి.

login box మీ password ను స్వీకరించి వెంటనే మళ్లీ అదే login box ను చూపిస్తుంది. session ప్రారంభమై ఆగిపోయింది. ముందుగా /var/log/xrdp-sesman.log ను పరిశీలించండి. తరువాత మీ home directory లోని ~/.xsession-errors ను పరిశీలించండి. xorgxrdp లేకపోవడం, ఇన్‌స్టాల్ చేయని desktop ను సూచించే ~/.xsession, మీరు write చేయలేని home directory, లేదా పూర్తిగా నిండిన disk — ఇవన్నీ చివరికి ఇదే లక్షణాన్ని కలిగిస్తాయి.

మీరు connect అయినప్పుడు X cursor తో కూడిన grey screen కనిపిస్తుంది. X ప్రారంభమైంది, కానీ desktop ప్రారంభం కాలేదు. ఇది మళ్లీ ~/.xsession సమస్యే. SSH ద్వారా చేతితో xfce4-session ను అమలు చేసి, అది చూపించే error ను చదవండి.

self-hosted RustDesk సర్వర్ చేసే పని

RustDesk రెండు processes గా విభజించబడుతుంది. hbbs అనేది clients register అయ్యే ID మరియు rendezvous server. ప్రత్యక్ష peer-to-peer connection విఫలమైనప్పుడు session ను తరలించేది hbbr relay. ఈ రెండింటిలో ఏదీ 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 మొదటిసారి start అయినప్పుడు రూపొందించిన 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 తో మళ్లీ configure చేయాలి. ఆ directory కు backup తీసుకోండి. ఇది weekend experiment కాకుండా మీ team ప్రతి machine ను access చేసే ప్రధాన విధానంగా మారితే, latest కు బదులుగా pinned image tags, Ed25519 key handling మరియు మీ plan కోసం చెల్లించాల్సి వచ్చే relay bandwidth కోసం dedicated RustDesk relay build ను అనుసరించడం ఉపయోగకరం.

Firewall ఈ ports కు నేరుగా అనుమతి ఇవ్వాలి. 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పై కాకుండా తమ స్వంత binary protocols ను TCP మరియు UDP ద్వారా ఉపయోగిస్తాయి. Route చేయడానికి Host header ఉండదు. పరిశీలించడానికి HTTP request కూడా ఉండదు. అందువల్ల nginx లోని server block కు లేదా Traefik HTTP router కు సరిపోల్చడానికి ఏదీ ఉండదు. 21116 పై ఉన్న UDP listener ఏ స్థాయిలోనూ HTTP సంబంధితది కాదు.

రెండు విధానాలు పనిచేస్తాయి. nginx stream block తో TCP ports ను forward చేయగలదు. ఇది సాధారణ అర్థంలోని reverse proxy కాకుండా plain layer 4 forwarding. అలాగే 21118 మరియు 21119 ports RustDesk web client ఉపయోగించే websockets ను కలిగి ఉంటాయి. అవి సాధారణ HTTP కావడంతో ఈ రెండు ports ను మీ proxy వెనుక ఉంచవచ్చు. అలా చేస్తే 21118 మరియు 21119 కు proxy మాత్రమే చేరుకునేలా firewall rules జోడించండి. కారణం, websocket connections పై నిజమైన client address ను గుర్తించడానికి hbbs X-Real-IP header పై ఆధారపడుతుంది.

కంటైనర్‌లో తాత్కాలిక బ్రౌజర్

కొన్నిసార్లు మీకు కావలసింది, మారని IP కలిగిన, మీ స్వంత మెషీన్‌కు వేరుగా ఉంచిన శుభ్రమైన బ్రౌజర్ మాత్రమే. తక్కువ సాఫ్ట్‌వేర్‌తో కంటైనర్ workspace దీన్ని అందిస్తుంది. 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 ను అందిస్తుంది, port 3001 HTTPS ను అందిస్తుంది. ఎక్కడా RDP client లేకుండానే browser tab ద్వారా desktop ను యాక్సెస్ చేయవచ్చు. Image tags అనేక base distributions పై XFCE, KDE, MATE మరియు i3 ను అందిస్తాయి. ఈ container కు host పై privileged access ఉంటుందని, passwordless sudo తో terminal కూడా ఉంటుందని project documentation స్పష్టంగా హెచ్చరిస్తుంది. అందువల్ల దీన్ని రక్షణ లేకుండా internet కు అందుబాటులో ఉంచకూడదు. అందుకే పై ports ను అన్ని addresses పై publish చేయకుండా 127.0.0.1 కు bind చేశారు. xrdp కోసం ఉపయోగించిన అదే SSH tunnel లేదా అదే VPN ద్వారా దీన్ని యాక్సెస్ చేయాలి.

Kasm Workspaces ఇదే విధానాన్ని చాలా పెద్ద స్థాయిలో అందిస్తుంది. ఇందులో web console, user accounts, అలాగే session ముగిసినప్పుడు reset అయ్యే ప్రతి-session containers ఉంటాయి. చిన్న VPS కంటే దీనికి ఎక్కువ వనరులు అవసరం. August 2026 నాటికి documentation లో పేర్కొన్న కనీస అవసరాలు 2 CPU cores, 4 GB memory మరియు 50 GB SSD. దీనికి అదనంగా ప్రతి user session కు default గా 2 cores మరియు 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 commands కాకుండా framebuffer updates ను పంపుతుంది. అందువల్ల నెమ్మదైన link పై ఇది RDP కంటే భారంగా అనిపిస్తుంది. దీనిలో sound channel ఉండదు. అయితే ఒక సందర్భంలో ఇది ఉపయోగకరంగా ఉంటుంది: మీరు disconnect చేసిన తర్వాత కూడా desktop session నడుస్తూనే ఉండాలి, తిరిగి వచ్చినప్పుడు అదే session మళ్లీ అందుబాటులో ఉండాలి. TigerVNC ఈ విధంగా పనిచేస్తుంది. vncserver -localhost yes :1, Xvnc ను TCP 5901 పై 127.0.0.1 కు bind చేస్తుంది. ఇతర ఏ ప్రదేశం నుంచి వచ్చే connections ను ఇది నిరాకరిస్తుంది. అందువల్ల ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com ఉపయోగించి xrdp ను tunnel చేసినట్లే దీన్నీ tunnel చేయాలి. VNC port ను ఎప్పుడూ public చేయవద్దు. చాలా VNC servers handshake సమయంలో password ను మాత్రమే రక్షిస్తాయి; ఆ తర్వాతి డేటాను రక్షించవు. కాబట్టి public port పై session contents network లో చదవగలిగే విధంగా ఉంటాయి.

VPS desktop‌గా ఉపయోగించడానికి అనుకూలమా?

దైనందిన ప్రధాన కంప్యూటర్‌గా ఉపయోగించడానికి కాదు. దీనికి కారణాలు అనేకం. GPU ఉండదు కాబట్టి మొత్తం గ్రాఫిక్స్ పనిని CPU నిర్వహిస్తుంది. ప్రతి కీప్రెస్‌కు network round trip కోసం వేచి ఉండాలి. SSHలో 40 ms latency సరిపోతున్నట్లు అనిపించినా, text editorలో అది స్పష్టంగా తెలుస్తుంది. Videoను site ఒకసారి, RDP encoder మరోసారి compress చేస్తుంది. మీ files మీ ప్రత్యక్ష నియంత్రణలో లేని diskలో ఉంటాయి. అదనంగా, web server కోసం కేటాయించిన monthly bandwidth allowanceను desktopను ఎక్కువగా ఉపయోగిస్తే త్వరగా వినియోగించవచ్చు.

తాత్కాలికంగా ఉపయోగించే machineగా ఇది చాలా అనుకూలం. దానికి కారణం కూడా ఇదే లక్షణాలు. IP address స్థిరంగా ఉంటుంది, అది data centreకు చెందినదై ఉంటుంది. ఒక service ఎల్లప్పుడూ ఒకే addressను చూడాల్సి ఉన్నప్పుడు ఇది ఉపయోగకరం. Machineను image నుంచి కొన్ని నిమిషాల్లో rebuild చేయవచ్చు. కాబట్టి ఏదైనా హానికరమైనదాన్ని పొందిన sessionను తొలగించి మళ్లీ నిర్మించడానికి అదనపు ఖర్చు ఉండదు. ఇది మీ నిజమైన hardware నుంచి వేరుగా ఉంటుంది. మీ laptop మూసి ఉన్నా ఇది నడుస్తూనే ఉంటుంది. Hourly billing కారణంగా తాత్కాలిక desktop ఖర్చు తక్కువగా ఉంటుంది.

ఈ machineను ఏ పనికి ఉపయోగించాలో ఇంకా నిర్ణయించుకుంటుంటే, దానిపై desktop install చేయడానికి ముందు VPS ఏ పనులకు అనుకూలమో తెలిపే ఆచరణాత్మక జాబితా చదవడం ఉపయోగకరం. ఒక Windows application కోసమే desktop అవసరమై ఉంటే, ముందుగా Linux మరియు Windows Server మధ్య ఉన్న వాస్తవ తేడాలు పరిశీలించండి. ఎందుకంటే licence వల్ల సమాధానం మొత్తం ఖర్చు మారవచ్చు.

FAQ

2 GB VPSలో remote desktop నడపవచ్చా?

అవును, తేలికైన desktop ఉపయోగిస్తే నడపవచ్చు. Login అయిన తర్వాత XFCE లేదా LXQt సుమారుగా 300 నుంచి 400 MB ఉపయోగిస్తాయి. అందువల్ల కొన్ని tabs ఉన్న browser కు తగినంత memory మిగులుతుంది. 2 GBలో GNOME లేదా KDE Plasma నడిపితే applications కు దాదాపు memory మిగలదు. 2 GB swap file జోడించండి. అప్పుడు memory pressure వల్ల processes హఠాత్తుగా ఆగిపోకుండా machine నెమ్మదిస్తుంది. ఏదైనా message లేకుండా అదృశ్యమైతే, kernel out-of-memory killer కోసం dmesg | grep -i "killed process" ను పరిశీలించండి.

నా VPS firewallలో port 3389 తెరవాలా?

వద్దు. TCP 3389ను నిరంతరం scan చేస్తుంటారు. బయటకు expose చేసిన 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 తో దానికి చేరుకోండి. ఒకరు లేదా ఇద్దరికి మించిన users ఉంటే, xrdpను loopbackకు బదులుగా WireGuard addressకు bind చేయండి.

xrdp "Authentication is required to create a color managed device" అని ఎందుకు అడుగుతుంది?

colord service అనుమతి కోసం polkitను అడుగుతుంది. Localగా login అయిన sessionకు మాత్రమే polkit ఆ చర్యకు సంబంధించిన అనుమతిని నిశ్శబ్దంగా ఇస్తుంది. RDP session localగా seated కాదు. అందువల్ల ప్రతి login సమయంలో password prompt కనిపిస్తుంది. Ubuntu 24.04లో పాత .pkla పరిష్కారం పనిచేయదు. కారణం, polkit 124 local authority filesను తొలగించింది. JavaScript rule కలిగిన /etc/polkit-1/rules.d/45-allow-colord.rules ను సృష్టించండి. ఆ rule, action ids org.freedesktop.color-manager. తో ప్రారంభమైనప్పుడు polkit.Result.YES ను return చేయాలి. తరువాత sudo systemctl restart polkit ను run చేయండి.

self-hosted RustDesk serverను nginx లేదా Traefik వెనుక ఉంచవచ్చా?

ప్రధాన serviceను ఉంచలేరు. hbbs మరియు hbbr HTTPకు బదులుగా తమ స్వంత binary protocolsను ఉపయోగిస్తాయి. అందువల్ల route చేయడానికి Host header ఉండదు. UDP 21116 HTTP proxy ద్వారా అసలు వెళ్లదు. Firewallలో TCP 21115 నుంచి 21119 వరకు మరియు UDP 21116ను తెరిచి, clientsను నేరుగా connect అయ్యేలా చేయండి. Web client ఉపయోగించే websocket ports 21118 మరియు 21119 HTTPపై పనిచేస్తాయి. వాటిని proxy వెనుక ఉంచవచ్చు. అలా చేస్తే proxy మాత్రమే వాటిని చేరుకునేలా firewallలో నియంత్రించండి. కారణం, ఆ connectionsపై 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 ను run చేయండి. తరువాత 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".