SSD Nodes Learn 🎉 VPS เริ่ม $5.50/เดือน
คู่มือ Matt Connorโดย Matt Connor

วิธีติดตั้ง Remote Desktop บน Linux VPS ด้วย xrdp และ XFCE

เรียนรู้วิธีติดตั้งสภาพแวดล้อมเดสก์ท็อปแบบกราฟิกบน Linux VPS ด้วย xrdp และ XFCE พร้อมเทคนิคการทำ SSH Tunnel เพื่อความปลอดภัยแทนการเปิดพอร์ต 3389 โดยตรง และเปรียบเทียบการใช้งาน RustDesk

ความหมายที่แท้จริงของ Remote Desktop บน Linux VPS

มีผลิตภัณฑ์สองประเภทที่ปรากฏขึ้นเมื่อค้นหาคำว่า "remote desktop on a Linux VPS" และการเลือกผิดประเภทจะทำให้คุณเสียเวลาไปเปล่าๆ ตลอดทั้งบ่าย ประเภทแรกคือตัวกลางสำหรับการเข้าถึงระยะไกล (remote-access broker) ตัวอย่างที่พบบ่อยคือการติดตั้ง RustDesk server ด้วยตนเอง ซึ่งทำหน้าที่ส่งต่อเซสชันระหว่างเครื่องสองเครื่องที่คุณมีอยู่แล้ว เช่น แล็ปท็อปของคุณกับคอมพิวเตอร์ที่บ้าน โดยตัวเซิร์ฟเวอร์ที่เช่ามาจะไม่ได้แสดงผลหน้าจอเดสก์ท็อปใดๆ เลย แต่จะทำหน้าที่เชื่อมต่อปลายทางทั้งสองเข้าหากันและส่งต่อแพ็กเก็ตข้อมูลในกรณีที่เครื่องทั้งสองไม่สามารถติดต่อกันได้โดยตรง ประเภทที่สองคือเดสก์ท็อปแบบกราฟิกที่ทำงานอยู่บนเซิร์ฟเวอร์ที่เช่ามาจริงๆ ซึ่งหมายความว่าพิกเซลจะถูกประมวลผลในศูนย์ข้อมูลและสตรีมมายังเครื่องของคุณ ตัวอย่างเช่น xrdp, VNC (virtual network computing) หรือ container workspace

มีคำถามหนึ่งข้อที่ใช้แยกความแตกต่างระหว่างสองประเภทนี้ เมื่อตั้งค่าเสร็จสิ้นแล้ว ตัวชี้เมาส์ของคุณอยู่ที่ไหน หากต้องการใช้งานบนเครื่องที่คุณมีอยู่แล้ว คุณต้องใช้ตัวกลาง (broker) แต่หากต้องการใช้งานบนตัว VPS เอง คุณต้องติดตั้งเดสก์ท็อปบน VPS นั้นๆ เนื้อหาในส่วนถัดไปจะเน้นไปที่กรณีที่สองเป็นหลัก เนื่องจากเป็นกรณีที่คู่มือส่วนใหญ่มักข้ามไป

ตัวเลือกใดที่เหมาะสมกับงานของคุณ

  • RustDesk พร้อม relay ของคุณเอง: วิธีนี้ช่วยป้องกันไม่ให้เซสชันผ่านเซิร์ฟเวอร์ rendezvous สาธารณะที่ดำเนินการโดยบุคคลภายนอก เนื่องจากคุณเป็นผู้ถือครองกุญแจคู่ (key pair) อย่างไรก็ตาม วิธีนี้ไม่ได้ช่วยป้องกันเครื่องที่ถูกควบคุม ซึ่งยังคงเป็นเครื่อง PC ที่คุณติดตั้งไคลเอนต์ไว้ และยังคงใช้รหัสผ่านเดิมของเครื่องนั้น
  • xrdp ผ่าน SSH tunnel หรือ VPN: วิธีนี้ช่วยป้องกันคุณจากการสแกนพอร์ต TCP 3389 บนอินเทอร์เน็ตอย่างต่อเนื่อง และป้องกันการเดารหัสผ่านที่หน้าล็อกอิน RDP เนื่องจากพอร์ตดังกล่าวจะไม่เปิดรับการเชื่อมต่อจากอินเทอร์เน็ตโดยตรง แต่ไม่ได้ช่วยป้องกันบัญชีที่รหัสผ่านอ่อนแอจากผู้ที่มีสิทธิ์เข้าถึง tunnel นั้นอยู่แล้ว
  • VNC ผ่าน tunnel เดียวกัน: วิธีนี้ให้เซสชันเดสก์ท็อปที่ยังคงอยู่แม้จะตัดการเชื่อมต่อ โดยใช้โปรโตคอลที่เก่าและเรียบง่ายกว่า RDP ในตัวมันเองไม่ได้ให้การป้องกันใดๆ: tunnel ทำหน้าที่รักษาความปลอดภัยทั้งหมด ดังนั้นการใช้ VNC บนพอร์ตสาธารณะเพียงอย่างเดียวจึงเป็นตัวเลือกที่แย่ที่สุดในที่นี้
  • พื้นที่ทำงานแบบคอนเทนเนอร์ เช่น Webtop หรือ Kasm: วิธีนี้ให้เบราว์เซอร์หรือเดสก์ท็อปทั้งระบบภายในคอนเทนเนอร์ที่คุณสามารถลบทิ้งและสร้างใหม่ได้ ซึ่งช่วยป้องกันเครื่องจริงของคุณจากสิ่งที่เบราว์เซอร์นั้นเข้าถึง แต่ไม่ได้ช่วยป้องกันโฮสต์: อิมเมจเหล่านี้ทำงานด้วยสิทธิ์ที่กว้างขวางและมี sudo ที่ไม่มีรหัสผ่านอยู่ภายใน ดังนั้นคอนเทนเนอร์จึงไม่ใช่ขอบเขตที่คุณควรไว้วางใจหากต้องรับมือกับภาระงานที่เป็นอันตราย

การติดตั้ง xrdp และ XFCE บน Ubuntu 24.04

อิมเมจของ VPS มักไม่มีหน้าจอเดสก์ท็อปมาให้ คุณต้องติดตั้งเดสก์ท็อปก่อน จากนั้นจึงติดตั้ง xrdp ซึ่งเป็นเซิร์ฟเวอร์โอเพนซอร์สที่สื่อสารด้วยโปรโตคอล RDP (Remote Desktop Protocol) เช่นเดียวกับที่ไคลเอนต์ Windows ใช้งาน โดยทั่วไปจะเลือกใช้เดสก์ท็อปที่มีน้ำหนักเบา ซึ่ง XFCE เป็นตัวเลือกมาตรฐานที่นิยมใช้กัน

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

Ubuntu 24.04 มาพร้อมกับ xrdp 0.9.24 และ xorgxrdp ในส่วนประกอบ universe ณ เดือนสิงหาคม 2026 ให้ติดตั้ง xorgxrdp โดยระบุชื่อแพ็กเกจแม้ว่าจะเป็นเพียงแพ็กเกจที่แนะนำก็ตาม เนื่องจากเป็นแบ็กเอนด์ของ X server ที่ xrdp จะเรียกใช้งานเมื่อเริ่มเซสชันใหม่ หากไม่มีแพ็กเกจนี้ หน้าจอเข้าสู่ระบบจะยอมรับรหัสผ่านของคุณ แต่จะดีดกลับมาที่หน้าจอเข้าสู่ระบบทันที

จากนั้นกำหนดค่าให้เซสชันทราบว่าจะเริ่มเดสก์ท็อปตัวใด โดย xrdp จะรัน /etc/xrdp/startwm.sh ซึ่งจะเรียกใช้งาน ~/.xsession หากไฟล์ดังกล่าวมีอยู่จริง

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

สุดท้าย xrdp จำเป็นต้องอ่านคีย์ TLS (Transport Layer Security) เพื่อนำเสนอต่อไคลเอนต์ ไฟล์ดังกล่าวต้องมีโหมด 640 และเป็นกรรมสิทธิ์ของกลุ่ม ssl-cert

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

รายการแสดงให้เห็น -rw-r----- 1 root ssl-cert หาก id xrdp ไม่แสดง ssl-cert ในกลุ่มที่ระบุ ให้รันคำสั่ง sudo adduser xrdp ssl-cert ตามด้วย sudo systemctl restart xrdp หากข้ามขั้นตอนนี้ไป xrdp จะไม่สามารถเปิดคีย์ได้ และ /var/log/xrdp.log จะบันทึกความล้มเหลวโดยระบุชื่อไฟล์ snakeoil ไว้ในบรรทัดดังกล่าว

เหตุผลที่คุณไม่ควรเปิดพอร์ต 3389 สู่สาธารณะ

พอร์ต TCP 3389 ถูกสแกนอย่างต่อเนื่องจากทุกแหล่งบนอินเทอร์เน็ต และหน้าต่างล็อกอิน RDP จะตอบรับทุกความพยายามในการเดารหัสผ่านอย่างสุภาพ ห้ามเปิดพอร์ตนี้โดยเด็ดขาด ให้ผูก xrdp ไว้กับ loopback address แทน แล้วเข้าถึงผ่านอุโมงค์ (tunnel) ที่คุณเชื่อถืออยู่แล้ว

แก้ไขไฟล์ /etc/xrdp/xrdp.ini และเปลี่ยนค่า listener ในส่วน [Globals]

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

ไฟล์ที่มาพร้อมกับซอฟต์แวร์ได้ระบุไวยากรณ์ดังกล่าวไว้ในคอมเมนต์แล้ว: tcp://.:3389 หมายถึง 127.0.0.1:3389 และ tcp://:3389 หมายถึงทุกอินเทอร์เฟซ ให้รีสตาร์ทบริการและตรวจสอบให้แน่ใจ เพราะหากพิมพ์ผิดในจุดนี้ บริการอาจยังคงทำงานบนทุกอินเทอร์เฟซโดยที่คุณไม่รู้ตัว

sudo systemctl restart xrdp
ss -tlnp | grep 3389

คุณต้องการค่า 127.0.0.1:3389 หากเห็น 0.0.0.0:3389 แสดงว่า xrdp เพิกเฉยต่อการแก้ไขของคุณ ซึ่งมักเกิดจากการที่บรรทัดดังกล่าวไปอยู่ภายใต้หัวข้อส่วนอื่นที่อยู่ถัดลงไปในไฟล์

ตอนนี้ให้เปิดอุโมงค์จากเครื่องของคุณเอง

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

-N หมายถึง "เปิดการเชื่อมต่อแต่ไม่ต้องรันคำสั่งใดๆ" เพื่อให้เซสชันคงอยู่เพียงเพื่อส่งผ่านพอร์ตเท่านั้น ให้เปิดเทอร์มินัลนั้นทิ้งไว้แล้วชี้ RDP client ไปที่ 127.0.0.1:3389 สำหรับ Linux client ซอฟต์แวร์ที่ใช้คือ FreeRDP 3 ซึ่งไฟล์ไบนารีบน 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 ในช่องชื่อคอมพิวเตอร์ FreeRDP จะขอให้คุณเชื่อถือใบรับรองในการเชื่อมต่อครั้งแรกและแสดงข้อความ Do you trust the above certificate? (Y/T/N) ซึ่งเป็นเรื่องปกติสำหรับใบรับรองแบบ self-signed snakeoil

หาก ssh ตอบกลับว่า bind [127.0.0.1]:3389: Address already in use แสดงว่ามีบางอย่างบนเครื่องของคุณใช้งานพอร์ต 3389 อยู่แล้ว ให้ย้ายฝั่ง local ไปที่ ssh -N -L 13389:127.0.0.1:3389 you@vps.example.com แล้วเชื่อมต่อที่ 127.0.0.1:13389

การสร้างอุโมงค์แยกสำหรับแต่ละคนอาจเป็นเรื่องยุ่งยาก ดังนั้นสำหรับทีม วิธีที่ดีกว่าคือการใช้เครือข่ายส่วนตัว ให้วางเครื่องเซิร์ฟเวอร์ไว้หลัง WireGuard VPN ที่โฮสต์เอง กำหนดให้ใช้ที่อยู่ tunnel เป็น 10.8.0.1 และตั้งค่า port=tcp://10.8.0.1:3389 เพื่อให้ xrdp ตอบรับเฉพาะภายใน VPN เท่านั้น ไม่ว่าในกรณีใด กฎไฟร์วอลล์สำหรับพอร์ต 3389 ไม่ควรมีอยู่เลย หากคุณไม่แน่ใจว่ากฎปัจจุบันอนุญาตอะไรบ้าง ให้เริ่มจาก พื้นฐานการใช้ ufw firewall บน VPS และตรวจสอบให้เรียบร้อยก่อนที่คุณจะเชื่อมต่อ ไม่ใช่ตรวจสอบหลังจากนั้น

Remote desktop ใช้ RAM เท่าใดบน VPS ขนาด 2 GB

Desktop environment ที่คุณเลือกจะเป็นตัวกำหนดว่าแผน 2 GB นั้นเพียงพอหรือเป็นไปไม่ได้ ตัวเลขด้านล่างนี้เป็นค่าประมาณการใช้งานหน่วยความจำหลังล็อกอินเข้าสู่ Ubuntu 24.04 ซึ่งอ้างอิงจากการเปรียบเทียบที่เผยแพร่ทั่วไป ไม่ใช่การวัดผลบนเครื่องของคุณโดยตรง คุณควรวัดค่าด้วยตนเองโดยใช้ 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"
  }
]

จาก desktop ทั้งหมด 5 รายการ ความแตกต่างของตัวเลขคือประเด็นสำคัญ LXQt ใช้หน่วยความจำประมาณ 300 MB และ XFCE ประมาณ 400 MB ซึ่งทั้งสองตัวเลือกนี้ยังเหลือพื้นที่บนเครื่อง 2 GB ให้กับเว็บเบราว์เซอร์ได้ ส่วน GNOME ต้องการหน่วยความจำประมาณ 1,200 MB ก่อนที่คุณจะเปิดหน้าต่างใดๆ ซึ่งบนเครื่อง 2 GB จะทำให้เบราว์เซอร์ต้องแย่งชิงทรัพยากรที่เหลืออยู่กับ desktop

เว็บเบราว์เซอร์คือต้นทุนที่แท้จริง ไม่ใช่ desktop shell เบราว์เซอร์สมัยใหม่ใช้หน่วยความจำระหว่าง 150 ถึง 400 MB ต่อแท็บที่ใช้งานอยู่ ดังนั้น VPS ขนาด 2 GB ที่รัน XFCE จะรองรับได้เพียงไม่กี่แท็บก่อนที่จะเริ่มใช้ swap คุณควรเพิ่ม swap เพื่อให้เครื่องทำงานช้าลงแทนที่จะสั่ง kill process ทิ้ง: ใช้ sudo fallocate -l 2G /swapfile ตามด้วย sudo chmod 600 /swapfile, sudo mkswap /swapfile, sudo swapon /swapfile และเพิ่มบรรทัดที่สอดคล้องกันใน /etc/fstab เพื่อให้ค่าคงอยู่หลังรีบูต เมื่อมีบางอย่างหายไปโดยไม่มีการแจ้งเตือน ให้รัน dmesg | grep -i "killed process" บรรทัดนั้นหมายความว่า kernel out-of-memory killer ได้ยุติการทำงานของ process นั้นไปแล้ว และเบราว์เซอร์มักจะเป็นเหยื่อรายแรก

CPU คือข้อจำกัดอีกประการหนึ่งที่มักถูกประเมินต่ำเกินไป VPS ไม่มี GPU ดังนั้น X จึงต้องใช้ software rendering ผ่าน llvmpipe ซึ่งหมายความว่า CPU ต้องเป็นผู้ประมวลผลทุกพิกเซล การเลื่อนหน้าเว็บที่มีเนื้อหาหนักหรือการเล่นวิดีโอจะปรากฏเป็นภาระของ CPU โดยตรง และจะส่งผลให้เฟรมเรตลดลงแทนที่เครื่องจะค้าง นี่คือข้อจำกัดเดียวกันกับที่คุณอาจสงสัยว่า คุณสามารถเล่นเกมบน VPS ได้หรือไม่: สำหรับงาน 3D คำตอบคือไม่ได้ และนี่คือเหตุผลหลัก

เสียงและคลิปบอร์ดในเซสชัน xrdp

Ubuntu 24.04 ใช้ PipeWire สำหรับจัดการเสียง แต่การเปลี่ยนเส้นทางเสียงของ xrdp ถูกเขียนขึ้นโดยอ้างอิง PulseAudio ดังนั้นการติดตั้งใหม่จึงใช้งานวิดีโอได้ปกติแต่ไม่มีเสียง Ubuntu มีแพ็กเกจ bridge สำหรับเรื่องนี้ไว้ให้

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

ให้ล็อกเอาต์ออกจากเซสชัน RDP โดยสมบูรณ์แล้วล็อกอินเข้ามาใหม่ เนื่องจากโมดูลจะถูกโหลดเมื่อเซสชันเริ่มต้นขึ้น การเชื่อมต่อใหม่ (reconnect) เพียงอย่างเดียวไม่เพียงพอ จากนั้นให้ตรวจสอบจากภายในเซสชันด้วยคำสั่ง:

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

คุณควรจะเห็น sink ที่มีชื่อระบุถึง xrdp และได้ยินเสียงทดสอบผ่านไคลเอนต์ของคุณ หากไม่พบ xrdp sink แสดงว่าโมดูลไม่ได้โหลดเข้าสู่เซสชันนี้ นอกจากนี้ไคลเอนต์ของคุณต้องร้องขอการใช้งานเสียงด้วย ซึ่งคือแฟล็ก /sound บน xfreerdp3 หรือการตั้งค่า "Remote audio" ในหัวข้อ Local Resources ของไคลเอนต์บน Windows

คลิปบอร์ดแบบข้อความจะทำงานได้ทั้งสองทิศทางเมื่อ xrdp-chansrv ทำงานอยู่สำหรับเซสชันของคุณ ซึ่ง xrdp จะเริ่มต้นให้โดยอัตโนมัติ ให้ยืนยันการทำงานด้วย pgrep -a xrdp-chansrv หากการคัดลอกและวางหยุดทำงานระหว่างเซสชัน แสดงว่ากระบวนการดังกล่าวสิ้นสุดลง การเชื่อมต่อใหม่จะทำให้กระบวนการนี้เริ่มต้นขึ้นอีกครั้ง การคัดลอกไฟล์แทนข้อความจะเป็นช่องทางแยกต่างหากที่เรียกว่า drive redirection โดย /drive:home,/home/you บน xfreerdp3 จะทำการ mount โฟลเดอร์ในเครื่องเข้าสู่เซสชันระยะไกล

ป๊อปอัป polkit และความล้มเหลวในการเข้าสู่ระบบครั้งแรกอื่นๆ

สิ่งที่มักพบเจอเป็นเรื่องประหลาดใจในการเข้าสู่ระบบครั้งแรกคือกล่องข้อความที่ระบุว่า Authentication is required to create a color managed device สาเหตุนั้นมีความเฉพาะเจาะจง บริการ colord จะร้องขอสิทธิ์จาก polkit ซึ่ง polkit จะอนุญาตการกระทำนั้นโดยเงียบเชียบเฉพาะกับเซสชันที่ถือว่ามีการใช้งานอยู่ภายในเครื่อง (locally seated) เท่านั้น แต่เซสชัน RDP ไม่ถือว่าเป็นเซสชันที่นั่งใช้งานอยู่จริง polkit จึงเปลี่ยนไปใช้วิธีถามรหัสผ่านจากคุณแทน Ubuntu 24.04 มาพร้อมกับ polkit 124 ซึ่งได้นำไฟล์ local authority แบบเก่าอย่าง .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 ก่อน จากนั้นตรวจสอบ ~/.xsession-errors ในโฮมไดเรกทอรีของคุณ การที่ไฟล์ xorgxrdp หายไป, การที่ ~/.xsession ระบุชื่อเดสก์ท็อปที่ไม่ได้ติดตั้งไว้, การที่คุณไม่สามารถเขียนข้อมูลลงในโฮมไดเรกทอรีได้ หรือดิสก์เต็ม ล้วนส่งผลให้เกิดปัญหานี้ทั้งสิ้น

คุณเชื่อมต่อแล้วเห็นหน้าจอสีเทาพร้อมตัวชี้เมาส์รูปกากบาท (X cursor) X เริ่มทำงานแล้วแต่เดสก์ท็อปไม่ทำงาน นั่นคือปัญหา ~/.xsession อีกครั้ง ให้รันคำสั่ง xfce4-session ด้วยตนเองผ่าน SSH แล้วอ่านข้อความแสดงข้อผิดพลาดที่ปรากฏขึ้น

หน้าที่ของเซิร์ฟเวอร์ RustDesk แบบ self-hosted

RustDesk แบ่งการทำงานออกเป็นสองกระบวนการ hbbs คือเซิร์ฟเวอร์สำหรับระบุ ID และทำหน้าที่เป็นจุดนัดพบ (rendezvous server) ที่ไคลเอนต์ต้องลงทะเบียนด้วย ส่วน hbbr คือ relay ที่ทำหน้าที่รับส่งข้อมูลเซสชันในกรณีที่การเชื่อมต่อแบบ peer-to-peer โดยตรงล้มเหลว ทั้งสองกระบวนการนี้ไม่ได้รันหน้าจอเดสก์ท็อป ทั้งคู่มาจากอิมเมจเดียวกัน และนี่คือไฟล์ compose ที่ทางโปรเจกต์เผยแพร่ โดยมีการเปลี่ยนที่อยู่ relay ให้เป็นชื่อโฮสต์ของคุณเอง:

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

ไคลเอนต์ทุกเครื่องจำเป็นต้องใช้ชื่อโฮสต์และ public key ดังกล่าว โดยให้กรอกข้อมูลทั้งสองอย่างในส่วน Network settings ของโปรแกรม RustDesk ส่วน private key ที่คู่กันจะถูกเก็บไว้ใน ./data/id_ed25519 หากคุณลบไดเรกทอรีข้อมูลทิ้ง เซิร์ฟเวอร์จะสร้างคู่กุญแจชุดใหม่ขึ้นมา ซึ่งจะส่งผลให้ไคลเอนต์ทุกเครื่องต้องถูกตั้งค่าใหม่ด้วยกุญแจชุดใหม่ ดังนั้นควรสำรองข้อมูลไดเรกทอรีดังกล่าวไว้

ไฟร์วอลล์ต้องอนุญาตให้ใช้งานพอร์ตเหล่านี้โดยตรง 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 ได้

ผู้อ่านที่ทำ TLS termination สำหรับทุกบริการผ่าน reverse proxy มักจะประสบปัญหาเมื่อพยายามตั้งค่านี้ hbbs และ hbbr ใช้โปรโตคอลไบนารีของตนเองผ่าน TCP และ UDP ไม่ใช่ HTTP จึงไม่มี Host header ให้ใช้ในการกำหนดเส้นทาง และไม่มีคำขอ HTTP ให้ตรวจสอบ ดังนั้นบล็อก server ของ nginx หรือ HTTP router ของ Traefik จึงไม่มีข้อมูลให้จับคู่ นอกจากนี้ UDP listener บนพอร์ต 21116 ก็ไม่ใช่สิ่งที่เกี่ยวข้องกับ HTTP ในเลเยอร์ใดๆ เลย

มีสองวิธีที่สามารถทำได้จริง วิธีแรกคือ nginx สามารถส่งต่อพอร์ต TCP ด้วยบล็อก stream ซึ่งเป็นการส่งต่อในระดับ layer 4 โดยตรง ไม่ใช่การทำ reverse proxy ในความหมายทั่วไป วิธีที่สองคือพอร์ต 21118 และ 21119 ซึ่งใช้ websockets สำหรับ RustDesk web client นั้นเป็น HTTP ปกติ จึงสามารถวางไว้หลัง proxy ได้ หากคุณเลือกวิธีนี้ ให้เพิ่มกฎ firewall เพื่อจำกัดให้มีเพียง proxy เท่านั้นที่เข้าถึงพอร์ต 21118 และ 21119 ได้ เนื่องจาก hbbs จะเชื่อถือ header X-Real-IP บนการเชื่อมต่อ websocket เพื่อระบุที่อยู่จริงของไคลเอนต์

เบราว์เซอร์แบบใช้แล้วทิ้งในคอนเทนเนอร์

บางครั้งสิ่งที่คุณต้องการคือเบราว์เซอร์ที่สะอาดหมดจดพร้อม IP ที่ไม่เปลี่ยนแปลง และแยกออกจากเครื่องของคุณโดยสิ้นเชิง พื้นที่ทำงานแบบคอนเทนเนอร์สามารถทำหน้าที่นี้ได้โดยใช้ซอฟต์แวร์ที่ติดตั้งน้อยกว่ามาก Webtop ของ LinuxServer เป็นตัวเลือกที่เบาบาง:

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

พอร์ต 3000 ให้บริการ HTTP และ 3001 ให้บริการ HTTPS คุณสามารถเข้าถึงเดสก์ท็อปได้ผ่านแท็บเบราว์เซอร์โดยไม่ต้องใช้ไคลเอ็นต์ RDP ใดๆ แท็กของอิมเมจครอบคลุมถึง XFCE, KDE, MATE และ i3 บนดิสทริบิวชันพื้นฐานหลายตัว เอกสารประกอบของโครงการระบุถึงความเสี่ยงไว้อย่างตรงไปตรงมาว่า คอนเทนเนอร์มีสิทธิ์เข้าถึงโฮสต์ในระดับสูงและมีเทอร์มินัลที่ใช้ sudo โดยไม่ต้องใช้รหัสผ่าน ดังนั้นจึงไม่ควรเปิดรับอินเทอร์เน็ตโดยไม่มีการป้องกัน นี่คือเหตุผลที่พอร์ตข้างต้นถูกผูกไว้กับ 127.0.0.1 แทนที่จะเผยแพร่บนทุกแอดเดรส คุณสามารถเข้าถึงได้ผ่าน SSH tunnel หรือ VPN เดียวกันกับที่คุณใช้สำหรับ xrdp

Kasm Workspaces ใช้แนวคิดเดียวกันแต่มีขนาดใหญ่กว่ามาก โดยมาพร้อมกับเว็บคอนโซล บัญชีผู้ใช้ และคอนเทนเนอร์แยกตามเซสชันที่จะรีเซ็ตเมื่อสิ้นสุดเซสชัน ระบบนี้ต้องการทรัพยากรเครื่องมากกว่าที่ VPS ขนาดเล็กจะมีให้ ณ เดือนสิงหาคม 2026 ข้อกำหนดขั้นต่ำที่ระบุไว้คือ CPU 2 คอร์, หน่วยความจำ 4 GB และ SSD 50 GB และแต่ละเซสชันของผู้ใช้จะใช้ทรัพยากรเริ่มต้นที่ 2 คอร์ และ 2768 MB เพิ่มเติมจากส่วนหลัก ดังนั้นแผนบริการขนาด 2 GB จึงไม่สามารถรันระบบนี้ได้ การติดตั้งทำได้โดยการดาวน์โหลดและรันสคริปต์:

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 แทนการส่งคำสั่งวาดภาพ ทำให้รู้สึกว่าใช้งานหนักกว่า RDP เมื่อเชื่อมต่อผ่านเครือข่ายที่ช้า และไม่มีช่องทางสำหรับส่งสัญญาณเสียง VNC ยังคงมีประโยชน์ในสถานการณ์เดียวคือ เมื่อคุณต้องการเซสชันเดสก์ท็อปที่ยังคงทำงานอยู่แม้จะตัดการเชื่อมต่อ และต้องการกลับมาใช้งานเซสชันเดิมเมื่อเชื่อมต่อใหม่ TigerVNC สามารถทำหน้าที่นี้ได้ vncserver -localhost yes :1 จะผูก Xvnc ไว้กับ 127.0.0.1 บนพอร์ต TCP 5901 และปฏิเสธการเชื่อมต่อจากแหล่งอื่น ดังนั้นคุณต้องทำ tunnel เหมือนกับ xrdp โดยใช้ ssh -N -L 5901:127.0.0.1:5901 you@vps.example.com ห้ามเปิดพอร์ต VNC สู่สาธารณะโดยเด็ดขาด เซิร์ฟเวอร์ VNC ส่วนใหญ่จะป้องกันรหัสผ่านเฉพาะในขั้นตอนการจับมือ (handshake) เท่านั้น แต่ไม่มีการป้องกันหลังจากนั้น ดังนั้นหากเปิดพอร์ตไว้สาธารณะ เนื้อหาในเซสชันจะสามารถถูกดักอ่านได้จากเครือข่าย

VPS เหมาะสำหรับใช้เป็นเดสก์ท็อปหรือไม่

ในฐานะเครื่องมือใช้งานหลัก (daily driver) คำตอบคือไม่ และมีเหตุผลหลายประการรองรับ เนื่องจากไม่มี GPU ทำให้ CPU ต้องประมวลผลการแสดงผลทั้งหมด ทุกการกดแป้นพิมพ์ต้องรอการรับส่งข้อมูลผ่านเครือข่าย ซึ่งค่าความหน่วง (latency) ระดับ 40 ms ที่ดูปกติสำหรับการใช้งาน SSH จะสังเกตเห็นได้ชัดเจนเมื่อใช้โปรแกรมแก้ไขข้อความ วิดีโอจะถูกบีบอัดสองชั้น คือจากเว็บไซต์ต้นทางและจากตัวเข้ารหัส RDP ไฟล์ของคุณจะถูกเก็บไว้บนดิสก์ที่คุณไม่ได้เป็นผู้ถือครอง และการใช้งานเดสก์ท็อปอย่างหนักจะกินปริมาณแบนด์วิดท์รายเดือนที่ถูกจัดสรรไว้สำหรับเว็บเซิร์ฟเวอร์จนหมด

ในฐานะเครื่องมือที่ใช้แล้วทิ้ง (disposable machine) VPS ถือว่าดีมาก และคุณสมบัติเดียวกันนี้เองที่เป็นเหตุผลสนับสนุน เลขที่อยู่ IP มีความเสถียรและเป็นของศูนย์ข้อมูล ซึ่งเป็นสิ่งที่คุณต้องการเมื่อบริการจำเป็นต้องเห็นที่อยู่ IP ที่สม่ำเสมอ เครื่องสามารถสร้างใหม่จากอิมเมจได้ภายในไม่กี่นาที ดังนั้นเซสชันที่ติดมัลแวร์หรือสิ่งแปลกปลอมจะไม่สร้างความเสียหายใดๆ ให้คุณ มันถูกแยกออกจากฮาร์ดแวร์จริงของคุณ และยังคงทำงานต่อไปได้แม้คุณจะปิดแล็ปท็อป การคิดค่าบริการเป็นรายชั่วโมงทำให้เดสก์ท็อปแบบใช้แล้วทิ้งมีราคาถูก

หากคุณยังไม่แน่ใจว่าเครื่องนี้มีไว้เพื่ออะไร รายการการใช้งานจริงที่ VPS ทำได้ดี เป็นสิ่งที่ควรอ่านก่อนที่คุณจะติดตั้งเดสก์ท็อปบนนั้น และหากเหตุผลที่คุณต้องการเดสก์ท็อปเป็นเพราะแอปพลิเคชัน Windows เพียงตัวเดียว ให้ชั่งน้ำหนักเรื่องนั้นกับ ความแตกต่างที่แท้จริงระหว่าง Linux และ Windows Server ก่อน เพราะค่าลิขสิทธิ์จะส่งผลต่อต้นทุนของคำตอบนี้

FAQ

ฉันสามารถรัน remote desktop บน VPS ขนาด 2 GB ได้หรือไม่?

ได้ หากใช้ desktop environment ที่เบา XFCE หรือ LXQt ใช้หน่วยความจำประมาณ 300 ถึง 400 MB หลังจากล็อกอิน ซึ่งเพียงพอสำหรับการเปิดเบราว์เซอร์ไม่กี่แท็บ แต่ GNOME หรือ KDE Plasma บน 2 GB จะไม่เหลือทรัพยากรให้แอปพลิเคชันอื่นเลย ควรเพิ่ม swap file ขนาด 2 GB เพื่อให้ระบบช้าลงเมื่อหน่วยความจำเต็ม แทนที่จะสั่ง kill กระบวนการทำงาน และหากมีบางอย่างหายไปโดยไม่มีข้อความแจ้งเตือน ให้ตรวจสอบ dmesg | grep -i "killed process" เพื่อดูการทำงานของ kernel out-of-memory killer

ฉันควรเปิดพอร์ต 3389 บน firewall ของ VPS หรือไม่?

ไม่ควร พอร์ต TCP 3389 ถูกสแกนอยู่ตลอดเวลา และการเปิดหน้าล็อกอิน RDP ไว้จะเสี่ยงต่อการถูกเดารหัสผ่าน ให้ตั้งค่า port=tcp://.:3389 ใน /etc/xrdp/xrdp.ini เพื่อให้ xrdp ฟังเฉพาะที่ 127.0.0.1 เท่านั้น ยืนยันการตั้งค่าด้วย ss -tlnp | grep 3389 และเข้าถึงผ่าน ssh -N -L 3389:127.0.0.1:3389 you@vps.example.com หากมีผู้ใช้งานมากกว่าหนึ่งหรือสองคน ให้ผูก xrdp เข้ากับ WireGuard address แทน loopback

ทำไม xrdp ถึงถามว่า "Authentication is required to create a color managed device"?

บริการ colord จะร้องขอสิทธิ์จาก polkit และ polkit จะอนุญาตการกระทำนั้นโดยอัตโนมัติเฉพาะ session ที่ล็อกอินผ่านหน้าจอเครื่องโดยตรง (locally seated) เท่านั้น session แบบ RDP ไม่ถือว่าเป็น local session จึงทำให้เกิดหน้าต่างถามรหัสผ่านทุกครั้งที่ล็อกอิน บน Ubuntu 24.04 วิธีแก้แบบเก่าด้วย .pkla จะไม่ได้ผลเนื่องจาก polkit 124 ได้ยกเลิกการใช้ไฟล์ local authority ไปแล้ว ให้สร้าง /etc/polkit-1/rules.d/45-allow-colord.rules โดยใส่กฎ JavaScript ที่ส่งค่า polkit.Result.YES สำหรับ action id ที่ขึ้นต้นด้วย org.freedesktop.color-manager. จากนั้นรัน sudo systemctl restart polkit

ฉันสามารถวางเซิร์ฟเวอร์ RustDesk ที่ self-host ไว้หลัง nginx หรือ Traefik ได้หรือไม่?

ไม่ได้สำหรับบริการหลัก hbbs และ hbbr ใช้ binary protocol ของตนเองไม่ใช่ HTTP จึงไม่มี Host header ให้ใช้ในการ route และ UDP 21116 ไม่สามารถผ่าน HTTP proxy ได้ ให้เปิดพอร์ต TCP 21115 ถึง 21119 และ UDP 21116 บน firewall แล้วให้ client เชื่อมต่อโดยตรง ส่วนพอร์ต websocket 21118 และ 21119 ที่ใช้โดย web client นั้นเป็น HTTP ซึ่งสามารถวางหลัง proxy ได้ แต่หากทำเช่นนั้น ให้ตั้งค่า firewall ให้เฉพาะ proxy เท่านั้นที่เข้าถึงได้ เพราะ hbbs จะเชื่อถือ X-Real-IP บนการเชื่อมต่อเหล่านั้น

ทำไมไม่มีเสียงใน session xrdp ของฉัน?

Ubuntu 24.04 ใช้ PipeWire ในขณะที่ระบบส่งสัญญาณเสียงของ xrdp ถูกสร้างมาเพื่อ PulseAudio ทำให้ไม่มีเสียงจนกว่าคุณจะติดตั้ง bridge ให้รัน sudo apt install -y pipewire-module-xrdp จากนั้นให้ log out ออกจาก session โดยสมบูรณ์แล้ว log in ใหม่ เนื่องจากโมดูลจะถูกโหลดเมื่อเริ่ม session เท่านั้น การ reconnect จะไม่โหลดโมดูลใหม่ ให้ตรวจสอบด้วย pactl list short sinks ว่ามี sink ที่ชื่อ xrdp หรือไม่ และตรวจสอบให้แน่ใจว่า client ร้องขอเสียง ซึ่งคือการตั้งค่า /sound บน xfreerdp3 หรือเลือก "Remote audio" ใน Windows client

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