Linux VPS-ல் Remote Desktop அமைப்பது எப்படி?

Linux VPS-ல் remote desktop என்பதன் உண்மையான பொருள்

"Linux VPS-ல் remote desktop" என்று தேடும்போது இரண்டு வெவ்வேறு தயாரிப்புகள் முடிவுகளாகக் கிடைக்கின்றன. தவறானதைத் தேர்ந்தெடுத்தால் உங்கள் நேரம்தான் வீணாகும். முதலாவது, remote-access broker. RustDesk-ன் self-hosted server இதற்கு ஒரு பொதுவான உதாரணம். இது உங்களிடம் ஏற்கனவே உள்ள இரண்டு கணினிகளுக்கு இடையே (உதாரணமாக, உங்கள் laptop மற்றும் வீட்டில் உள்ள PC) ஒரு session-ஐ இணைத்துத் தருகிறது. வாடகைக்கு எடுக்கப்பட்ட server-ல் எந்த desktop-ம் இயங்காது. இது இரண்டு முனைகளையும் ஒன்றோடொன்று அறிமுகப்படுத்தி, அவை நேரடியாகத் தொடர்புகொள்ள முடியாதபோது packets-ஐ மட்டும் கடத்துகிறது. இரண்டாவது, வாடகைக்கு எடுக்கப்பட்ட server-ல் இயங்கும் உண்மையான graphical desktop. இதில் pixels அந்த data centre-லேயே உருவாக்கப்பட்டு உங்களுக்கு stream செய்யப்படுகிறது. இதற்கு xrdp, VNC (virtual network computing), அல்லது container workspace போன்றவை பயன்படுகின்றன.

இவற்றைப் பிரித்தறிய ஒரு கேள்வி உதவும். இது செயல்படத் தொடங்கிய பிறகு, mouse pointer எங்கே இருக்கும்? உங்களிடம் ஏற்கனவே உள்ள கணினியில் வேலை செய்ய வேண்டுமென்றால், உங்களுக்கு ஒரு broker தேவை. VPS-க்குள்ளேயே வேலை செய்ய வேண்டுமென்றால், உங்களுக்கு VPS-ல் ஒரு desktop தேவை. கீழே உள்ள பகுதியில் இரண்டாவது வகைக்கே அதிக முக்கியத்துவம் கொடுக்கப்பட்டுள்ளது, ஏனெனில் பெரும்பாலான வழிகாட்டிகள் இந்த விஷயத்தைத் தவிர்த்துவிடுகின்றன.

உங்கள் பணிக்கு எந்த விருப்பம் பொருத்தமானது

• சொந்த relay-உடன் கூடிய RustDesk. இது அமர்வுகளை (sessions) அந்நியர்கள் நடத்தும் பொது rendezvous server வழியாகச் செல்லாமல் பாதுகாக்கிறது, ஏனெனில் cryptographic key pair உங்களிடம் மட்டுமே இருக்கும். இது கட்டுப்படுத்தப்படும் கணினியைப் பாதுகாக்காது; நீங்கள் client-ஐ நிறுவிய PC-யும், அதில் உள்ள கடவுச்சொல்லும் அப்படியே இருக்கும்.
• SSH tunnel அல்லது VPN வழியாக xrdp. இது TCP 3389 port-ஐ இணையம் முழுவதும் ஸ்கேன் செய்வதிலிருந்தும், RDP login பெட்டியில் கடவுச்சொற்களை ஊகிப்பதிலிருந்தும் உங்களைப் பாதுகாக்கிறது, ஏனெனில் அந்த port இணையத்தில் நேரடியாகத் தெரிவதில்லை. ஆனால், tunnel-க்குள் நுழைய அனுமதி பெற்ற எவரிடமிருந்தும் பலவீனமான கணக்குக் கடவுச்சொல்லை இது பாதுகாக்காது.
• அதே tunnel வழியாக VNC. இது துண்டிக்கப்பட்டாலும் நீடிக்கும் desktop அமர்வை வழங்குகிறது, இது RDP-ஐ விட பழைய மற்றும் எளிமையான protocol ஆகும். இது தனியாக எதையும் பாதுகாப்பதில்லை: tunnel மட்டுமே அனைத்துப் பாதுகாப்பு வேலைகளையும் செய்கிறது, எனவே பொதுவான port-ல் VNC-ஐ மட்டும் பயன்படுத்துவது இதில் மிக மோசமான தேர்வாகும்.
• Webtop அல்லது Kasm போன்ற container workspace. இது ஒரு browser அல்லது முழுமையான desktop-ஐ அழித்துவிட்டு மீண்டும் உருவாக்கக்கூடிய container-ல் வழங்குகிறது, இது நீங்கள் பயன்படுத்தும் browser அணுகும் எதிலிருந்தும் உங்கள் உண்மையான கணினியைப் பாதுகாக்கிறது. இது host-ஐப் பாதுகாக்காது: இந்த images அதிக உரிமைகளுடன் (privileges) மற்றும் கடவுச்சொல் இல்லாத sudo-உடன் இயங்குகின்றன, எனவே hostile workload-ஐக் கையாளும் போது இந்த container-ஐ ஒரு பாதுகாப்பான எல்லையாகக் கருதக்கூடாது.

Ubuntu 24.04-ல் xrdp மற்றும் XFCE-ஐ நிறுவுதல்

VPS server image-களில் graphical desktop இருப்பதில்லை. எனவே, நீங்கள் ஒன்றை நிறுவி, அதன் பிறகு Windows client பயன்படுத்தும் அதே RDP (remote desktop protocol)-ஐ ஆதரிக்கும் open-source server-ஆன xrdp-ஐ நிறுவ வேண்டும். இலகுவான desktop-ஐத் தேர்வு செய்வது சிறந்தது; இதற்கு XFCE பொதுவாகப் பரிந்துரைக்கப்படுகிறது.

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

ஆகஸ்ட் 2026 நிலவரப்படி, Ubuntu 24.04-ன் universe component-ல் xrdp 0.9.24 மற்றும் xorgxrdp ஆகியவை உள்ளன. xorgxrdp-ஐ அதன் பெயரைக் கொண்டே நிறுவவும்; இது ஒரு பரிந்துரைக்கப்பட்ட package மட்டுமே என்றாலும், புதிய session-ஐத் தொடங்க xrdp பயன்படுத்தும் X server backend இதுவே. இது இல்லையெனில், login திரையில் உங்கள் கடவுச்சொல்லை உள்ளிட்டதும், மீண்டும் அதே login திரையிற்கே வந்துவிடுவீர்கள்.

இப்போது எந்த desktop-ஐத் தொடங்க வேண்டும் என்பதை session-க்குத் தெரிவிக்க வேண்டும். xrdp /etc/xrdp/startwm.sh-ஐ இயக்குகிறது; அந்த file இருக்கும்போது அது ~/.xsession-ஐ இயக்கும்.

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

இறுதியாக, client-களுக்கு வழங்கும் TLS (transport layer security) key-ஐ xrdp வாசிக்க வேண்டும். அந்த file 640 mode-ல் இருக்க வேண்டும் மற்றும் அதன் உரிமையாளர் ssl-cert group-ஆக இருக்க வேண்டும்.

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

இந்த பட்டியல் -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 அந்தப் பிழையை snakeoil filename-உடன் பதிவு செய்யும்.

ஏன் port 3389-ஐ இணையத்திற்குத் திறக்கக்கூடாது

TCP 3389 இணையத்தில் உள்ள அனைவராலும் தொடர்ந்து ஸ்கேன் செய்யப்படுகிறது, மேலும் RDP login box ஒவ்வொரு கடவுச்சொல் முயற்சிக்கும் பதிலளிக்கும். இதைத் திறக்க வேண்டாம். xrdp-ஐ loopback முகவரியுடன் பிணைத்து (bind), நீங்கள் ஏற்கனவே நம்பும் tunnel வழியாக அதை அணுகுங்கள்.

/etc/xrdp/xrdp.ini-ஐத் திருத்தி, [Globals] பிரிவில் உள்ள listener-ஐ மாற்றவும்.

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

வழங்கப்பட்ட கோப்பு அதன் சொந்த கருத்துகளில் அந்த syntax-ஐ ஆவணப்படுத்துகிறது: tcp://.:3389 என்பது 127.0.0.1:3389 என்பதைக் குறிக்கிறது, மற்றும் tcp://:3389 என்பது அனைத்து interface-களையும் குறிக்கிறது. Restart செய்து உறுதிப்படுத்தவும், ஏனெனில் இதில் ஏற்படும் ஒரு தட்டச்சுப் பிழை (typo) அமைதியாகச் சேவையை அனைத்து முகவரிகளிலும் விட்டுவிடும்.

sudo systemctl restart xrdp
ss -tlnp | grep 3389

உங்களுக்கு 127.0.0.1:3389 தேவை. 0.0.0.0:3389 என்று காண்பது, xrdp உங்கள் மாற்றத்தைப் புறக்கணித்துவிட்டது என்று பொருள், பொதுவாக அந்த வரி கோப்பின் கீழே வேறொரு பிரிவின் தலைப்பின் கீழ் சென்றதால் இது நிகழும்.

இப்போது உங்கள் கணினியிலிருந்து tunnel-ஐத் திறக்கவும்.

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

-N என்பது "இணைப்பைத் திறக்கவும் ஆனால் எந்தக் கட்டளையையும் இயக்க வேண்டாம்" என்று பொருள், எனவே அந்த session port-ஐக் கொண்டு செல்ல மட்டுமே இருக்கும். அந்த terminal-ஐ இயங்கவிட்டு, RDP client-ஐ 127.0.0.1:3389-க்குச் சுட்டிக்காட்டவும். Linux client-ல் மென்பொருள் FreeRDP 3 ஆகும், அதன் binary Ubuntu 24.04-ல் xfreerdp3 என்று அழைக்கப்படுகிறது:

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

Windows-ல் உள்ளமைக்கப்பட்ட mstsc-ஐப் பயன்படுத்தவும் மற்றும் கணினியாக 127.0.0.1 என்று தட்டச்சு செய்யவும். முதல் இணைப்பின் போது certificate-ஐ நம்புமாறு FreeRDP கேட்கும் மற்றும் Do you trust the above certificate? (Y/T/N)-ஐ அச்சிடும், இது self-signed snakeoil certificate-டன் எதிர்பார்க்கப்படுவதுதான்.

ssh bind [127.0.0.1]:3389: Address already in use என்று பதிலளித்தால், உங்கள் கணினியில் ஏதோ ஒன்று ஏற்கனவே 3389-ஐப் பிடித்துள்ளது. உள்ளூர் முனையை ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com மூலம் நகர்த்தி, 127.0.0.1:13389-க்கு இணைக்கவும்.

ஒரு நபருக்கு ஒரு tunnel என்பது சோர்வாக இருக்கும், எனவே ஒரு குழுவிற்குச் சிறந்த பதில் ஒரு private network ஆகும். அந்த box-ஐ self-hosted WireGuard VPN-க்கு பின்னால் வைத்து, அதற்கு tunnel முகவரியான 10.8.0.1-ஐக் கொடுத்து, port=tcp://10.8.0.1:3389-ஐ அமைக்கவும், இதனால் xrdp VPN-க்குள் மட்டுமே பதிலளிக்கும். எப்படியிருந்தாலும், 3389-க்கான firewall விதி இருக்கவே கூடாது. உங்கள் தற்போதைய விதிகள் எதை அனுமதிக்கின்றன என்பதில் உங்களுக்குத் தெரியவில்லை என்றால், ufw firewall basics on a VPS-லிருந்து தொடங்கி, இணைப்பதற்கு முன்பே சரிபார்க்கவும், இணைத்த பிறகு அல்ல.

2 GB VPS-ல் remote desktop எவ்வளவு RAM-ஐப் பயன்படுத்தும்

நீங்கள் தேர்ந்தெடுக்கும் desktop, 2 GB திட்டம் போதுமானதா அல்லது பயனற்றதா என்பதைத் தீர்மானிக்கிறது. கீழே உள்ள எண்கள், Ubuntu 24.04-ல் login செய்தவுடன் பயன்படுத்தப்படும் தோராயமான நினைவக அளவுகள் ஆகும். இவை உங்கள் கணினியில் அளவிடப்பட்டவை அல்ல, வெளியிடப்பட்ட ஒப்பீடுகளிலிருந்து எடுக்கப்பட்டவை. நீங்கள் இணைந்தவுடன் 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-யிலும் இயங்குகின்றன. எனவே, இவை இரண்டிலும் 2 GB கொண்ட கணினியில் browser-ஐ இயக்க போதுமான இடம் உள்ளது. GNOME ஒரு window-ஐத் திறப்பதற்கு முன்பே சுமார் 1,200 MB-யைக் கோருகிறது. 2 GB-ல் இது மீதமுள்ள நினைவகத்திற்காக browser-உடன் போட்டியிடும்.

desktop shell-ஐ விட browser-தான் அதிக நினைவகத்தை எடுத்துக்கொள்கிறது. நவீன browser ஒன்று, ஒரு active tab-க்கு 150 முதல் 400 MB வரை பயன்படுத்துகிறது. எனவே, XFCE இயங்கும் 2 GB VPS-ல் சில tabs-களைத் திறந்தாலே அது swap செய்யத் தொடங்கிவிடும். செயல்முறைகளை (processes) நிறுத்துவதற்குப் பதிலாக கணினி மெதுவாகச் செயல்பட swap-ஐச் சேர்க்கவும்: sudo fallocate -l 2G /swapfile, பிறகு sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile, மற்றும் /etc/fstab-ல் அதற்கு இணையான வரியைச் சேர்க்கவும், அப்போதுதான் reboot செய்த பிறகும் அது நிலைத்திருக்கும். ஏதேனும் ஒரு செயல்முறை எச்சரிக்கையின்றி மறைந்துவிட்டால், dmesg | grep -i "killed process"-ஐ இயக்கவும். அந்த வரி, kernel-ன் out-of-memory killer அதை முடித்துவிட்டது என்பதைக் குறிக்கிறது; பொதுவாக browser-தான் இதற்குப் பலியாகிறது.

CPU மற்றொரு எல்லையாகும், இதை எளிதாகக் குறைத்து மதிப்பிட்டுவிடக் கூடாது. VPS-ல் GPU இல்லாததால், X ஆனது llvmpipe மூலம் software rendering-க்கு மாறுகிறது. அதாவது, ஒவ்வொரு pixel-ஐயும் CPU-வே வரைய வேண்டும். ஒரு பெரிய பக்கத்தை scroll செய்யும்போதும், video பார்க்கும்போதும் அது CPU சுமையாகவே வெளிப்படும், கணினி உறைந்து போவதற்குப் பதிலாக frame rate குறையும். VPS-ல் game விளையாட முடியுமா என்று நீங்கள் யோசித்தால், அதற்கும் இதே தடையேதான் காரணம்: 3D சார்ந்த எதற்கும் இது சாத்தியமில்லை.

xrdp அமர்வில் ஒலி மற்றும் கிளிப்போர்டு

Ubuntu 24.04-ல் ஆடியோவிற்காக PipeWire பயன்படுத்தப்படுகிறது. ஆனால், xrdp-ன் ஒலி திசைமாற்றம் (sound redirection) PulseAudio-விற்காக உருவாக்கப்பட்டது. எனவே, புதிய நிறுவலில் வீடியோ சரியாக வேலை செய்யும், ஆனால் ஒலி கேட்காது. இதற்கான bridge தொகுப்பை Ubuntu வழங்குகிறது.

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

RDP அமர்விலிருந்து முழுமையாக வெளியேறி (log out) மீண்டும் உள்நுழையவும். ஏனெனில், அமர்வு தொடங்கும்போதே இந்த module ஏற்றப்படும். வெறும் reconnect மட்டும் போதாது. அமர்வுக்குள் நுழைந்த பிறகு பின்வருவனவற்றைச் சரிபார்க்கவும்:

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

xrdp என்று பெயரிடப்பட்ட sink-ஐ நீங்கள் பார்க்க வேண்டும். உங்கள் client மூலம் சோதனை ஒலியை (test tone) கேட்க வேண்டும். xrdp sink இல்லை என்றால், இந்த அமர்வில் module ஏற்றப்படவில்லை என்று அர்த்தம். உங்கள் client-ம் ஆடியோவைக் கோர வேண்டும்: இதற்கு xfreerdp3-ல் /sound flag-ஐப் பயன்படுத்த வேண்டும், அல்லது Windows client-ல் Local Resources பிரிவின் கீழ் உள்ள "Remote audio" அமைப்பைச் சரிபார்க்க வேண்டும்.

உங்கள் அமர்வுக்கு xrdp-chansrv இயங்கத் தொடங்கியவுடன், உரை கிளிப்போர்டு (text clipboard) இரு திசைகளிலும் வேலை செய்யும். இதை xrdp உங்களுக்காகத் தொடங்கும். pgrep -a xrdp-chansrv மூலம் இதை உறுதிப்படுத்தவும். அமர்வின் இடையில் copy மற்றும் paste வேலை செய்யவில்லை என்றால், அந்த process நின்றுவிட்டது என்று பொருள்; மீண்டும் இணைப்பதன் மூலம் அது தானாகவே மறுதொடக்கம் செய்யப்படும். உரைக்கு பதிலாக கோப்புகளை நகலெடுப்பது (copying files) drive redirection எனப்படும் தனி channel ஆகும்: xfreerdp3-ல் /drive:home,/home/you உள்ளூர் கோப்புறையை (local folder) remote அமர்வில் mount செய்யும்.

Polkit பாப்-அப் மற்றும் முதல்முறை உள்நுழையும்போது ஏற்படும் பிற தோல்விகள்

முதல்முறை உள்நுழையும்போது பொதுவாக ஏற்படும் ஆச்சரியம் Authentication is required to create a color managed device என்ற உரையாடல் பெட்டி ஆகும். இதற்கான காரணம் குறிப்பிட்டது. Colord service, polkit-இடம் அனுமதி கேட்கிறது; உள்ளூர் அமர்வு (locally seated) என்று கருதப்படும் அமர்வுகளுக்கு மட்டுமே polkit அமைதியாக அனுமதியை வழங்குகிறது. RDP அமர்வு உள்ளூர் அமர்வாகக் கருதப்படாததால், polkit உங்களிடம் கடவுச்சொல்லைக் கேட்கிறது. Ubuntu 24.04-ல் polkit 124 பதிப்பு உள்ளது, இது பழைய உள்ளூர் அதிகார .pkla கோப்புகளை நீக்கிவிட்டது. எனவே, /etc/polkit-1/localauthority/50-local.d/45-allow-colord.pkla-ஐ எழுதச் சொல்லும் எந்த வழிகாட்டியும் 24.04-ல் எந்த மாற்றத்தையும் ஏற்படுத்தாது. அதற்குப் பதிலாக ஒரு JavaScript விதியை எழுதவும்.

/* /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-ஐ இயக்கிவிட்டு மீண்டும் இணைக்கவும். மற்ற இரண்டு தோல்விகளை அவற்றின் அறிகுறிகளைக் கொண்டு அறிந்துகொள்வது அவசியம்.

உள்நுழைவு பெட்டி உங்கள் கடவுச்சொல்லை ஏற்றுக்கொண்டு மீண்டும் அதே இடத்திற்கு வருகிறது. அமர்வு தொடங்கி உடனடியாக முடிந்துவிட்டது. முதலில் /var/log/xrdp-sesman.log-ஐப் படிக்கவும், பிறகு உங்கள் home directory-ல் உள்ள ~/.xsession-errors-ஐப் பார்க்கவும். விடுபட்ட xorgxrdp, நிறுவப்படாத desktop-ஐக் குறிப்பிடும் ~/.xsession, உங்களால் எழுத முடியாத home directory அல்லது நிரம்பிய வட்டு (full disk) போன்றவை இதற்கு காரணமாக இருக்கலாம்.

நீங்கள் இணைக்கும்போது X கர்சருடன் சாம்பல் நிறத் திரை தெரிகிறது. X தொடங்கிவிட்டது, ஆனால் desktop தொடங்கவில்லை. இது மீண்டும் ~/.xsession தொடர்பான சிக்கல்: SSH வழியாக xfce4-session-ஐ நீங்களே இயக்கி, அது காட்டும் பிழைச் செய்தியைப் படிக்கவும்.

self-hosted RustDesk server-ன் செயல்பாடுகள்

RustDesk இரண்டு செயல்முறைகளாகப் பிரிகிறது. hbbs என்பது வாடிக்கையாளர்கள் (clients) பதிவு செய்யும் ID மற்றும் rendezvous server ஆகும். நேரடி peer-to-peer இணைப்பு தோல்வியடையும் போது, அமர்வை (session) கொண்டு செல்லும் relay-ஆக hbbr செயல்படுகிறது. இவை இரண்டிலும் desktop சூழல் இயங்காது. இவை இரண்டும் ஒரே image-லிருந்து வருகின்றன. திட்டத்தின் அதிகாரப்பூர்வ compose file கீழே கொடுக்கப்பட்டுள்ளது; இதில் relay முகவரி உங்கள் 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 அமைப்புகளில் உள்ளிட வேண்டும். இதனுடன் தொடர்புடைய private key ./data/id_ed25519-ல் இருக்கும். தரவு அடைவை (data directory) நீக்கினால், server புதிய ஜோடி சாவிகளை உருவாக்கும்; அப்போது ஒவ்வொரு client-லும் புதிய key-ஐ மீண்டும் உள்ளமைக்க வேண்டியிருக்கும். எனவே அந்த அடைவை backup எடுக்கவும். இது ஒரு வார இறுதி பரிசோதனையாக இல்லாமல், உங்கள் குழுவினர் அனைத்து கணினிகளையும் அணுகும் முதன்மை வழியாக மாறினால், RustDesk relay-ன் பிரத்யேக build முறையைப் பின்பற்றுவது சிறந்தது. இது Ed25519 key கையாளுதல், latest-க்கு பதிலாக pinned image tags பயன்படுத்துதல் மற்றும் உங்கள் திட்டத்திற்குத் தேவையான relay bandwidth ஆகியவற்றை நிர்வகிக்க உதவும்.

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

RustDesk ஏன் nginx அல்லது Traefik-க்கு பின்னால் இயங்காது

ஏற்கனவே அனைத்து சேவைகளுக்கும் ஒரு reverse proxy மூலம் TLS termination செய்யும் பயனர்கள், RustDesk-ஐயும் அவ்வாறே அமைக்க முயன்று தோல்வியடைகிறார்கள். hbbs மற்றும் hbbr ஆகியவை HTTP-க்கு பதிலாக TCP மற்றும் UDP வழியாகத் தங்களுக்குரிய binary protocols-ஐப் பயன்படுத்துகின்றன. இதில் routing செய்வதற்கு Host header கிடையாது, ஆய்வு செய்வதற்கு HTTP request-ம் கிடையாது. எனவே, ஒரு nginx server block அல்லது Traefik HTTP router-ஆல் எதையும் பொருத்த முடியாது. 21116 port-ல் உள்ள UDP listener எந்தவொரு அடுக்கிலும் (layer) HTTP சார்ந்தது அல்ல.

இரண்டு வழிகளில் இதைச் செய்ய முடியும். nginx மூலம் TCP ports-ஐ stream block பயன்படுத்தி forward செய்ய முடியும்; இது வழக்கமான reverse proxy அல்ல, மாறாக layer 4 forwarding ஆகும். மேலும், 21118 மற்றும் 21119 ஆகிய ports-கள் RustDesk web client பயன்படுத்தும் websockets-ஐக் கொண்டுள்ளன. இவை சாதாரண HTTP என்பதால், இவற்றை உங்கள் proxy-க்கு பின்னால் வைக்கலாம். அவ்வாறு செய்யும்போது, firewall விதிகளைச் சேர்த்து proxy-க்கு மட்டும் 21118 மற்றும் 21119 ports-களை அணுக அனுமதி வழங்கவும். ஏனெனில், உண்மையான client முகவரியைக் கண்டறிய websocket இணைப்புகளில் உள்ள X-Real-IP header-ஐ hbbs நம்பியுள்ளது.

கண்டெய்னரில் இயங்கும் தற்காலிக பிரவுசர்

சில நேரங்களில், உங்கள் சொந்த கணினியிலிருந்து தனிமைப்படுத்தப்பட்ட, மாறாத IP முகவரியைக் கொண்ட ஒரு சுத்தமான பிரவுசர் மட்டுமே உங்களுக்குத் தேவைப்படும். ஒரு கண்டெய்னர் பணிச்சூழல் (container 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-ஐயும், 3001 HTTPS-ஐயும் வழங்குகிறது. எந்தவொரு RDP client-ம் இல்லாமலேயே, பிரவுசர் டேப் ஒன்றிலேயே நீங்கள் டெஸ்க்டாப்பை அணுகலாம். இதன் image tags-கள் XFCE, KDE, MATE மற்றும் i3 ஆகியவற்றை பல்வேறு base distributions-ல் வழங்குகின்றன. இந்தத் திட்டத்தின் ஆவணங்கள் இதன் ஆபத்தை வெளிப்படையாகக் கூறுகின்றன: இந்த கண்டெய்னருக்கு host மீது privileged access உள்ளது மற்றும் கடவுச்சொல் இல்லாத sudo வசதியுடன் கூடிய terminal-ஐயும் கொண்டுள்ளது. எனவே, இதை இணையத்தில் பாதுகாப்பற்ற முறையில் நேரடியாக வைக்கக்கூடாது. இதனால்தான் மேலே உள்ள ports அனைத்தும் அனைத்து முகவரிகளிலும் வெளியிடப்படாமல், 127.0.0.1-க்கு மட்டும் பிணைக்கப்பட்டுள்ளன (bound). xrdp-க்கு நீங்கள் பயன்படுத்திய அதே SSH tunnel அல்லது VPN வழியாகவே இதையும் அணுகவும்.

Kasm Workspaces இதே கருத்தாக்கத்தை மிகப் பெரிய அளவில் வழங்குகிறது. இதில் web console, பயனர் கணக்குகள் மற்றும் அமர்வு முடிந்ததும் தானாகவே அழிந்துவிடும் per-session கண்டெய்னர்கள் உள்ளன. இதற்குச் சிறிய VPS-ஐ விட அதிக திறன் கொண்ட கணினி தேவை. ஆகஸ்ட் 2026 நிலவரப்படி, இதற்கான குறைந்தபட்சத் தேவை 2 CPU cores, 4 GB memory மற்றும் 50 GB SSD ஆகும். ஒவ்வொரு பயனர் அமர்வுக்கும் கூடுதலாக 2 cores மற்றும் 2768 MB தேவைப்படும். எனவே, 2 GB RAM கொண்ட திட்டத்தில் இதை இயக்க முடியாது. இதன் நிறுவல் ஒரு 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 வசதி இல்லை. ஒரு குறிப்பிட்ட சூழலில் இது பயனுள்ளதாக இருக்கும்: நீங்கள் இணைப்பைத் துண்டித்த பிறகும் இயங்கிக்கொண்டிருக்கும் ஒரு desktop session தேவைப்படும்போதும், மீண்டும் இணையும்போது அதே session-ஐத் தொடர விரும்பும்போதும் இது உதவும். TigerVNC இதைச் செய்கிறது. vncserver -localhost yes :1 ஆனது Xvnc-ஐ TCP 5901 port-ல் 127.0.0.1 முகவரியுடன் பிணைக்கிறது (bind), மேலும் பிற இடங்களிலிருந்து வரும் இணைப்புகளை நிராகரிக்கிறது. எனவே, ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com-ஐப் பயன்படுத்தி xrdp போலவே இதற்கும் tunnel அமைக்க வேண்டும். VNC port-ஐ ஒருபோதும் பொதுவெளியில் (public) திறக்க வேண்டாம். பெரும்பாலான VNC server-கள் handshake-ன் போது மட்டுமே கடவுச்சொல்லைப் பாதுகாக்கின்றன, அதற்குப் பிறகு எந்தப் பாதுகாப்பும் இல்லை. எனவே, ஒரு public port-ல் இயங்கினால், session-ன் உள்ளடக்கங்களை network-ல் எளிதாகக் கண்டறிய முடியும்.

VPS ஒரு சிறந்த desktop-ஆ?

தினசரி பயன்பாட்டிற்கு இது ஏற்றதல்ல, இதற்கான காரணங்கள் பல உள்ளன. இதில் GPU இல்லாததால், CPU-வே அனைத்து வேலைகளையும் செய்கிறது. ஒவ்வொரு keystroke-ம் network round trip-க்காகக் காத்திருக்க வேண்டும்; SSH-ல் 40 ms latency பெரிய பாதிப்பை ஏற்படுத்தாது, ஆனால் text editor-ல் இது தெளிவாகத் தெரியும். Video இருமுறை compress செய்யப்படுகிறது; முதலில் தளத்தாலும், பிறகு RDP encoder-ஆலும் இது நடக்கிறது. உங்கள் கோப்புகள் உங்களிடம் இல்லாத ஒரு disk-ல் சேமிக்கப்படுகின்றன, மேலும் desktop-ன் அதிகப்படியான பயன்பாடு, web server-க்காக ஒதுக்கப்பட்ட மாதாந்திர bandwidth அளவை விரைவாகக் காலி செய்துவிடும்.

ஒரு தற்காலிக machine-ஆக இதைப் பயன்படுத்தினால் இது மிகவும் சிறந்தது, மேற்சொன்ன அதே காரணங்களே இதற்கும் பொருந்தும். இதன் IP address நிலையானது மற்றும் data centre-க்கு உரியது; ஒரு service-க்கு நிலையான address தேவைப்படும்போது இது அவசியமானது. ஒரு image-லிருந்து சில நிமிடங்களில் machine-ஐ மீண்டும் உருவாக்க முடியும் என்பதால், ஏதேனும் பாதிப்பு ஏற்பட்டால் உங்கள் தரவுகள் வீணாகாது. இது உங்கள் சொந்த hardware-லிருந்து தனிமைப்படுத்தப்பட்டுள்ளது, மேலும் உங்கள் laptop-ஐ மூடினாலும் இது தொடர்ந்து இயங்கும். Hourly billing முறையில் இந்தத் தற்காலிக desktop-ஐக் குறைந்த செலவில் பயன்படுத்தலாம்.

இந்த machine-ஐ எதற்காகப் பயன்படுத்தலாம் என்று நீங்கள் இன்னும் முடிவு செய்யவில்லை என்றால், VPS எதற்குச் சிறந்தது என்பதற்கான நடைமுறைப் பட்டியல்-ஐ desktop-ஐ நிறுவும் முன் படிப்பது நல்லது. ஒரு குறிப்பிட்ட Windows application-க்காக நீங்கள் desktop-ஐத் தேடுகிறீர்கள் என்றால், முதலில் Linux மற்றும் Windows Server-க்கு இடையிலான உண்மையான வேறுபாடுகள்-ஐ ஒப்பிட்டுப் பாருங்கள், ஏனெனில் உரிமம் (licence) உங்கள் செலவை மாற்றக்கூடும்.

FAQ

2 GB VPS-ல் என்னால் remote desktop-ஐ இயக்க முடியுமா?

ஆம், இலகுவான desktop சூழலுடன் இயக்க முடியும். login செய்த பிறகு XFCE அல்லது LXQt சுமார் 300 முதல் 400 MB வரை மட்டுமே பயன்படுத்தும், எனவே சில browser tabs-களைத் திறக்க போதுமான memory இருக்கும். 2 GB-ல் GNOME அல்லது KDE Plasma-வை இயக்கினால், applications-க்கு மிகக் குறைந்த memory-யே மிஞ்சும். 2 GB swap file-ஐச் சேர்க்கவும்; இது memory பற்றாக்குறையின் போது process-களைக் கொல்வதற்குப் பதிலாக, கணினியின் வேகத்தைக் குறைத்துச் சமாளிக்க உதவும். ஏதேனும் process தானாக மறைந்துவிட்டால், kernel-ன் out-of-memory killer-ஐக் கண்டறிய dmesg | grep -i "killed process"-ஐச் சரிபார்க்கவும்.

எனது VPS firewall-ல் 3389 port-ஐத் திறக்க வேண்டுமா?

கூடாது. TCP 3389 port தொடர்ந்து ஸ்கேன் செய்யப்படுகிறது, மேலும் வெளிப்படையான RDP login பக்கம் கடவுச்சொல் ஊகத் தாக்குதலுக்கு (password guessing) வழிவகுக்கும். /etc/xrdp/xrdp.ini-ல் port=tcp://.:3389-ஐ அமைப்பதன் மூலம் xrdp-ஐ 127.0.0.1-ல் மட்டும் கேட்கும்படி செய்யவும். இதை ss -tlnp | grep 3389 மூலம் உறுதிப்படுத்தி, ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com மூலம் அணுகவும். ஒன்று அல்லது இரண்டு பேருக்கு மேல் பயன்படுத்த வேண்டுமெனில், loopback-க்கு பதிலாக WireGuard முகவரியுடன் xrdp-ஐ இணைக்கவும்.

xrdp ஏன் "Authentication is required to create a color managed device" என்று கேட்கிறது?

colord service, polkit-இடம் அனுமதி கேட்கிறது. உள்ளூர் அமர்வுகளுக்கு (locally seated session) மட்டுமே polkit தானாக அனுமதி வழங்கும். RDP அமர்வு உள்ளூர் அமர்வு அல்ல என்பதால், ஒவ்வொரு முறை login செய்யும்போதும் கடவுச்சொல் கேட்கிறது. Ubuntu 24.04-ல் பழைய .pkla தீர்வு வேலை செய்யாது, ஏனெனில் polkit 124-ல் local authority கோப்புகள் நீக்கப்பட்டுவிட்டன. org.freedesktop.color-manager.-ல் தொடங்கும் action ids-களுக்கு polkit.Result.YES-ஐ வழங்கும் JavaScript விதியைக் கொண்ட /etc/polkit-1/rules.d/45-allow-colord.rules கோப்பை உருவாக்கி, பின் 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 நேரடியாக இணைக்க அனுமதிக்கவும். web client பயன்படுத்தும் websocket ports 21118 மற்றும் 21119 ஆகியவை HTTP என்பதால், அவற்றை proxy-க்கு பின்னால் வைக்கலாம். அவ்வாறு செய்தால், proxy மட்டுமே அவற்றை அணுகும் வகையில் firewall-ல் கட்டுப்படுத்தவும், ஏனெனில் hbbs அந்த இணைப்புகளில் X-Real-IP-ஐ நம்புகிறது.

எனது xrdp அமர்வில் ஏன் ஒலி (sound) கேட்கவில்லை?

Ubuntu 24.04-ல் PipeWire பயன்படுத்தப்படுகிறது, ஆனால் xrdp-ன் ஒலி redirection PulseAudio-க்காக உருவாக்கப்பட்டது. எனவே, bridge-ஐ நிறுவும் வரை ஒலி கிடைக்காது. sudo apt install -y pipewire-module-xrdp-ஐ இயக்கி, அமர்விலிருந்து முழுமையாக வெளியேறி மீண்டும் login செய்யவும். ஏனெனில், module அமர்வு தொடங்கும்போதே ஏற்றப்படும், மீண்டும் இணைப்பதன் (reconnect) மூலம் அது இயங்காது. pactl list short sinks மூலம் xrdp என்று பெயரிடப்பட்ட sink உள்ளதா எனச் சரிபார்க்கவும். client ஒலி கோரிக்கையை அனுப்புகிறதா என்பதை உறுதிப்படுத்தவும்; இது xfreerdp3-ல் /sound flag அல்லது Windows client-ல் "Remote audio" விருப்பமாகும்.