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 render करत नाही. तो दोन्ही 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. तुमच्याकडे key pair असल्यामुळे session अनोळखी लोकांनी चालवलेल्या सार्वजनिक rendezvous server मधून जाण्यापासून ते संरक्षण करते. मात्र ते नियंत्रित केल्या जाणाऱ्या machine चे संरक्षण करत नाही. ती machine तुम्ही client install केलेला कोणताही PC असतो आणि त्या PC वर असलेला कोणताही password लागू राहतो.
• SSH tunnel किंवा VPN वर xrdp. TCP 3389 च्या इंटरनेटभर होणाऱ्या सततच्या scanning पासून आणि RDP login box वरील password guessing पासून ते तुमचे संरक्षण करते, कारण हा port इंटरनेटसमोर कधीच उघडा राहत नाही. मात्र tunnel आधीच मिळवलेल्या कोणत्याही व्यक्तीपासून weak account password चे संरक्षण ते करत नाही.
• त्याच tunnel वर VNC. disconnect झाल्यानंतरही टिकणारे desktop session ते देते. यासाठी RDP पेक्षा जुना आणि सोपा protocol वापरला जातो. स्वतंत्रपणे ते कोणतेही संरक्षण देत नाही: सर्व security काम tunnel करते. त्यामुळे सार्वजनिक port वर एकट्याने चालणारे VNC हा येथे सर्वांत वाईट पर्याय आहे.
• Webtop किंवा Kasm सारखे container workspace. फेकून देऊन पुन्हा तयार करता येणाऱ्या container मध्ये ते browser किंवा संपूर्ण desktop देते. त्यामुळे browser ज्या गोष्टींशी संपर्क साधतो त्यापासून तुमच्या वास्तविक machine चे संरक्षण होते. मात्र host चे संरक्षण होत नाही: या images broad privileges आणि passwordless sudo सह चालतात. त्यामुळे hostile workload साठी container ही विश्वासार्ह boundary नाही.

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

VPS सर्व्हर इमेजमध्ये graphical desktop नसतो. प्रथम तो स्थापित करा. त्यानंतर xrdp स्थापित करा. xrdp हा RDP (remote desktop protocol) वापरणारा open-source server आहे. 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 चालवतो. ती फाइल उपलब्ध असल्यास ~/.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 चालवल्यानंतर groups मध्ये ssl-cert दिसत नसेल, तर sudo adduser xrdp ssl-cert आणि नंतर sudo systemctl restart xrdp चालवा. हे वगळल्यास xrdp key उघडू शकत नाही. त्या अपयशाची नोंद /var/log/xrdp.log मध्ये snakeoil filename सह केली जाते.

इंटरनेटवर port 3389 उघडू नये याचे कारण

इंटरनेटवरील प्रत्येक घटक TCP 3389 सतत scan करत असतो आणि 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 करून पुष्टी करा, कारण येथे झालेली typo सेवा सर्व 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 वरील एखादी प्रक्रिया आधीच 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 ला स्वतः host केलेल्या WireGuard VPN च्या मागे ठेवा, त्याला tunnel address 10.8.0.1 द्या आणि port=tcp://10.8.0.1:3389 सेट करा, जेणेकरून xrdp फक्त VPN च्या आत प्रतिसाद देईल. कोणताही पर्याय निवडला तरी 3389 साठी firewall rule मुळीच अस्तित्वात नसावा. सध्याच्या rules मुळे काय परवानगी आहे याबद्दल खात्री नसल्यास VPS वरील ufw firewall मूलतत्त्वे येथून सुरुवात करा आणि connect करण्यापूर्वी तपासा, नंतर नाही.

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

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

[
  {
    "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 उरते. GNOME एकही window उघडण्यापूर्वी सुमारे 1,200 MB वापरतो. त्यामुळे 2 GB system वर उरलेल्या memory साठी browser आणि desktop यांच्यात स्पर्धा सुरू होते.

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

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

xrdp सत्रातील ध्वनी आणि clipboard

Ubuntu 24.04 ध्वनीसाठी PipeWire वापरते. xrdp मधील ध्वनी redirection हे PulseAudio साठी लिहिलेले आहे. त्यामुळे नवीन installation मध्ये video कार्यरत असते, पण ध्वनी ऐकू येत नाही. Ubuntu यासाठी bridge package उपलब्ध करून देते.

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

RDP सत्रातून पूर्णपणे log out करा आणि पुन्हा log in करा, कारण हे 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 ने ध्वनीची विनंती करणे देखील आवश्यक आहे. Windows client मध्ये हे /sound on xfreerdp3 flag किंवा Local Resources अंतर्गत "Remote audio" setting द्वारे केले जाते.

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

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

पहिल्या लॉगिनवेळी सर्वाधिक दिसणारे आश्चर्य म्हणजे Authentication is required to create a color managed device असा संदेश दाखवणारा संवाद. यामागचे कारण विशिष्ट आहे. colord सेवा परवानगीसाठी polkit कडे विनंती करते. polkit ही कृती केवळ स्थानिकरित्या उपस्थित मानल्या जाणाऱ्या session ला शांतपणे मंजूर करते. RDP session स्थानिकरित्या उपस्थित मानले जात नाही. त्यामुळे 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 नसणे, स्थापित नसलेल्या desktop चे नाव देणारे ~/.xsession, ज्यामध्ये तुम्हाला लिहिता येत नाही अशी home directory किंवा भरलेली disk — या सर्व कारणांचा शेवट याच लक्षणात होतो.

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

स्वतः होस्ट केलेला RustDesk सर्व्हर काय करतो

RustDesk दोन प्रक्रियांमध्ये विभागलेले आहे. hbbs हा क्लायंट नोंदणी करण्यासाठी वापरत असलेला ID आणि rendezvous सर्व्हर आहे. 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

प्रत्येक क्लायंटमध्ये तुमचा host name आणि ती public key आवश्यक आहे. RustDesk client मधील Network settings अंतर्गत दोन्ही नोंदी करा. संबंधित private key ./data/id_ed25519 मध्येच राहते. Data directory हटवल्यास सर्व्हर नवीन key pair निर्माण करतो. त्यामुळे त्यानंतर प्रत्येक क्लायंटमध्ये नवीन key सह पुन्हा configuration करावे लागते. त्या directory चा backup घ्या. हा प्रयोगापुरता setup न राहता तुमच्या टीमने प्रत्येक machine वर पोहोचण्यासाठी याच पद्धतीचा वापर करायचा असल्यास, RustDesk relay ची dedicated build Ed25519 key हाताळणी, latest ऐवजी pinned image tags आणि तुमच्या plan नुसार लागणारी relay bandwidth यांसाठी उपयुक्त ठरेल.

Firewall मध्ये हे ports थेट allow केले पाहिजेत. 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 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 वर विश्वास ठेवते.

कंटेनरमधील disposable browser

कधीकधी तुम्हाला फक्त असा स्वच्छ browser हवा असतो, ज्याचा IP बदलत नाही आणि जो तुमच्या स्वतःच्या मशीनपासून वेगळा ठेवलेला असतो. Container workspace हे काम कमी software install करून करते. LinuxServer's 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 न करता browser tab मध्ये desktop उघडता येतो. Image tags मध्ये अनेक base distributions साठी XFCE, KDE, MATE आणि i3 उपलब्ध आहेत. या प्रकल्पाच्या documentation मध्ये जोखमीबाबत स्पष्ट इशारा दिला आहे: कंटेनरला host वर privileged access असतो आणि त्यात passwordless 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 पेक्षा यासाठी अधिक संसाधने आवश्यक आहेत. 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 पाठवते. त्यामुळे धीम्या नेटवर्क दुव्यावर ते RDP पेक्षा अधिक जड वाटते. तसेच त्यात sound channel नसतो. VNC एका परिस्थितीत उपयुक्त ठरते: 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 servers handshake दरम्यान password सुरक्षित ठेवतात; त्यानंतरच्या डेटासाठी कोणतेही संरक्षण देत नाहीत. त्यामुळे public port वर session मधील मजकूर network वर उघडपणे वाचता येतो.

VPS हा डेस्कटॉप म्हणून योग्य आहे का?

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

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

या machine चा उपयोग कशासाठी करायचा हे अजून ठरवत असाल, तर त्यावर 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 वर GNOME किंवा KDE Plasma चालवल्यास applications साठी जवळजवळ memory उरत नाही. 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 वर listening करेल. ss -tlnp | grep 3389 ने ते पडताळा आणि ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com ने त्याच्याशी connect करा. एक किंवा दोनपेक्षा अधिक users असल्यास xrdp ला loopback ऐवजी WireGuard address वर bind करा.

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

colord service polkit कडे permission मागते. 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 वापरतात. त्यामुळे त्यांच्यावर route करण्यासाठी 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" हा पर्याय वापरा.