Linux VPS پر حقیقی remote desktop کیسے چلائیں

Linux VPS پر remote desktop کا حقیقی مطلب

"Linux VPS پر remote desktop" تلاش کرنے سے دو مختلف قسم کی مصنوعات سامنے آتی ہیں، اور غلط انتخاب آپ کا پورا دن ضائع کر سکتا ہے۔ پہلی قسم remote-access broker ہے۔ RustDesk کا self-hosted server اس کی عام مثال ہے۔ یہ ان دو machines کے درمیان session relay کرتا ہے جو پہلے ہی آپ کی ملکیت میں ہوں، مثلاً آپ کا laptop اور گھر میں موجود PC۔ rented server پر کوئی desktop render نہیں ہوتا۔ یہ دونوں endpoints کو ایک دوسرے سے متعارف کراتا ہے اور جب وہ براہ راست ایک دوسرے تک نہیں پہنچ سکتے تو packets forward کرتا ہے۔ دوسری قسم rented server پر چلنے والا حقیقی graphical desktop ہے۔ اس میں pixels data centre میں render ہوتے ہیں اور آپ تک stream کیے جاتے ہیں۔ اس کے لیے xrdp، VNC (virtual network computing)، یا container workspace استعمال ہوتا ہے۔

ایک سوال دونوں میں فرق واضح کر دیتا ہے۔ جب یہ setup کام کرنے لگے تو mouse pointer کہاں موجود ہوگا؟ اگر وہ آپ کی پہلے سے ملکیت والی machine پر ہو تو آپ کو broker چاہیے۔ اگر وہ خود VPS پر ہو تو آپ کو VPS پر desktop چاہیے۔ ذیل میں زیادہ تر جگہ دوسری صورت کے لیے مختص ہے، کیونکہ اکثر guides اس صورت کو نظرانداز کرتی ہیں۔

آپ کے کام کے لیے کون سا اختیار موزوں ہے

• اپنے relay کے ساتھ RustDesk۔ یہ session کو اجنبی افراد کے چلائے ہوئے public rendezvous server سے گزرنے سے بچاتا ہے، کیونکہ key pair آپ کے پاس ہوتا ہے۔ یہ controlled machine کو محفوظ نہیں بناتا۔ وہ وہی PC رہتا ہے جس پر آپ نے client install کیا ہے، اور اس PC کا موجودہ password ہی استعمال ہوتا ہے۔
• SSH tunnel یا VPN کے ذریعے xrdp۔ یہ آپ کو TCP 3389 کی internet-wide مسلسل scanning اور RDP login box پر password guessing سے بچاتا ہے، کیونکہ یہ port کبھی internet کے سامنے نہیں آتا۔ یہ کمزور account password کو اس شخص سے محفوظ نہیں کرتا جسے پہلے ہی tunnel تک رسائی حاصل ہو۔
• اسی tunnel کے ذریعے VNC۔ یہ آپ کو ایسا desktop session فراہم کرتا ہے جو connection منقطع ہونے کے بعد بھی برقرار رہتا ہے، اور اس میں RDP سے پرانا اور سادہ protocol استعمال ہوتا ہے۔ یہ اکیلا کسی چیز کو محفوظ نہیں کرتا۔ تمام security tunnel فراہم کرتی ہے، اس لیے public port پر صرف VNC چلانا یہاں بدترین اختیار ہے۔
• Webtop یا Kasm جیسا container workspace۔ یہ آپ کو browser یا مکمل desktop ایک ایسے container میں فراہم کرتا ہے جسے آپ ختم کرکے دوبارہ build کر سکتے ہیں۔ اس سے آپ کی اصل machine اس browser کے چھونے والی چیزوں سے محفوظ رہتی ہے۔ یہ host کو محفوظ نہیں کرتا۔ یہ images وسیع privileges کے ساتھ چلتی ہیں اور ان کے اندر passwordless sudo ہوتا ہے، اس لیے hostile workload کے لیے container کو قابلِ اعتماد boundary نہیں سمجھنا چاہیے۔

Ubuntu 24.04 پر xrdp اور XFCE انسٹال کریں

VPS سرور image میں graphical desktop شامل نہیں ہوتا۔ پہلے desktop انسٹال کریں، پھر xrdp انسٹال کریں۔ xrdp ایک open-source سرور ہے جو 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 ہے جسے xrdp نیا session شروع کرنے کے لیے چلاتا ہے۔ اس کے بغیر login box آپ کا password قبول کرنے کے بعد دوبارہ login box دکھاتا ہے۔

اب session کو بتائیں کہ کون سا desktop شروع کرنا ہے۔ xrdp /etc/xrdp/startwm.sh چلاتا ہے، اور اگر وہ file موجود ہو تو ~/.xsession چلاتا ہے۔

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

آخر میں، xrdp کو وہ TLS (transport layer security) key پڑھنے کی ضرورت ہوتی ہے جو یہ clients کو فراہم کرتا ہے۔ اس file کا 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 اس failure کو snakeoil filename والی line میں record کرتا ہے۔

انٹرنیٹ کے لیے port 3389 کیوں نہیں کھولنا چاہیے

TCP 3389 کو انٹرنیٹ پر موجود ہر نظام مسلسل scan کرتا ہے، اور RDP کا login box ہر password attempt کا جواب دیتا ہے۔ اسے نہ کھولیں۔ اس کے بجائے 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 ہونے سے 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 پر 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 پر اعتماد کرنے کو کہتا ہے اور 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 کے ذریعے منتقل کریں اور 127.0.0.1:13389 سے connect کریں۔

ہر شخص کے لیے الگ tunnel بنانا مشکل ہو جاتا ہے، اس لیے team کے لیے private network بہتر حل ہے۔ machine کو 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 کی بنیادی باتیں سے آغاز کریں، اور connect کرنے سے پہلے جانچ کریں، بعد میں نہیں۔

2 GB VPS پر remote desktop کتنی RAM استعمال کرتا ہے

آپ کا منتخب کردہ desktop یہ طے کرتا ہے کہ 2 GB plan قابلِ استعمال رہے گا یا بالکل ناکافی ثابت ہوگا۔ ذیل کے اعداد Ubuntu 24.04 پر login کے فوراً بعد memory کے عام استعمال کی تقریباً مقدار ہیں۔ یہ اعداد شائع شدہ موازنوں سے لیے گئے ہیں، آپ کی machine پر براہِ راست پیمائش نہیں کی گئی۔ Connect ہونے کے فوراً بعد اپنی machine پر 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 desktops میں فرق ہی اصل نکتہ ہے۔ LXQt تقریباً 300 MB اور XFCE تقریباً 400 MB استعمال کرتا ہے، اس لیے دونوں 2 GB machine پر browser کے لیے جگہ چھوڑتے ہیں۔ GNOME ایک بھی window کھولنے سے پہلے تقریباً 1,200 MB چاہتا ہے۔ 2 GB پر اس کے بعد browser باقی memory کے لیے desktop کے ساتھ مقابلہ کرتا ہے۔

اصل لاگت desktop shell نہیں بلکہ browser ہے۔ جدید browser ہر active tab کے لیے عموماً 150 سے 400 MB استعمال کرتا ہے، اس لیے XFCE چلانے والا 2 GB VPS چند tabs تک ٹھیک رہتا ہے اور پھر swapping شروع کر دیتا ہے۔ Swap شامل کریں تاکہ machine processes ختم کرنے کے بجائے سست ہو جائے: sudo fallocate -l 2G /swapfile، پھر sudo chmod 600 /swapfile، sudo mkswap /swapfile، sudo swapon /swapfile چلائیں، اور /etc/fstab میں متعلقہ line شامل کریں تاکہ reboot کے بعد بھی یہ برقرار رہے۔ اگر کوئی چیز بغیر warning کے غائب ہو جائے تو dmesg | grep -i "killed process" چلائیں۔ اس line کا مطلب ہے کہ kernel کے out-of-memory killer نے اسے ختم کیا۔ عموماً browser ہی متاثر ہوتا ہے۔

CPU دوسری حد ہے، اور اس کا اندازہ لگانا زیادہ آسانی سے غلط ہو جاتا ہے۔ VPS میں GPU نہیں ہوتا، اس لیے X، llvmpipe کے ذریعے software rendering پر واپس آ جاتا ہے۔ اس کا مطلب ہے کہ CPU ہر pixel خود draw کرتا ہے۔ بھاری page کو scroll کرنا اور video چلانا دونوں براہِ راست CPU load میں ظاہر ہوتے ہیں۔ Machine freeze ہونے کے بجائے frame rate کم ہو جاتا ہے۔ یہی وہ حد ہے جس کا سامنا VPS پر game چلانے کے امکان کے بارے میں سوچتے وقت ہوتا ہے: 3D کام کے لیے جواب نہیں ہے، اور وجہ بھی یہی ہے۔

xrdp سیشن میں آواز اور clipboard

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 کریں، کیونکہ module سیشن شروع ہوتے وقت load ہوتا ہے۔ صرف reconnect کرنا کافی نہیں ہے۔ اس کے بعد سیشن کے اندر یہ command چلائیں:

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

آپ کو ایسا sink نظر آنا چاہیے جس کے نام میں xrdp شامل ہو، اور test tone آپ کے client کے ذریعے سنائی دینی چاہیے۔ اگر xrdp sink موجود نہیں ہے تو module اس سیشن میں load نہیں ہوا۔ آپ کے client کو audio کی درخواست بھی کرنی ہوگی۔ یہ /sound کا xfreerdp3 flag ہے، یا Windows client میں Local Resources کے تحت "Remote audio" setting ہے۔

Text clipboard دونوں سمتوں میں اس وقت کام کرتا ہے جب آپ کے سیشن کے لیے xrdp-chansrv چل رہا ہو۔ xrdp اسے خود شروع کرتا ہے۔ pgrep -a xrdp-chansrv سے اس کی تصدیق کریں۔ اگر سیشن کے دوران copy اور paste کام کرنا بند کر دیں تو یہ process ختم ہو چکا ہے، اور reconnect کرنے سے یہ دوبارہ شروع ہو جاتا ہے۔ Text کے بجائے files copy کرنا ایک الگ channel ہے جسے drive redirection کہتے ہیں: xfreerdp3 پر /drive:home,/home/you ایک local folder کو remote session میں mount کرتا ہے۔

polkit کا popup اور پہلی login کی دیگر ناکامیاں

پہلی login کے وقت سب سے عام حیرت ایک ایسا dialog ہے جس میں Authentication is required to create a color managed device لکھا ہوتا ہے۔ اس کی وجہ مخصوص ہے۔ colord service اجازت کے لیے polkit سے درخواست کرتی ہے۔ polkit یہ action خاموشی سے صرف اس session کو منظور کرتا ہے جسے وہ locally seated سمجھتا ہے۔ RDP session seated نہیں ہوتا، اس لیے polkit آپ سے password طلب کرتا ہے۔ Ubuntu 24.04 کے ساتھ polkit 124 جاری ہوتا ہے، جس نے پرانی local authority .pkla files ہٹا دی ہیں۔ اس لیے ہر وہ guide جو آپ کو /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 کریں۔ دو دیگر ناکامیاں ہیں جنہیں ان کی علامت سے پہچاننا مفید ہے۔

login box آپ کا password قبول کرتا ہے اور فوراً واپس آ جاتا ہے۔ session شروع ہوا اور بند ہو گیا۔ پہلے /var/log/xrdp-sesman.log پڑھیں، پھر اپنی home directory میں ~/.xsession-errors پڑھیں۔ xorgxrdp کا missing ہونا، ~/.xsession میں ایسے desktop کا نام ہونا جو installed نہیں ہے، ایسی home directory جس میں آپ لکھ نہیں سکتے، یا disk کا بھر جانا، سب اسی نتیجے تک پہنچتے ہیں۔

آپ connect کرتے ہیں اور X cursor کے ساتھ grey screen دیکھتے ہیں۔ X شروع ہوا، لیکن desktop شروع نہیں ہوا۔ یہ پھر ~/.xsession ہے: SSH کے ذریعے دستی طور پر xfce4-session چلائیں اور اس کی ظاہر کردہ error پڑھیں۔

خود میزبان RustDesk سرور کیا کرتا ہے

RustDesk دو processes میں تقسیم ہوتا ہے۔ hbbs ID اور rendezvous server ہے، جس کے ساتھ clients register کرتے ہیں، جبکہ hbbr وہ relay ہے جو direct peer-to-peer connection ناکام ہونے پر session کو منتقل کرتا ہے۔ ان میں سے کوئی بھی desktop نہیں چلاتا۔ دونوں ایک ہی image سے آتے ہیں۔ یہ وہ compose file ہے جسے project publish کرتا ہے، اور اس میں 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 پڑھیں جو server نے پہلی بار start ہونے پر generate کی تھی:

sudo docker compose up -d
sudo cat ./data/id_ed25519.pub

ہر client میں RustDesk client کی Network settings کے تحت آپ کا host name اور وہ public key درج کرنا ضروری ہے۔ متعلقہ private key ./data/id_ed25519 میں رہتی ہے۔ data directory حذف کرنے پر server نیا key pair generate کرتا ہے، اس لیے ہر client کو نئی key کے ساتھ دوبارہ configure کرنا پڑتا ہے۔ اس directory کا backup رکھیں۔

Firewall کو ان ports پر براہِ راست رسائی کی اجازت دینی ہوگی۔ hbbs، TCP ports 21115، 21116 اور 21118، اور UDP port 21116 استعمال کرتا ہے۔ hbbr، TCP ports 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 کے پاس match کرنے کے لیے کچھ نہیں ہوتا۔ 21116 پر UDP listener کسی بھی سطح پر HTTP سے متعلق نہیں ہے۔

دو طریقے کام کرتے ہیں۔ nginx stream block کے ذریعے TCP ports forward کر سکتا ہے۔ یہ معمول کے مفہوم میں reverse proxy کے بجائے سادہ layer 4 forwarding ہے۔ دوسری طرف، 21118 اور 21119 ports RustDesk web client کے لیے استعمال ہونے والے websockets منتقل کرتے ہیں۔ یہ عام HTTP ہے، اس لیے ان دونوں کو proxy کے پیچھے رکھا جا سکتا ہے۔ ایسا کرنے کی صورت میں firewall rules شامل کریں تاکہ صرف proxy ہی 21118 اور 21119 تک پہنچ سکے، کیونکہ websocket connections پر حقیقی 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 tags میں کئی base distributions پر XFCE، KDE، MATE اور i3 شامل ہیں۔ project کی اپنی documentation اس خطرے کو واضح طور پر بیان کرتی ہے: کنٹینر کو host تک privileged access حاصل ہے اور اس میں password کے بغیر sudo والا terminal شامل ہے۔ اس لیے اسے غیر محفوظ حالت میں internet پر expose نہیں کرنا چاہیے۔ اسی وجہ سے اوپر والے ports کو تمام addresses پر publish کرنے کے بجائے 127.0.0.1 سے bind کیا گیا ہے۔ اسے اسی SSH tunnel یا اسی VPN کے ذریعے access کریں جو آپ نے xrdp کے لیے استعمال کیا تھا۔

Kasm Workspaces بھی یہی تصور بہت بڑے scale پر فراہم کرتا ہے۔ اس میں web console، user accounts اور ہر session کے لیے ایسے containers شامل ہیں جو session ختم ہونے پر reset ہو جاتے ہیں۔ اسے ایک چھوٹے VPS کے مقابلے میں زیادہ machine resources درکار ہوتے ہیں۔ 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 ڈرائنگ کمانڈز کے بجائے framebuffer updates بھیجتا ہے، اس لیے سست لنک پر یہ RDP کے مقابلے میں زیادہ بھاری محسوس ہوتا ہے، اور اس میں sound channel بھی نہیں ہوتا۔ یہ ایک صورت میں مفید ہے: آپ ایسا desktop session چاہتے ہیں جو disconnect ہونے کے بعد بھی چلتا رہے، اور واپس آنے پر وہی 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 کو کبھی public نہ کریں۔ زیادہ تر VNC servers handshake کے دوران password کو محفوظ رکھتے ہیں، لیکن اس کے بعد آنے والے کسی بھی data کو محفوظ نہیں کرتے۔ اس لیے public port پر session کا content network پر پڑھا جا سکتا ہے۔

کیا VPS ایک اچھا desktop ہے؟

روزمرہ استعمال کے لیے نہیں، اور اس کی وجوہات متعدد ہیں۔ GPU موجود نہیں ہوتا، اس لیے CPU تمام rendering کرتا ہے۔ ہر keystroke کے لیے network round trip کا انتظار کرنا پڑتا ہے، اور 40 ms latency جو SSH میں قابلِ قبول محسوس ہوتی ہے، text editor میں نمایاں ہو جاتی ہے۔ Video دو مرتبہ compress ہوتی ہے: پہلے site اسے compress کرتی ہے، پھر RDP encoder۔ آپ کی files ایسی disk پر موجود ہوتی ہیں جس پر آپ کا براہِ راست اختیار نہیں ہوتا، اور desktop کا زیادہ استعمال ماہانہ bandwidth allowance تیزی سے ختم کر دیتا ہے، جبکہ یہ allowance عموماً web server کے لیے مقرر کیا گیا ہوتا ہے۔

عارضی طور پر استعمال اور پھر ختم کر دینے والی machine کے طور پر یہ بہت اچھی ہے، اور یہی خصوصیات اس کی وجہ بھی ہیں۔ IP address مستقل ہوتا ہے اور data centre سے تعلق رکھتا ہے، جو اس وقت مطلوب ہوتا ہے جب کسی service کو مستقل address نظر آنا چاہیے۔ Machine چند منٹ میں image سے دوبارہ build ہو جاتی ہے، اس لیے اگر کسی session میں خطرناک چیز شامل ہو جائے تو اسے ختم کرنے کی لاگت تقریباً کچھ نہیں ہوتی۔ یہ آپ کے حقیقی hardware سے الگ رہتی ہے اور laptop بند ہونے کے بعد بھی چلتی رہتی ہے۔ Hourly billing عارضی desktop کو کم خرچ بناتی ہے۔

اگر آپ ابھی یہ طے کر رہے ہیں کہ اس machine کا مقصد کیا ہے تو desktop install کرنے سے پہلے VPS کے عملی استعمالات کی فہرست پڑھنا مفید ہوگا۔ اگر desktop کی ضرورت کی وجہ صرف ایک Windows application تھی تو پہلے Linux اور Windows Server کے درمیان حقیقی فرق کا جائزہ لیں، کیونکہ licence جواب کی لاگت تبدیل کر دیتا ہے۔

FAQ

کیا میں 2 GB VPS پر remote desktop چلا سکتا ہوں؟

ہاں، light desktop کے ساتھ۔ XFCE یا LXQt login کے بعد تقریباً 300 سے 400 MB استعمال کرتے ہیں، جس سے چند tabs والے browser کے لیے کافی memory بچ جاتی ہے۔ 2 GB پر GNOME یا KDE Plasma ایپلی کیشنز کے لیے تقریباً کوئی 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 کیا جاتا ہے، اور exposed RDP login box password guessing کو دعوت دیتا ہے۔ /etc/xrdp/xrdp.ini میں port=tcp://.:3389 set کریں تاکہ 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 یہ action صرف locally seated session کو خاموشی سے اجازت دیتا ہے۔ RDP session seated نہیں ہوتا، اس لیے ہر login پر password prompt ظاہر ہوتا ہے۔ Ubuntu 24.04 پر پرانا .pkla fix کوئی اثر نہیں کرتا، کیونکہ polkit 124 نے local authority files کا support ختم کر دیا ہے۔ /etc/polkit-1/rules.d/45-allow-colord.rules بنائیں، جس میں ایسی JavaScript rule ہو جو org.freedesktop.color-manager. سے شروع ہونے والے action ids کے لیے polkit.Result.YES واپس کرے، پھر 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 start پر load ہوتا ہے اور reconnect اسے load نہیں کرے گا۔ xrdp نام والے sink کے لیے pactl list short sinks سے چیک کریں، اور یقینی بنائیں کہ client audio کی درخواست کرتا ہے۔ xfreerdp3 پر یہ /sound flag ہے، یا Windows client میں "Remote audio" اختیار ہے۔