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

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

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

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

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

• RustDesk พร้อม relay ของคุณเอง: วิธีนี้ช่วยป้องกันไม่ให้เซสชันส่งผ่าน rendezvous server สาธารณะที่ดำเนินการโดยบุคคลภายนอก เนื่องจากคุณเป็นผู้ถือครอง key pair เอง อย่างไรก็ตาม วิธีนี้ไม่ได้ช่วยป้องกันเครื่องที่ถูกควบคุม ซึ่งยังคงเป็น PC เครื่องเดิมที่คุณติดตั้งไคลเอนต์ไว้ และยังคงใช้รหัสผ่านเดิมของเครื่องนั้น
• xrdp ผ่าน SSH tunnel หรือ VPN: วิธีนี้ช่วยป้องกันคุณจากการสแกนพอร์ต TCP 3389 ทั่วอินเทอร์เน็ตอย่างต่อเนื่อง และป้องกันการเดารหัสผ่านที่หน้าล็อกอิน RDP เนื่องจากพอร์ตดังกล่าวไม่เคยเปิดรับการเชื่อมต่อจากอินเทอร์เน็ตโดยตรง แต่ไม่ได้ช่วยป้องกันรหัสผ่านบัญชีที่อ่อนแอจากผู้ที่มีสิทธิ์เข้าถึง tunnel นั้นอยู่แล้ว
• VNC ผ่าน tunnel เดียวกัน: วิธีนี้ให้เซสชันเดสก์ท็อปที่ยังคงอยู่แม้จะถูกตัดการเชื่อมต่อ โดยใช้โปรโตคอลที่เก่าและเรียบง่ายกว่า RDP ในตัวมันเองไม่ได้ให้การป้องกันใดๆ: tunnel ทำหน้าที่รักษาความปลอดภัยทั้งหมด ดังนั้นการใช้ VNC บนพอร์ตสาธารณะเพียงอย่างเดียวจึงเป็นตัวเลือกที่แย่ที่สุดในที่นี้
• Container workspace เช่น 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 ซึ่งไฟล์ 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 ในช่องชื่อคอมพิวเตอร์ 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 address เป็น 10.8.0.1 และตั้งค่า port=tcp://10.8.0.1:3389 เพื่อให้ xrdp ตอบรับเฉพาะภายใน VPN เท่านั้น ไม่ว่ากรณีใดก็ตาม กฎ firewall สำหรับพอร์ต 3389 ไม่ควรมีอยู่เลย หากคุณไม่แน่ใจว่ากฎปัจจุบันอนุญาตให้ทำอะไรได้บ้าง ให้เริ่มจาก พื้นฐาน ufw firewall บน VPS และตรวจสอบให้เรียบร้อยก่อนที่คุณจะเชื่อมต่อ ไม่ใช่ตรวจสอบหลังจากนั้น

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

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

จากจำนวน 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 เพื่อให้ค่าคงอยู่หลังการ reboot เมื่อมีบางอย่างหายไปโดยไม่มีการแจ้งเตือน ให้รัน dmesg | grep -i "killed process" บรรทัดดังกล่าวหมายความว่า kernel out-of-memory killer ได้ยุติการทำงานของ process นั้นไปแล้ว และเบราว์เซอร์มักจะเป็นเหยื่อหลัก

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

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

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

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 แสดงว่า X เริ่มทำงานแล้วแต่เดสก์ท็อปไม่ทำงาน นั่นคือปัญหา ~/.xsession อีกครั้ง ให้รันคำสั่ง xfce4-session ด้วยตนเองผ่าน SSH แล้วอ่านข้อความแสดงข้อผิดพลาดที่ปรากฏขึ้น

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

RustDesk แบ่งการทำงานออกเป็น 2 กระบวนการ โดย 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 หากคุณลบไดเรกทอรีข้อมูลทิ้ง เซิร์ฟเวอร์จะสร้างคู่กุญแจใหม่ขึ้นมา ซึ่งจะทำให้ไคลเอนต์ทุกเครื่องต้องถูกตั้งค่าใหม่ด้วยกุญแจชุดใหม่ ดังนั้นควรสำรองข้อมูลไดเรกทอรีดังกล่าวไว้ หากคุณตัดสินใจใช้ช่องทางนี้เป็นวิธีหลักในการเข้าถึงเครื่องคอมพิวเตอร์ของทีมแทนที่จะเป็นเพียงการทดลองชั่วคราว การสร้าง RustDesk relay ขึ้นมาใช้งานโดยเฉพาะ เป็นสิ่งที่ควรทำ เพื่อจัดการกุญแจ Ed25519 ให้ถูกต้อง, การระบุเวอร์ชันอิมเมจแบบตายตัวแทนการใช้ latest และเพื่อรองรับปริมาณการใช้งานแบนด์วิดท์ของ relay ที่คุณต้องรับผิดชอบค่าใช้จ่าย

ไฟร์วอลล์ต้องอนุญาตพอร์ตเหล่านี้โดยตรง โดย 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 มักจะพยายามตั้งค่า RustDesk ในลักษณะเดียวกันแต่ไม่สำเร็จ เนื่องจาก hbbs และ hbbr ใช้โปรโตคอลไบนารีของตนเองผ่าน TCP และ UDP ไม่ใช่ HTTP จึงไม่มี Host header ให้ใช้ในการกำหนดเส้นทาง (route) และไม่มีคำขอ HTTP ให้ตรวจสอบ ดังนั้นบล็อก server ของ nginx หรือ HTTP router ของ Traefik จึงไม่มีข้อมูลให้จับคู่ นอกจากนี้ตัวรับสัญญาณ UDP บนพอร์ต 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 client ใดๆ แท็กของอิมเมจครอบคลุมถึง 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 เหมาะสำหรับใช้เป็นเดสก์ท็อปหรือไม่

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

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

หากคุณยังไม่แน่ใจว่าเครื่องนี้มีไว้เพื่ออะไร รายการการใช้งานจริงที่ 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) แต่ RDP session ไม่ถือเป็น 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

ฉันสามารถวาง self-hosted RustDesk server ไว้หลัง nginx หรือ Traefik ได้หรือไม่?

ไม่ได้สำหรับบริการหลัก hbbs และ hbbr ใช้ binary protocol ของตนเองแทนที่จะเป็น HTTP จึงไม่มี Host header ให้ใช้ในการทำ routing และพอร์ต 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 จากนั้นให้ล็อกเอาต์ออกจาก session โดยสมบูรณ์แล้วล็อกอินใหม่ เนื่องจากโมดูลจะถูกโหลดเมื่อเริ่ม session เท่านั้น การเชื่อมต่อใหม่ (reconnect) จะไม่โหลดโมดูลดังกล่าว ให้ตรวจสอบด้วย pactl list short sinks เพื่อดู sink ที่ระบุชื่อ xrdp และตรวจสอบให้แน่ใจว่า client ได้ร้องขอเสียง ซึ่งคือ flag /sound บน xfreerdp3 หรือเลือก "Remote audio" ใน Windows client