วิธีติดตั้ง RustDesk Relay Server บน VPS ด้วยตนเอง

RustDesk relay server แบบ self-hosted คืออะไร

RustDesk relay server แบบ self-hosted ประกอบด้วย daemon สองตัวที่ทำงานบน VPS เดียวกัน hbbs ทำหน้าที่เป็น ID และ rendezvous server โดยจะลงทะเบียน ID ของไคลเอนต์ทุกตัวและทำหน้าที่เชื่อมต่อไคลเอนต์สองตัวเข้าหากัน hbbr ทำหน้าที่เป็น relay server ซึ่งจะรับส่งข้อมูลเซสชันในกรณีที่ไคลเอนต์ไม่สามารถเชื่อมต่อกันโดยตรงได้ คู่มือส่วนใหญ่จะแนะนำวิธีการติดตั้งทั้งสองตัวเพื่อให้ใช้งานได้เท่านั้น แต่เนื้อหาต่อไปนี้จะครอบคลุมส่วนที่เหลือ ได้แก่ กุญแจสำหรับการควบคุมการเข้าถึง, พอร์ต, การอัปเกรด และการจัดการแบนด์วิดท์

daemon ทั้งสองตัวมาพร้อมกับอิมเมจเดียวกันคือ rustdesk/rustdesk-server และอ่านคู่กุญแจ Ed25519 จากไดเรกทอรีเดียวกัน Ed25519 เป็นรูปแบบการลงลายมือชื่อด้วยกุญแจสาธารณะ (public key signature scheme) คู่กุญแจนี้จะเป็นตัวกำหนดว่าเซิร์ฟเวอร์ของคุณจะสื่อสารกับไคลเอนต์ตัวใดบ้าง โดยไม่มีฐานข้อมูลผู้ใช้งานอยู่เบื้องหลัง

hbbs และ hbbr: daemon ตัวไหนที่ใช้แบนด์วิดท์ของคุณ

ทราฟฟิกของ hbbs มีขนาดเล็กและคงที่: เป็นการลงทะเบียน ID และการส่งสัญญาณ heartbeat รวมถึงการแลกเปลี่ยนข้อมูลสั้นๆ เพื่อแนะนำ peer สองฝั่งให้รู้จักกัน มันทำงานตลอดทั้งวันและแทบไม่กินทรัพยากรเลย

ทราฟฟิกของ hbbr คือตัวเซสชันการใช้งานจริง เฟรมภาพหน้าจอจะถูกส่งไปทางหนึ่ง ส่วนข้อมูลคีย์บอร์ดและเมาส์จะถูกส่งไปอีกทางหนึ่ง และทุกไบต์ที่ถูกส่งผ่าน relay จะเข้ามาที่ VPS ของคุณแล้วถูกส่งออกไปอีกครั้ง หากผู้ให้บริการของคุณคิดค่าบริการเฉพาะขาออก (egress) เซสชันที่ผ่าน relay จะมีค่าใช้จ่ายตามอัตราการใช้งานเซสชันนั้น แต่หากคิดค่าบริการจากปริมาณการถ่ายโอนข้อมูลรวม คุณจะต้องเสียค่าใช้จ่ายประมาณสองเท่าของปริมาณข้อมูลดังกล่าว

การทำ relay เป็นเพียงทางเลือกสำรอง ไม่ใช่เส้นทางปกติ hbbs จะพยายามเชื่อมต่อไคลเอนต์ทั้งสองฝั่งโดยตรงก่อน โดยใช้การทำ hole punching ผ่าน NAT (network address translation) ที่อยู่หน้าไคลเอนต์แต่ละฝั่ง เมื่อวิธีนี้สำเร็จ เซสชันจะไม่ผ่าน hbbr เลยและปริมาณการใช้งานของคุณก็จะไม่ถูกหัก แต่เมื่อฝั่งใดฝั่งหนึ่งอยู่หลัง NAT ที่กำหนดพอร์ตใหม่สำหรับทุกปลายทาง หรืออยู่หลังไฟร์วอลล์ที่บล็อกเส้นทางที่เจาะไว้ เซสชันจะเปลี่ยนไปใช้ hbbr และทุกเฟรมข้อมูลจะวิ่งผ่าน VPS ของคุณ

มี environment variable หนึ่งตัวที่ตัดทางเลือกนี้ออกไป ALWAYS_USE_RELAY=Y บน hbbs จะบังคับให้ทุกเซสชันต้องผ่าน hbbr เอกสารของ RustDesk แสดงค่านี้ไว้ในตัวอย่าง Compose ชุดหนึ่ง จึงมีการคัดลอกไปใช้กันบ่อยครั้ง มันทำให้การเชื่อมต่อคาดเดาได้ง่ายขึ้นและทำให้คุณต้องเสียค่าใช้จ่ายขาออกจริง ควรตั้งค่านี้ก็ต่อเมื่อคุณตัดสินใจเลือกเอง ไม่ใช่เพราะคุณคัดลอกมาวางเพียงอย่างเดียว

พอร์ตที่เซิร์ฟเวอร์ RustDesk แบบ self-hosted จำเป็นต้องใช้งาน

หมายเลขพอร์ตด้านล่างนี้ได้รับการตรวจสอบกับเอกสารประกอบของเซิร์ฟเวอร์ RustDesk และ repository rustdesk-server เมื่อวันที่ 17 สิงหาคม 2026

• TCP 21115 บน hbbs: สำหรับการทดสอบ NAT type
• UDP 21116 บน hbbs: สำหรับการลงทะเบียน ID และการส่ง heartbeat หากไม่มีพอร์ตนี้ ไคลเอนต์จะไม่สามารถออนไลน์ได้ไม่ว่าจะเปิดพอร์ตอื่นใดไว้ก็ตาม
• TCP 21116 บน hbbs: สำหรับ TCP hole punching และบริการเชื่อมต่อ
• TCP 21117 บน hbbr: สำหรับ relay นี่คือพอร์ตที่ใช้รับส่งข้อมูลเซสชัน ซึ่งเป็นพอร์ตที่ทำให้เกิดการใช้ปริมาณข้อมูล (bandwidth)
• TCP 21118 บน hbbs และ TCP 21119 บน hbbr: สำหรับ WebSocket ซึ่งใช้โดยไคลเอนต์บนเบราว์เซอร์ ให้ปิดพอร์ตทั้งสองนี้ไว้หากคุณไม่ได้ใช้งาน
• TCP 21114 คือเว็บคอนโซลใน RustDesk Server Pro สำหรับรุ่น open source จะไม่มีการเปิดฟังพอร์ตนี้

ติดตั้ง hbbs และ hbbr โดยระบุ image tag ให้ชัดเจน

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbs
    volumes:
      - ./data:/root
    network_mode: "host"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:1.1.16
    command: hbbr -k _
    volumes:
      - ./data:/root
    network_mode: "host"
    restart: unless-stopped

mkdir -p ~/rustdesk
cd ~/rustdesk
# save the block above as ~/rustdesk/compose.yml before this line
sudo docker compose up -d
sudo docker compose ps

บริการทั้งสองควรเรียกอ่าน running ตรวจสอบให้แน่ใจว่ามี listener ทำงานอยู่ก่อนที่คุณจะตั้งค่า firewall

sudo ss -tlnp | grep -E ':2111[5-7]'
sudo ss -ulnp | grep ':21116'

คุณควรเห็น TCP listener บนพอร์ต 21115, 21116 และ 21117 รวมถึง UDP listener บนพอร์ต 21116 หากบรรทัด UDP หายไป แสดงว่า hbbs ไม่ได้ทำงานอยู่ เนื่องจาก listener ดังกล่าวเป็นจุดที่ไคลเอนต์ใช้สำหรับลงทะเบียน

มี 4 สิ่งในไฟล์นั้นที่ตั้งใจกำหนดไว้ คือ tag ที่ใช้คือ 1.1.16 ซึ่งเป็น release ปัจจุบัน ณ เดือนสิงหาคม 2026 ที่เผยแพร่เมื่อวันที่ 20 กรกฎาคม 2026 แทนที่จะใช้ latest เพราะ latest หมายถึงเวอร์ชันใดก็ตามที่ถูก push ล่าสุด และ docker compose pull ในอีก 6 เดือนข้างหน้าอาจทำให้คุณได้เซิร์ฟเวอร์เวอร์ชันที่คุณไม่เคยทดสอบมาก่อน network_mode: "host" จะทำการ bind host interface โดยตรง ซึ่งเป็นวิธีที่เอกสารของ RustDesk แนะนำและเป็นตัวกำหนดพฤติกรรมของ firewall ของคุณ ./data:/root จะทำการ map working directory ของ image ไปยัง host เพื่อให้ key pair ถูกจัดเก็บในที่ที่คุณสามารถสำรองข้อมูลได้ และ hbbr -k _ คือจุดเดียวที่ปรับเปลี่ยนจากตัวอย่างต้นฉบับ เนื่องจากค่าเริ่มต้นจะเปิด relay ของคุณให้ใครก็ได้เข้ามาใช้งาน หากคุณยังใหม่กับ Compose สามารถดู การรัน Docker Compose บน VPS ซึ่งครอบคลุมรูปแบบไฟล์และคำสั่งจัดการวงจรชีวิตของคอนเทนเนอร์

หาก hbbr ย้ายไปอยู่บนเซิร์ฟเวอร์เครื่องที่สอง hbbs จำเป็นต้องทราบตำแหน่งที่ตั้งใหม่ โดยให้ส่งค่า -r relay.example.com:21117 หรือตั้งค่า environment variable RELAY-SERVERS หากรันบนเครื่องเดียว คุณไม่จำเป็นต้องตั้งค่านี้

คู่กุญแจ Ed25519 คือการควบคุมการเข้าถึง

ในการเริ่มทำงานครั้งแรก hbbs จะสร้าง id_ed25519 และ id_ed25519.pub ไว้ในไดเรกทอรีการทำงาน หากมีการ mount ตามที่ระบุไว้ข้างต้น ไฟล์ทั้งสองจะปรากฏอยู่บนโฮสต์

ls -l ~/rustdesk/data/
sudo cat ~/rustdesk/data/id_ed25519.pub

id_ed25519.pub จะเก็บสตริง base64 ไว้หนึ่งชุด สตริงนั้นจะต้องนำไปใส่ในช่อง Key บนไคลเอนต์ทุกเครื่อง ส่วน id_ed25519 คือส่วนที่เป็นกุญแจส่วนตัวและห้ามนำออกจากเซิร์ฟเวอร์โดยเด็ดขาด กุญแจสาธารณะไม่ใช่ความลับเพราะต้องคัดลอกลงในไฟล์ตั้งค่าของไคลเอนต์ทุกเครื่องอยู่แล้ว แต่กุญแจส่วนตัวคือความลับ: ใครก็ตามที่ถือครองมันสามารถตั้งเซิร์ฟเวอร์ที่ไคลเอนต์ของคุณจะเชื่อถือได้

ให้สำรองไฟล์ทั้งสองไว้ทันที ก่อนที่คุณจะตั้งค่าไคลเอนต์ครบยี่สิบเครื่อง

sudo tar czf ~/rustdesk-keys.tgz -C ~/rustdesk/data id_ed25519 id_ed25519.pub
sudo chmod 600 ~/rustdesk-keys.tgz

คัดลอกไฟล์สำรองนั้นออกจากเครื่อง นี่คือเหตุผลว่าทำไมขั้นตอนนี้จึงสำคัญกว่าขั้นตอนอื่น หากคุณลบ ~/rustdesk/data หรือสร้างเซิร์ฟเวอร์ใหม่บน VPS โดยไม่ได้คัดลอกไฟล์นี้ hbbs จะสร้างคู่กุญแจใหม่ขึ้นมาในการเริ่มทำงานครั้งถัดไป ไคลเอนต์ทุกเครื่องยังคงถือครองกุญแจสาธารณะชุดเก่าอยู่ ดังนั้น hbbs จะปฏิเสธการเชื่อมต่อและไคลเอนต์จะออฟไลน์ ให้รันคำสั่ง sudo cat ~/rustdesk/data/id_ed25519.pub แล้วเปรียบเทียบกับช่อง Key บนไคลเอนต์เครื่องใดก็ได้: สตริงทั้งสองจะไม่ตรงกัน และความไม่ตรงกันนี้คือสาเหตุของความล้มเหลวทั้งหมด การแก้ไขหมายถึงการต้องเข้าไปแก้ไขการตั้งค่าบนทุกเครื่องด้วยตนเอง รวมถึงเครื่องที่คุณกำลังใช้งาน RustDesk เพื่อรีโมทเข้าไปด้วย

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

เหตุใดการทำ relay โดยไม่ตรวจสอบสิทธิ์จึงเป็นปัญหา

โดยค่าเริ่มต้น hbbr จะไม่ตรวจสอบสิ่งใดเลย เอกสารการกำหนดค่าของ RustDesk ระบุไว้ชัดเจนว่า คีย์ว่างจะอนุญาตให้ไคลเอนต์ที่ไม่มีคีย์ที่ตรงกันสามารถใช้งาน relay ได้ การตั้งค่าเริ่มต้นเป็นค่าว่างมีไว้เพื่อให้ผู้ใช้ใหม่ไม่พบปัญหาคีย์ไม่ตรงกันในการใช้งานครั้งแรก แต่ผลที่ตามมาคือ ใครก็ตามที่พบที่อยู่ของคุณบน TCP 21117 สามารถส่ง traffic ของเซสชันผ่าน VPS ของคุณได้ โดยใช้โควตาการโอนถ่ายข้อมูลของคุณ และผ่าน IP address ของคุณ

command: hbbr -k _ จะช่วยปิดช่องโหว่นี้ อาร์กิวเมนต์ _ จะสั่งให้ hbbr โหลดคู่กุญแจจากไดเรกทอรีทำงานของมัน และเนื่องจากคอนเทนเนอร์ทั้งสองตัว mount ไปยัง ./data เดียวกัน จึงเป็นคู่กุญแจชุดเดียวกับที่ hbbs สร้างไว้ก่อนหน้า ไม่มีการคัดลอกด้วยมือ ดังนั้นจึงไม่มีทางที่ข้อมูลจะคลาดเคลื่อน

การใช้ volume ร่วมกันคือส่วนที่ผู้คนมักทำผิดพลาด หากคุณกำหนดไดเรกทอรีแยกให้ hbbr มันจะสร้างคู่กุญแจที่ แตกต่าง ออกไป ทำให้ hbbs และ hbbr ไม่ตรงกัน ส่งผลให้เซสชันที่ต้องผ่าน relay ทั้งหมดล้มเหลว ในขณะที่เซสชันแบบเชื่อมต่อตรงยังคงใช้งานได้ อาการที่เกิดขึ้นจะสร้างความสับสน คือ RustDesk จะเชื่อมต่อกับ peer บางรายได้และบางรายไม่ได้ ขึ้นอยู่กับว่าการทำ hole punching สำเร็จหรือไม่ การตรวจสอบ ls -l ~/rustdesk/data/ ที่แสดงคู่ id_ed25519 เพียงคู่เดียวจะช่วยตัดปัญหานี้ออกไปได้

กำหนดค่าเครื่องลูกข่ายให้ชี้มายังเซิร์ฟเวอร์ของคุณ

บนแต่ละเครื่อง ให้เปิดโปรแกรม RustDesk ไปที่ Settings จากนั้นเลือก Network แล้วไปที่ ID/Relay Server

• ID Server: ใส่ hostname ของคุณ ตัวอย่างเช่น rustdesk.example.com โดยเครื่องลูกข่ายจะใช้พอร์ต 21116 เว้นแต่คุณจะระบุเป็นพอร์ตอื่น
• Relay Server: ปล่อยว่างไว้หาก hbbr ทำงานอยู่บนโฮสต์เดียวกับ hbbs
• API Server: ปล่อยว่างไว้ เนื่องจากเซิร์ฟเวอร์เวอร์ชันโอเพนซอร์สไม่มีฟีเจอร์นี้
• Key: ใส่สตริง base64 ที่ได้จาก id_ed25519.pub โดยคัดลอกมาวางให้ถูกต้องแม่นยำและห้ามมีช่องว่างต่อท้าย

หน้าต่างหลักควรแสดงสถานะว่าเครื่องลูกข่ายพร้อมใช้งาน หากไม่เป็นเช่นนั้น แสดงว่าพอร์ต UDP 21116 ไม่สามารถเชื่อมต่อไปยัง hbbs ได้ เนื่องจากกระบวนการลงทะเบียนและ heartbeat ทำงานผ่านโปรโตคอล UDP เท่านั้น และไม่มีวิธีอื่นที่จะทำให้ ID ออนไลน์ได้

จำกัดพอร์ตเพื่อไม่ให้ relay กลายเป็นบริการสาธารณะ

เนื่องจากคอนเทนเนอร์ใช้ host networking จึงไม่มีกฎ Docker NAT อยู่เบื้องหน้า ทำให้กฎของ ufw ทำงานได้ตามที่คุณคาดหวัง

sudo ufw allow 22/tcp
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udp
sudo ufw enable
sudo ufw status numbered

ให้เพิ่ม 21118:21119/tcp เฉพาะในกรณีที่คุณใช้งาน browser client เท่านั้น ควรเปิด SSH session ทิ้งไว้อีกหนึ่งหน้าต่างในขณะที่คุณเปิดใช้งาน ufw เพื่อป้องกันไม่ให้คุณถูกตัดการเชื่อมต่อจากเซิร์ฟเวอร์หากตั้งค่ากฎ SSH ผิดพลาด พื้นฐานไฟร์วอลล์ ufw สำหรับ VPS ครอบคลุมถึงนโยบายเริ่มต้นและการเรียงลำดับกฎ

ข้อควรระวังคือ หากคุณเปลี่ยนไปใช้วิธีเผยแพร่พอร์ตด้วยบล็อก ports: ซึ่งเป็นวิธีที่ตัวอย่างอิมเมจ RustDesk supervisor แบบทางเลือกใช้งาน Docker จะเขียนกฎ DNAT ของตัวเองขึ้นมา และแพ็กเก็ตจะเข้าถึงคอนเทนเนอร์โดยไม่ผ่าน chain ที่กฎ ufw ของคุณอยู่ ดังนั้นการสั่ง ufw deny พอร์ต 21117 จะไม่มีผล และ relay จะเปิดรับการเชื่อมต่อจากอินเทอร์เน็ตแม้ว่า ufw status จะแสดงสถานะว่าปิดอยู่ก็ตาม การเผยแพร่พอร์ตของ Docker ข้ามการทำงานของ ufw อธิบายถึงลำดับของ chain ไว้ การใช้ host networking จะช่วยหลีกเลี่ยงปัญหานี้ได้ทั้งหมด หากคุณจำเป็นต้องเผยแพร่พอร์ต ให้ bind พอร์ตนั้นเข้ากับ address เดียว ดังเช่นใน "127.0.0.1:21118:21118" ที่อยู่หลัง reverse proxy

การจำกัดด้วย source address จะได้ผลก็ต่อเมื่อ client ของคุณมี address ที่คงที่เท่านั้น

sudo ufw allow from 203.0.113.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 21116 proto udp

แล็ปท็อปที่ใช้งานผ่านเครือข่ายโรงแรมมักไม่มี address ที่คงที่ ซึ่งเป็นเหตุผลว่าทำไมกุญแจบน hbbr จึงมีความสำคัญในการรักษาความปลอดภัยมากกว่าไฟร์วอลล์ในกรณีนี้

การอัปเกรด stack ที่เก็บคีย์ของคุณ

คีย์จะถูกเก็บไว้ใน bind mount ไม่ใช่ภายใน container ดังนั้นการอัปเกรดจึงมีความปลอดภัยตราบใดที่คุณไม่ไปยุ่งกับ ./data

1. สำรองข้อมูลไดเรกทอรีข้อมูลก่อน: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data
2. อ่านบันทึกประจำรุ่น (release notes) สำหรับ tag ใหม่ในหน้า rustdesk-server releases
3. แก้ไขไฟล์ compose.yml และเปลี่ยนบรรทัด image: ทั้งสองบรรทัดให้เป็น tag ใหม่
4. รันคำสั่ง sudo docker compose pull จากนั้นรัน sudo docker compose up -d
5. รันคำสั่ง sudo cat ~/rustdesk/data/id_ed25519.pub และยืนยันว่าสตริงที่ได้เป็นสตริงเดียวกับที่ client ของคุณถืออยู่

ขั้นตอนที่ 5 คือการตรวจสอบที่สำคัญที่สุด เพราะหากคีย์มีการเปลี่ยนแปลง เซิร์ฟเวอร์จะไม่แจ้งเตือนใดๆ แต่จะทำให้ client ทุกตัวใช้งานไม่ได้ทันที การย้อนกลับ (rollback) ทำได้โดยการเปลี่ยนกลับไปใช้ tag เดิมแล้วรัน up -d อีกครั้ง ซึ่งวิธีนี้จะใช้ได้ก็ต่อเมื่อคุณได้ระบุเวอร์ชันไว้แล้ว (pinned) หากใช้ latest ตัว docker compose pull จะย้ายชื่อ tag ไปยัง image ใหม่ ทำให้ไม่มี tag ใดที่ชี้ไปยัง image เก่าอีกต่อไป

สาเหตุปกติที่ทำให้คีย์สูญหายไม่ใช่เพราะ docker compose down ซึ่งไม่ได้ยุ่งกับ bind mount แต่เกิดจากการย้ายไปยัง VPS ใหม่แล้วคัดลอกไปเพียง compose.yml เท่านั้น อย่าลืมคัดลอก ./data ไปด้วยทุกครั้ง

การตรวจสอบปริมาณข้อมูลขาออกบนแผนบริการที่มีการจำกัดโควตาการรับส่งข้อมูล

hbbr เป็นส่วนประกอบเดียวใน stack นี้ที่ใช้โควตาการรับส่งข้อมูล FAQ ของ RustDesk ระบุว่าการเชื่อมต่อผ่าน relay บนหน้าจอความละเอียด 1920x1080 จะใช้แบนด์วิดท์ระหว่าง 30 KB/s ถึง 3 MB/s และงานออฟฟิศทั่วไปจะใช้ประมาณ 100 KB/s ตัวเลขเหล่านี้เป็นค่าที่เผยแพร่สำหรับการเชื่อมต่อหนึ่งเซสชัน ไม่ใช่การวัดผลจากระบบของคุณโดยตรง หากคำนวณจากการใช้งาน 60 ชั่วโมงต่อเดือน หรือวันละ 2 ชั่วโมง จะได้ผลลัพธ์ดังนี้

[
  {
    "label": "Low end, 30 KB/s",
    "gb_per_month": 6.5
  },
  {
    "label": "Office work, 100 KB/s",
    "gb_per_month": 21.6
  },
  {
    "label": "High end, 3 MB/s",
    "gb_per_month": 648
  }
]

ที่อัตราการใช้งานแบบงานออฟฟิศ หนึ่งเซสชันจะใช้ข้อมูลประมาณ 21.6 GB ต่อเดือน ซึ่งไม่มีแผนบริการใดได้รับผลกระทบ แต่ที่อัตราสูงสุดตามช่วงที่ระบุไว้ การใช้งาน 60 ชั่วโมงเท่าเดิมจะใช้ข้อมูลถึง 648 GB และหากมีการเชื่อมต่อพร้อมกัน 2 เซสชันที่อัตราดังกล่าว จะใช้โควตา 1 TB จนหมดภายในเดือนเดียว ส่วนค่าต่ำสุดจะอยู่ที่ 6.5 GB ทั้งนี้ กิกะไบต์ในที่นี้มีค่าเท่ากับ 1000 MB ซึ่งเป็นวิธีนับโควตาการรับส่งข้อมูลตามปกติ

docker stats จะไม่สามารถแยกแยะข้อมูลส่วนนี้ให้คุณได้ เนื่องจากคอนเทนเนอร์ที่ใช้ host networking จะใช้ network namespace ร่วมกับโฮสต์ ทำให้ตัวนับข้อมูลเป็นตัวนับเดียวกับของโฮสต์ แต่มีเครื่องมืออื่นอีก 2 รายการที่ใช้งานได้ โดย vnstat จะวัดผลรวมทั้งเครื่อง:

sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

การวัดผลรวมทั้งเครื่องหมายถึงทั้งเครื่องจริงๆ หาก VPS นี้รันบริการอื่นที่มีการรับส่งข้อมูลจำนวนมาก เช่น เซิร์ฟเวอร์รูปภาพแบบ self-hosted ที่ดึงข้อมูลจากคลังภาพในโทรศัพท์ทุกคืน ข้อมูลขาออกเหล่านั้นจะถูกนับรวมในยอดรายเดือนเดียวกับทราฟฟิกของ relay

ตัวนับของ nftables สามารถวัดเฉพาะทราฟฟิกของ relay ได้:

sudo nft add table inet relaymeter
sudo nft add chain inet relaymeter out '{ type filter hook output priority 0 ; }'
sudo nft add rule inet relaymeter out tcp sport 21117 counter
sudo nft list table inet relaymeter

กฎนี้ไม่มี verdict จึงทำได้เพียงนับ packets และ bytes โดยไม่เปลี่ยนแปลงสิ่งที่อนุญาต และอยู่ใน table ของตนเอง จึงไม่รบกวน ufw กฎนี้ไม่คงอยู่ถาวร หากต้องการให้กลับมาหลัง reboot ให้ใส่บรรทัดเดิมไว้ใน /etc/nftables.conf ตัวนับจะเพิ่มขึ้นเฉพาะขณะที่มีการ relay session อยู่จริง หากตัวนับยังเพิ่มขึ้นขณะที่ไม่มีเครื่องของคุณเชื่อมต่อ แสดงว่ามีผู้อื่นค้นพบ relay ของคุณ ซึ่งเป็นกรณีที่ hbbr -k _ มีไว้เพื่อป้องกัน เนื่องจากคุณคงไม่เปิดอ่าน nft list ทุกเช้า ให้ตั้ง cron job บนระบบดังกล่าวเพื่อตรวจสอบจำนวน bytes เทียบกับ threshold และส่ง push alert เมื่อเกินค่าที่กำหนด งานนี้เหมาะกับ ntfy server ของคุณเอง

hbbr ยังมีค่าจำกัดอัตรา (rate limit) ที่คุณสามารถปรับลดลงได้ โดย SINGLE_BANDWIDTH มีค่าเริ่มต้นที่ 128 Mb/s ต่อหนึ่งการเชื่อมต่อ relay และ TOTAL_BANDWIDTH อยู่ที่ 1024 Mb/s สำหรับการเชื่อมต่อทั้งหมด การตั้งค่า SINGLE_BANDWIDTH=8 จะจำกัดความเร็วต่อเซสชันไว้ที่ประมาณ 1 MB/s ซึ่งเป็นการจำกัดความเร็ว ไม่ใช่ยอดรวมรายเดือน ดังนั้นให้มองว่าเป็นการป้องกันไม่ให้เซสชันเดียวใช้แบนด์วิดท์จนเต็ม มากกว่าจะเป็นการควบคุมงบประมาณการใช้งาน

เมื่อคุณไม่จำเป็นต้องใช้ relay เลย

สำหรับการใช้งานส่วนตัว คำตอบที่ตรงไปตรงมาคือคุณอาจไม่จำเป็นต้องใช้สิ่งเหล่านี้เลย ให้ติดตั้งเครื่องทั้งสองเครื่องไว้บน mesh VPN แล้วเชื่อมต่อผ่าน tunnel address โดยตรง วิธีนี้จะไม่มี hbbs, ไม่มี hbbr, ไม่มีการใช้ relay egress และไม่ต้องคอยอัปเดต container บน VPS

บนเครื่องที่คุณต้องการควบคุม ให้เปิดใช้งาน direct IP access ในการตั้งค่าความปลอดภัยของ RustDesk โดยช่องพอร์ตจะมีค่าเริ่มต้นเป็น 21118 ให้ตรวจสอบว่าพอร์ตดังกล่าวเปิดใช้งานอยู่ก่อนที่จะพยายามเชื่อมต่อ:

ss -tlnp | grep 21118

จากนั้นให้เชื่อมต่อผ่าน VPN address ของ peer นั้นแทนการใช้ ID ทั้งนี้ FAQ ของ RustDesk ระบุว่าโหมดนี้การเชื่อมต่อจะไม่มีการเข้ารหัส ดังนั้นควรใช้งานภายใน tunnel เท่านั้นและห้ามใช้งานผ่านอินเทอร์เน็ตสาธารณะโดยเด็ดขาด เพราะ tunnel คือสิ่งที่ทำหน้าที่เข้ารหัสข้อมูลให้คุณ

การเลือกวิธีขึ้นอยู่กับว่าใครเป็นเจ้าของเครื่อง หากคุณต้องสนับสนุนเครื่องที่ไม่ใช่ของคุณ หรือผู้ใช้งานที่ไม่ต้องการติดตั้ง VPN client การใช้ hbbs และ hbbr แบบ self-hosted จะเหมาะสมกว่า เพราะฝั่งผู้ใช้งานจะใช้เพียง ID และรหัสผ่านเท่านั้น แต่หากเครื่องทั้งหมดเป็นของคุณและสามารถติดตั้ง key ได้ การใช้ mesh VPN พร้อม direct IP access จะเหมาะสมกว่า การเปรียบเทียบ WireGuard กับ Tailscale ครอบคลุมวิธีการสร้าง mesh สองรูปแบบที่นิยมใช้ และ การใช้งาน remote desktop บน Linux VPS ครอบคลุมกรณีอื่น ๆ ในสถานการณ์ที่เครื่องที่คุณต้องการเข้าถึงหน้าจอคือตัวเซิร์ฟเวอร์เอง

FAQ

ทุกเซสชันของ RustDesk ต้องผ่าน relay ของฉันหรือไม่?

ไม่จำเป็น hbbs จะพยายามเชื่อมต่อไคลเอนต์ทั้งสองฝั่งโดยตรงก่อน โดยใช้เทคนิค hole punching ผ่าน NAT ที่อยู่หน้าไคลเอนต์แต่ละฝั่ง เฉพาะเซสชันที่การเชื่อมต่อโดยตรงล้มเหลวเท่านั้นที่จะย้อนกลับไปใช้ hbbr และเซสชันเหล่านั้นเท่านั้นที่จะใช้แบนด์วิดท์ของคุณ ข้อยกเว้นคือ ALWAYS_USE_RELAY=Y บน hbbs ซึ่งจะบังคับให้ทุกเซสชันผ่าน hbbr โดยไม่คำนึงว่าจะมีเส้นทางเชื่อมต่อโดยตรงหรือไม่ หากมีการตั้งค่าตัวแปรนี้ไว้ในไฟล์ Compose ของคุณ ข้อมูลทุกไบต์ของทุกเซสชันจะถูกนำไปคำนวณค่าใช้จ่ายในการรับส่งข้อมูลของคุณ

คีย์ของเซิร์ฟเวอร์ RustDesk ถูกเก็บไว้ที่ใด และจะเกิดอะไรขึ้นหากทำหาย?

hbbs จะสร้าง id_ed25519 และ id_ed25519.pub ไว้ในไดเรกทอรีการทำงานเมื่อเริ่มทำงานครั้งแรก ไดเรกทอรีดังกล่าวคือ /root ภายในอิมเมจมาตรฐาน ดังนั้นเมื่อใช้ volume mount ตามที่แสดงไว้ข้างต้น ไฟล์เหล่านี้จะปรากฏอยู่ใน ./data บนโฮสต์ ให้สำรองไฟล์ทั้งสองไว้นอกเซิร์ฟเวอร์ หากไฟล์สูญหาย hbbs จะสร้างคู่คีย์ใหม่ในการเริ่มทำงานครั้งถัดไป และไคลเอนต์ทุกเครื่องที่ยังถือคีย์สาธารณะเดิมอยู่จะถูกปฏิเสธการเชื่อมต่อ โดยไม่มีวิธีกู้คืนอื่นนอกจากการแก้ไขช่อง Key บนไคลเอนต์แต่ละเครื่องด้วยตนเอง

ฉันต้องเปิดพอร์ตใดบ้างสำหรับเซิร์ฟเวอร์ RustDesk ที่โฮสต์เอง?

TCP 21115, 21116 และ 21117 รวมถึง UDP 21116 โดย hbbs ใช้ 21115 สำหรับการทดสอบประเภท NAT และใช้ 21116 สำหรับการลงทะเบียน ID และ heartbeat ผ่าน UDP รวมถึงใช้สำหรับ hole punching ผ่าน TCP ส่วน hbbr ใช้ 21117 สำหรับการทำ relay สำหรับ TCP 21118 และ 21119 เป็นพอร์ต WebSocket สำหรับไคลเอนต์บนเบราว์เซอร์ หากคุณไม่ได้ใช้งานให้ปิดพอร์ตเหล่านี้ไว้ ส่วน TCP 21114 เป็นพอร์ตสำหรับ Pro web console ซึ่งรุ่น open source ไม่จำเป็นต้องใช้งาน

คนแปลกหน้าสามารถใช้ relay ของ RustDesk ที่ฉันโฮสต์เองได้หรือไม่?

ได้ หากคุณรัน hbbr ด้วยการตั้งค่าเริ่มต้น เอกสารของ RustDesk ระบุว่าหากไม่มีการระบุคีย์ ไคลเอนต์ที่ไม่มีคีย์ที่ตรงกันจะสามารถใช้ relay ได้ ดังนั้นใครก็ตามที่ทราบชื่อโฮสต์และพอร์ต 21117 ของคุณจะสามารถส่งข้อมูลผ่านเซิร์ฟเวอร์ของคุณได้ คุณควรสั่งรัน hbbr ด้วย -k _ เพื่อให้โหลดคู่คีย์เดียวกับที่ hbbs สร้างไว้ใน volume ./data ที่ใช้ร่วมกัน หลังจากนั้นจะมีเพียงไคลเอนต์ที่กำหนดค่าด้วยคีย์สาธารณะของคุณเท่านั้นที่จะสามารถใช้งาน relay ผ่านเซิร์ฟเวอร์ของคุณได้