Linux VPS پر xrdp اور XFCE سے Remote Desktop

Linux VPS پر remote desktop کا اصل مطلب

"Linux VPS پر remote desktop" تلاش کرنے پر دو مختلف قسم کی مصنوعات سامنے آتی ہیں، اور غلط انتخاب سے آپ کا پورا دوپہر ضائع ہو سکتا ہے۔ پہلی قسم remote-access broker ہے۔ RustDesk کا self-hosted server اس کی عام مثال ہے۔ یہ آپ کے پہلے سے موجود دو computers، مثلاً laptop اور گھر کے PC، کے درمیان session relay کرتا ہے۔ 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 کہاں موجود ہوتا ہے؟ اگر pointer آپ کے پہلے سے موجود کسی machine پر ہو تو آپ کو broker چاہیے۔ اگر pointer خود VPS پر ہو تو آپ کو VPS پر desktop چاہیے۔ ذیل میں زیادہ تر جگہ دوسری صورت کے لیے مختص ہے، کیونکہ اکثر guides اسی صورت کو نظرانداز کرتی ہیں۔

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

• اپنے relay کے ساتھ RustDesk۔ یہ سیشن کو اجنبی افراد کے چلائے ہوئے public rendezvous server سے گزرنے سے محفوظ رکھتا ہے، کیونکہ key pair آپ کے پاس ہوتا ہے۔ یہ control کی جانے والی 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 استعمال ہوتا ہے۔ یہ بذاتِ خود کسی چیز کو محفوظ نہیں رکھتا۔ سکیورٹی کا تمام کام tunnel کرتا ہے، اس لیے public port پر اکیلا VNC یہاں بدترین اختیار ہے۔
• Webtop یا Kasm جیسا container workspace۔ یہ آپ کو ایسے container میں browser یا مکمل desktop فراہم کرتا ہے جسے آپ ختم کرکے دوبارہ build کر سکتے ہیں۔ اس طرح آپ کی اصل machine اس browser کے touch کیے ہوئے مواد سے محفوظ رہتی ہے۔ یہ host کو محفوظ نہیں رکھتا۔ یہ images وسیع privileges کے ساتھ چلتی ہیں اور ان کے اندر passwordless sudo موجود ہوتا ہے، اس لیے hostile workload کے لیے container کو قابلِ اعتماد boundary نہیں سمجھنا چاہیے۔

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

VPS server image میں graphical desktop شامل نہیں ہوتا۔ پہلے desktop انسٹال کریں، پھر xrdp انسٹال کریں۔ xrdp ایک open-source server ہے جو 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 کو اس line میں snakeoil filename کے ساتھ درج کرتا ہے۔

آپ کو 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

فراہم کردہ file اپنے comments میں اس syntax کی وضاحت کرتی ہے: 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 نے آپ کی ترمیم نظرانداز کر دی۔ عموماً اس کی وجہ یہ ہوتی ہے کہ 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 پر پہلے سے کوئی چیز 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 کی بنیادی باتوں سے آغاز کریں اور 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 میں اصل فرق memory استعمال کا ہے۔ 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 شامل کریں تاکہ processes ختم ہونے کے بجائے machine سست ہو جائے: sudo fallocate -l 2G /swapfile، پھر sudo chmod 600 /swapfile، sudo mkswap /swapfile، sudo swapon /swapfile چلائیں، اور /etc/fstab میں متعلقہ line شامل کریں تاکہ reboot کے بعد بھی swap برقرار رہے۔ اگر کوئی process بغیر warning کے غائب ہو جائے تو dmesg | grep -i "killed process" چلائیں۔ اس کا مطلب ہے کہ kernel کے out-of-memory killer نے اسے ختم کیا ہے، اور عموماً browser ہی متاثر ہوتا ہے۔

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

xrdp سیشن میں آواز اور کلپ بورڈ

Ubuntu 24.04 آڈیو کے لیے PipeWire استعمال کرتا ہے، جبکہ xrdp کی sound redirection کو PulseAudio کے مطابق بنایا گیا تھا۔ اس لیے نئی installation میں ویڈیو کام کرتی ہے لیکن آواز نہیں آتی۔ 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

آپ کو ایسا 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 کہتے ہیں: /drive:home,/home/you میں xfreerdp3 ایک local folder کو remote session میں mount کرتا ہے۔

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

پہلی login کے وقت سب سے عام حیرت ایک ایسا dialog ہے جس میں Authentication is required to create a color managed device لکھا ہوتا ہے۔ اس کی وجہ مخصوص ہے۔ colord service اجازت کے لیے polkit سے درخواست کرتی ہے۔ polkit یہ action خاموشی سے صرف اس session کو منظور کرتا ہے جسے وہ مقامی طور پر موجود سمجھتا ہے۔ RDP session کو مقامی طور پر موجود نہیں سمجھا جاتا، اس لیے 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 کا غائب ہونا، ~/.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 کا network traffic منتقل کرتا ہے۔ دونوں میں desktop نہیں چلتا۔ دونوں ایک ہی image سے آتے ہیں۔ یہ وہ compose file ہے جسے project شائع کرتا ہے، تاہم 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 رکھیں۔ اگر یہ weekend experiment کے بجائے آپ کی team کے لیے ہر machine تک رسائی کا مستقل طریقہ بن جائے، تو RustDesk relay کی dedicated build استعمال کرنا مفید ہے۔ اس میں Ed25519 key handling، latest کے بجائے pinned image tags، اور آپ کے plan کے مطابق ادا کی جانے والی relay bandwidth شامل ہے۔

Firewall کو ان ports پر براہ راست traffic کی اجازت دینی ہوگی۔ 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 کے بجائے TCP اور UDP پر اپنے binary protocols استعمال کرتے ہیں۔ routing کے لیے کوئی Host header موجود نہیں ہوتا اور نہ ہی جانچنے کے لیے کوئی HTTP request ہوتی ہے، اس لیے nginx کے پاس server block یا Traefik کے HTTP router کو match کرنے کے لیے کچھ نہیں ہوتا۔ 21116 پر UDP listener کسی بھی layer پر HTTP نہیں ہے۔

دو طریقے کام کرتے ہیں۔ nginx stream block کے ذریعے TCP ports forward کر سکتا ہے، جو معمول کے مفہوم میں reverse proxy کے بجائے سادہ layer 4 forwarding ہے۔ 21118 اور 21119 ports RustDesk web client کے لیے استعمال ہونے والے websockets لے کر چلتے ہیں۔ یہ عام HTTP ہے، اس لیے یہ دونوں ports آپ کے proxy کے پیچھے رکھے جا سکتے ہیں۔ اگر آپ ایسا کریں تو firewall rules شامل کریں تاکہ صرف proxy ہی 21118 اور 21119 تک پہنچ سکے، کیونکہ websocket connections پر حقیقی client address معلوم کرنے کے لیے hbbs X-Real-IP header پر اعتماد کرتا ہے۔

کنٹینر میں عارضی browser

کبھی آپ کو صرف ایک صاف browser درکار ہوتا ہے جس کا IP تبدیل نہ ہو اور جو آپ کی اپنی مشین سے الگ رکھا جائے۔ کنٹینر workspace یہ کام بہت کم اضافی software کے ساتھ کرتا ہے۔ 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 حاصل ہوتا ہے اور اس میں passwordless sudo والا terminal شامل ہے، اس لیے اسے غیر محفوظ حالت میں internet پر expose نہیں کرنا چاہیے۔ اسی وجہ سے اوپر والے ports کو تمام addresses پر publish کرنے کے بجائے 127.0.0.1 سے bind کیا گیا ہے۔ اسے اسی SSH tunnel یا اسی VPN کے ذریعے access کریں جسے آپ نے xrdp کے لیے استعمال کیا تھا۔

Kasm Workspaces بھی یہی تصور بہت بڑے پیمانے پر پیش کرتا ہے۔ اس میں 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 ڈرائنگ 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 کریں۔ VNC port کو کبھی public نہ کریں۔ زیادہ تر VNC servers handshake کے دوران password کو محفوظ رکھتے ہیں، لیکن اس کے بعد آنے والے کسی بھی data کو محفوظ نہیں کرتے۔ اس لیے public port پر session کا content network پر پڑھا جا سکتا ہے۔

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

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

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

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

FAQ

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

ہاں، ہلکے 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 کے ذریعے اس تک پہنچیں۔ اگر users کی تعداد ایک یا دو سے زیادہ ہو تو xrdp کو loopback کے بجائے WireGuard address پر bind کریں۔

xrdp کیوں پوچھتا ہے: "Authentication is required to create a color managed device"?

colord service اجازت کے لیے 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 نہیں ہوگا۔ pactl list short sinks سے ایسا sink تلاش کریں جس کے نام میں xrdp ہو، اور یقینی بنائیں کہ client audio کی درخواست کرتا ہے۔ xfreerdp3 پر یہ /sound flag ہے، یا Windows client میں "Remote audio" اختیار ہے۔