SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor

Linux VPS वर remote desktop कसा चालवायचा?

xrdp आणि XFCE वापरून Linux VPS वर प्रत्यक्ष graphical desktop चालवा. port 3389 उघडण्याऐवजी SSH tunnel वापरा आणि RustDesk कधी योग्य ठरते ते समजा.

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 वापरा. खालील मजकुरात दुसऱ्या प्रकाराला अधिक जागा दिली आहे, कारण बहुतेक मार्गदर्शक हा प्रकार वगळतात.

तुमच्या कामासाठी कोणता पर्याय योग्य आहे

  • तुमच्या स्वतःच्या relay सह RustDesk. सार्वजनिक rendezvous server मधून session जाण्यापासून ते संरक्षण करते, कारण key pair तुमच्या नियंत्रणात असते. मात्र नियंत्रित केली जाणारी मशीन सुरक्षित होत नाही. ती client install केलेली कोणतीही PC आणि त्या PC वर सेट केलेला कोणताही password असतो.
  • SSH tunnel किंवा VPN वर xrdp. TCP 3389 चे संपूर्ण इंटरनेटवरून होणारे सतत scanning आणि RDP login box वरील password guessing यापासून ते संरक्षण करते, कारण तो port इंटरनेटसमोर उघडा नसतो. मात्र ज्याच्याकडे tunnel आधीपासून आहे, त्याच्यापासून weak account password सुरक्षित होत नाही.
  • त्याच tunnel वर VNC. disconnection नंतरही टिकणारे desktop session मिळते आणि त्यासाठी RDP पेक्षा जुना व सोपा protocol वापरला जातो. स्वतंत्रपणे ते कोणतेही संरक्षण देत नाही. सर्व security काम tunnel करते. त्यामुळे public port वर एकट्या VNC चा वापर हा येथे सर्वांत वाईट पर्याय आहे.
  • Webtop किंवा Kasm सारखे container workspace. browser किंवा संपूर्ण desktop अशा container मध्ये मिळते, जो तुम्ही हटवून पुन्हा build करू शकता. त्यामुळे browser ज्या गोष्टींना स्पर्श करतो त्यापासून तुमची वास्तविक मशीन सुरक्षित राहते. मात्र host सुरक्षित होत नाही. या images broad privileges सह चालतात आणि आत passwordless sudo असते. त्यामुळे hostile workload साठी container वर विश्वास ठेवता कामा नये.

Ubuntu 24.04 वर xrdp आणि XFCE स्थापित करा

VPS सर्व्हर इमेजमध्ये graphical desktop नसतो. तो आधी स्थापित करावा लागतो. त्यानंतर xrdp स्थापित करा. xrdp हा RDP (remote desktop protocol) वापरणारा open-source सर्व्हर आहे. 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 दाखवतो.

आता session ने कोणता desktop सुरू करायचा ते सांगा. xrdp /etc/xrdp/startwm.sh चालवतो. ही प्रक्रिया ती file अस्तित्वात असल्यास ~/.xsession चालवते.

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

शेवटी, xrdp ला clients साठी उपलब्ध करून देत असलेली TLS (transport layer security) key वाचावी लागते. त्या file चा mode 640 आहे आणि तिच्या मालकीचा group ssl-cert आहे.

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 सह करते.

इंटरनेटसाठी port 3389 का उघडू नये

इंटरनेटवरील प्रत्येक घटक TCP 3389 चे सतत scanning करतो आणि RDP login box प्रत्येक password प्रयत्नाला प्रतिसाद देतो. तो port उघडू नका. त्याऐवजी xrdp ला loopback address वर bind करा आणि आधीपासून विश्वसनीय असलेल्या tunnel द्वारे त्याच्यापर्यंत पोहोचा.

/etc/xrdp/xrdp.ini संपादित करा आणि [Globals] section मधील listener बदला.

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

वितरित केलेल्या file मधील comments मध्ये ही syntax स्पष्ट केली आहे: tcp://.:3389 म्हणजे 127.0.0.1:3389, तर tcp://:3389 म्हणजे प्रत्येक interface. Restart करून configuration ची खात्री करा. येथे typo असल्यास service सर्व addresses वर सुरू राहते आणि याची स्पष्ट सूचना मिळत नाही.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

तुम्हाला 127.0.0.1:3389 हवे आहे. 0.0.0.0:3389 दिसत असल्यास xrdp ने तुमचा बदल स्वीकारलेला नाही. सामान्यतः असे तेव्हा होते जेव्हा ही line file मधील पुढील वेगळ्या section heading अंतर्गत गेली असते.

आता तुमच्या स्वतःच्या 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 वर अंगभूत mstsc वापरा आणि computer म्हणून 127.0.0.1 प्रविष्ट करा. पहिल्यांदा connect करताना FreeRDP certificate वर विश्वास ठेवण्यास सांगते आणि 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 बदला आणि 127.0.0.1:13389 शी connect करा.

प्रत्येक व्यक्तीसाठी स्वतंत्र tunnel वापरणे त्रासदायक ठरते. त्यामुळे team साठी private network हा चांगला पर्याय आहे. हा box self-hosted WireGuard VPN च्या मागे ठेवा, त्याला tunnel address 10.8.0.1 द्या आणि port=tcp://10.8.0.1:3389 सेट करा, जेणेकरून xrdp फक्त VPN च्या आत उत्तर देईल. कोणताही पर्याय निवडला तरी 3389 साठीची firewall rule अस्तित्वातच नसावी. सध्याच्या rules मुळे काय परवानगी आहे याबद्दल खात्री नसल्यास, VPS वरील ufw firewall basics पासून सुरुवात करा आणि connect करण्यापूर्वी तपासा, connect केल्यानंतर नाही.

2 GB VPS वर remote desktop किती RAM वापरतो

तुम्ही निवडलेला desktop 2 GB plan आरामात वापरता येईल की तो पूर्णपणे अपुरा ठरेल, हे ठरवतो. खालील आकडे Ubuntu 24.04 वर login केल्यानंतर लगेच वापरात असलेल्या memory चे साधारण आकडे आहेत. हे तुमच्या मशीनवर मोजलेले नसून प्रकाशित तुलनांवर आधारित आहेत. तुम्ही connect झाल्यानंतर लगेच free -m वापरून स्वतःच्या सिस्टमवरील वापर मोजा.

ChartTypical memory in use after login, Ubuntu 24.04 (published figures)
The data behind this chart
[
  {
    "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 मध्ये memory वापरातील फरक महत्त्वाचा आहे. LXQt जवळपास 300 MB आणि XFCE जवळपास 400 MB वापरतो. त्यामुळे 2 GB सर्व्हरवर browser साठी दोन्हीमध्ये पुरेशी memory उरते. एकही window उघडण्यापूर्वी GNOME ला साधारण 1,200 MB लागतो. त्यामुळे 2 GB वर उरलेल्या memory साठी browser आणि desktop यांच्यात स्पर्धा सुरू होते.

मुख्य memory वापर desktop shell मुळे नव्हे, तर browser मुळे होतो. आधुनिक browser प्रत्येक active tab साठी साधारण 150 ते 400 MB वापरतो. त्यामुळे XFCE चालणारा 2 GB VPS काही tabs हाताळतो आणि त्यानंतर swap वापरू लागतो. प्रक्रिया बंद होण्याऐवजी मशीन मंदावण्यासाठी swap जोडा: sudo fallocate -l 2G /swapfile, त्यानंतर sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile चालवा आणि reboot नंतरही swap उपलब्ध राहण्यासाठी /etc/fstab मध्ये संबंधित ओळ जोडा. एखादी प्रक्रिया कोणतीही सूचना न देता बंद झाली, तर dmesg | grep -i "killed process" चालवा. याचा अर्थ kernel च्या out-of-memory killer ने ती प्रक्रिया बंद केली आहे. सामान्यतः browser हाच त्याचा बळी असतो.

CPU ही दुसरी मर्यादा आहे आणि तिचा अंदाज कमी लावणे सोपे असते. VPS मध्ये GPU नसतो. त्यामुळे X, llvmpipe द्वारे software rendering वापरतो आणि प्रत्येक pixel CPU कडून render केला जातो. मोठे web page scroll करणे आणि video playback करणे यामुळे थेट CPU load वाढतो. मशीन पूर्णपणे थांबण्याऐवजी frame rate कमी होतो. VPS वर gaming करता येते का याचा विचार करत असाल, तर हीच मर्यादा लागू होते: 3D कामांसाठी उत्तर नाही, आणि त्याचे कारण हेच आहे.

xrdp सत्रातील ध्वनी आणि क्लिपबोर्ड

Ubuntu 24.04 ध्वनीसाठी PipeWire वापरते. xrdp चे sound redirection PulseAudio साठी लिहिलेले असल्याने नवीन installation मध्ये video कार्यरत असतो, पण ध्वनी येत नाही. Ubuntu हे bridge package स्वरूपात पुरवते.

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

RDP सत्रातून पूर्णपणे log out करा आणि पुन्हा log in करा, कारण session सुरू होताना module load होते. फक्त reconnect करणे पुरेसे नाही. त्यानंतर सत्राच्या आतून तपासा:

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

xrdp चा उल्लेख असलेला sink दिसला पाहिजे आणि test tone तुमच्या client मधून ऐकू आला पाहिजे. xrdp sink दिसत नसेल, तर module या सत्रात load झालेले नाही. तुमच्या client ने audio साठी विनंती करणेही आवश्यक आहे. Windows client मध्ये हे /sound on xfreerdp3 flag किंवा Local Resources अंतर्गत "Remote audio" setting द्वारे केले जाते.

तुमच्या सत्रासाठी xrdp-chansrv चालू असल्यास text clipboard दोन्ही दिशांनी कार्य करते; xrdp ते तुमच्यासाठी सुरू करते. pgrep -a xrdp-chansrv वापरून ते चालू आहे याची खात्री करा. सत्राच्या मध्यात copy आणि paste काम करणे थांबले, तर ती process बंद झाली आहे. Reconnect केल्यावर ती पुन्हा सुरू होते. Text ऐवजी files copy करणे हे drive redirection नावाचे स्वतंत्र channel आहे: xfreerdp3 वरील /drive:home,/home/you remote session मध्ये local folder mount करते.

polkit पॉपअप आणि पहिल्या लॉगिनमधील इतर त्रुटी

पहिल्या लॉगिनच्या वेळी सर्वाधिक दिसणारे आश्चर्य म्हणजे Authentication is required to create a color managed device असा संदेश असलेला संवादपट. याचे कारण विशिष्ट आहे. colord सेवा परवानगीसाठी polkit कडे विनंती करते. polkit ही कृती फक्त locally seated मानल्या जाणाऱ्या 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 लिहिण्यास सांगणाऱ्या जुन्या मार्गदर्शकांतील पद्धतीचा 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 करा. लक्षणांवरून ओळखता येणाऱ्या आणखी दोन त्रुटी लक्षात ठेवा.

लॉगिन बॉक्स तुमचा password स्वीकारतो आणि लगेच पुन्हा दिसतो. Session सुरू होऊन लगेच बंद झाला आहे. प्रथम /var/log/xrdp-sesman.log वाचा. त्यानंतर तुमच्या home directory मधील ~/.xsession-errors वाचा. xorgxrdp नसणे, ~/.xsession मध्ये install न केलेल्या desktop चे नाव असणे, ज्या home directory मध्ये लिहिता येत नाही अशी directory असणे किंवा disk पूर्ण भरलेली असणे—या सर्व कारणांचा शेवट याच लक्षणात होतो.

तुम्ही connect करता आणि X cursor असलेली grey screen दिसते. X सुरू झाले आहे, पण desktop सुरू झालेले नाही. येथे पुन्हा ~/.xsession कारणीभूत आहे: SSH द्वारे xfce4-session manually चालवा आणि ते दाखवणारी error वाचा.

self-hosted RustDesk सर्व्हरचे कार्य

RustDesk दोन प्रक्रियांमध्ये विभागलेले आहे. hbbs हा clients नोंदणी करतात तो ID आणि rendezvous server आहे. hbbr हा direct peer-to-peer connection अयशस्वी झाल्यावर session वाहून नेणारा relay आहे. यापैकी कोणतीही प्रक्रिया desktop चालवत नाही. दोन्ही प्रक्रिया एका image मधून येतात. खाली प्रकल्पाने प्रकाशित केलेली 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

ही रचना सुरू करा. त्यानंतर सर्व्हरने पहिल्यांदा सुरू होताना निर्माण केलेली 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 delete केल्यास सर्व्हर नवी key pair निर्माण करतो. त्यामुळे त्यानंतर प्रत्येक client मध्ये नवी key पुन्हा configure करावी लागते. त्या directory चा backup ठेवा.

Firewall मध्ये हे ports थेट allow केलेले असणे आवश्यक आहे. hbbs साठी TCP 21115, 21116 आणि 21118 तसेच UDP 21116 allow करा. hbbr साठी TCP 21117 आणि 21119 allow करा.

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 का चालत नाही

प्रत्येक सेवेचे TLS एकाच reverse proxy वर terminate करणारे वाचक ही रचना वापरण्याचा प्रयत्न करतात आणि अपयशी ठरतात. hbbs आणि hbbr HTTP ऐवजी TCP आणि UDP वर त्यांचे स्वतंत्र binary protocols वापरतात. Routing करण्यासाठी Host header उपलब्ध नसतो आणि तपासण्यासाठी HTTP request नसते. त्यामुळे nginx च्या server block किंवा Traefik HTTP router कडे जुळवण्यासाठी काहीही नसते. 21116 वरील UDP listener कोणत्याही स्तरावर HTTP घटक नाही.

दोन गोष्टी कार्य करतात. nginx stream block वापरून TCP ports forward करू शकतो. हे नेहमीच्या अर्थाने reverse proxy नसून साधे layer 4 forwarding आहे. तसेच 21118 आणि 21119 ports वर RustDesk web client वापरत असलेले websockets असतात. ते सामान्य HTTP असल्यामुळे हे दोन्ही ports तुमच्या proxy च्या मागे ठेवता येतात. असे केल्यास firewall rules जोडा, जेणेकरून 21118 आणि 21119 पर्यंत फक्त proxy पोहोचू शकेल. कारण websocket connections वरील वास्तविक client address शोधण्यासाठी hbbs X-Real-IP header वर विश्वास ठेवतो.

कंटेनरमधील तात्पुरता ब्राउझर

काही वेळा तुम्हाला फक्त स्वच्छ ब्राउझर हवा असतो, ज्याचा 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 कुठेही install करण्याची गरज नसते; desktop browser tab मध्ये उघडता येतो. Image tags मध्ये अनेक base distributions वर XFCE, KDE, MATE आणि i3 समाविष्ट आहेत. या प्रकल्पाच्या documentation मध्ये जोखमीबाबत स्पष्ट सूचना आहे: या कंटेनरला host वर privileged access असतो आणि त्यात password शिवाय sudo वापरणारे terminal समाविष्ट असते. त्यामुळे तो असुरक्षितपणे internet-facing ठेवू नये. म्हणून वरील ports सर्व addresses वर publish करण्याऐवजी 127.0.0.1 ला bind केले आहेत. xrdp साठी वापरलेल्या त्याच SSH tunnel किंवा त्याच VPN द्वारे त्याच्यापर्यंत पोहोचा.

Kasm Workspaces ही त्याच कल्पनेची अधिक मोठ्या प्रमाणातील आवृत्ती आहे. यात web console, user accounts आणि session संपल्यावर reset होणारे प्रत्येक session साठी स्वतंत्र containers असतात. लहान VPS पेक्षा यासाठी अधिक machine resources आवश्यक आहेत. August 2026 पर्यंतच्या documentation नुसार किमान आवश्यकता 2 CPU cores, 4 GB memory आणि 50 GB SSD अशी आहे. याशिवाय प्रत्येक user session साठी default म्हणून 2 cores आणि 2768 MB memory आवश्यक असते. 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 पाठवते. त्यामुळे धीम्या लिंकवर ते RDP पेक्षा जड वाटते. तसेच त्यात sound channel नसतो. VNC एका परिस्थितीत उपयुक्त ठरते: 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 करा. VNC port कधीही सार्वजनिक करू नका. बहुतेक VNC servers handshake दरम्यान password चे संरक्षण करतात; त्यानंतरच्या session चे मात्र करत नाहीत. त्यामुळे public port वर session मधील मजकूर network वर वाचता येतो.

VPS हा desktop म्हणून योग्य आहे का?

दैनंदिन वापरासाठी नाही. त्यामागची कारणे अनेक आहेत. GPU नसल्यामुळे CPU ला सर्व rendering करावे लागते. प्रत्येक keypress साठी network round trip ची प्रतीक्षा करावी लागते. SSH मध्ये 40 ms latency स्वीकारार्ह वाटू शकते, पण text editor मध्ये ती जाणवते. Video चे compression दोनदा होते: एकदा site कडून आणि पुन्हा RDP encoder कडून. तुमच्या files तुमच्या ताब्यात नसलेल्या disk वर असतात. तसेच, जड desktop वापरामुळे web server साठी निश्चित केलेली monthly bandwidth allowance लवकर संपते.

तात्पुरत्या वापरासाठीचे machine म्हणून VPS अतिशय चांगला आहे. याच गुणधर्मांमुळे ते उपयुक्त ठरते. IP address स्थिर असतो आणि तो data centre चा असतो. एखाद्या service ला सातत्यपूर्ण address दिसणे आवश्यक असल्यास हेच अपेक्षित असते. Machine image वरून काही मिनिटांत पुन्हा तयार करता येतो. त्यामुळे एखाद्या session मध्ये धोकादायक software आल्यास ते machine पुन्हा तयार करण्याचा खर्च जवळजवळ शून्य असतो. ते तुमच्या वास्तविक hardware पासून isolated असते आणि laptop बंद केल्यानंतरही चालू राहते. Hourly billing मुळे तात्पुरते वापरण्याचा desktop स्वस्त पडतो.

हा server नेमका कशासाठी आहे हे अजून ठरवत असाल, तर त्यावर desktop install करण्यापूर्वी VPS कोणत्या कामांसाठी उपयुक्त आहे याची व्यावहारिक यादी वाचणे उपयुक्त ठरेल. Desktop हवा असण्याचे कारण एखादे Windows application असेल, तर आधी Linux आणि Windows Server मधील वास्तविक फरक लक्षात घ्या. कारण licence मुळे या पर्यायाचा खर्च बदलतो.

FAQ

2 GB VPS वर remote desktop चालवता येईल का?

होय, हलक्या desktop सह. Login केल्यानंतर XFCE किंवा LXQt सुमारे 300 ते 400 MB memory वापरतात. त्यामुळे काही tabs असलेला browser चालवण्यासाठी पुरेशी memory उरते. 2 GB memory असलेल्या VPS वर GNOME किंवा KDE Plasma चालवल्यास applications साठी जवळजवळ काहीही उरत नाही. 2 GB ची swap file जोडा. त्यामुळे memory pressure मुळे processes बंद होण्याऐवजी मशीनचा वेग कमी होईल. एखादी गोष्ट कोणताही 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 वापरून त्याला access करा. एक किंवा दोनपेक्षा जास्त वापरकर्ते असल्यास, xrdp ला loopback ऐवजी WireGuard address वर bind करा.

xrdp "Authentication is required to create a color managed device" असे का विचारते?

colord service permission साठी polkit कडे विनंती करते. polkit ही action फक्त locally seated session ला शांतपणे मंजूर करते. RDP session seated नसते. त्यामुळे प्रत्येक login वेळी password prompt दिसतो. Ubuntu 24.04 वर जुना .pkla fix काहीही करत नाही, कारण polkit 124 ने local authority files काढून टाकल्या आहेत. /etc/polkit-1/rules.d/45-allow-colord.rules तयार करा. त्यात action ids org.freedesktop.color-manager. ने सुरू होत असल्यास polkit.Result.YES परत करणारा JavaScript rule ठेवा. त्यानंतर sudo systemctl restart polkit चालवा.

self-hosted RustDesk server nginx किंवा Traefik च्या मागे ठेवता येईल का?

मुख्य service ठेवता येणार नाही. hbbs आणि hbbr HTTP ऐवजी त्यांचे स्वतःचे binary protocols वापरतात. त्यामुळे routing करण्यासाठी Host header उपलब्ध नसतो. UDP 21116 HTTP proxy मधून अजिबात जाऊ शकत नाही. Firewall वर TCP 21115 ते 21119 आणि UDP 21116 उघडा. Clients ना थेट connect होऊ द्या. Web client वापरत असलेले websocket ports 21118 आणि 21119 हे HTTP आहेत. ते proxy च्या मागे ठेवता येतात. असे केल्यास firewall मध्ये फक्त proxy ला त्यांच्यापर्यंत पोहोचण्याची परवानगी द्या, कारण त्या connections वर 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 करा. Module session सुरू होताना load केले जाते. Reconnect केल्याने ते load होणार नाही. xrdp नावाचा sink आहे का हे pactl list short sinks वापरून तपासा. तसेच client audio ची विनंती करत आहे याची खात्री करा. xfreerdp3 वरील /sound flag किंवा Windows client मधील "Remote audio" हा पर्याय यासाठी वापरला जातो.

#remote-desktop#xrdp#rustdesk#vnc#self-hosting