Cara Hosting Server Relay RustDesk di VPS Sendiri

Apa itu server relay RustDesk yang di-hosting sendiri

Server relay RustDesk yang di-hosting sendiri terdiri atas dua daemon pada satu VPS. hbbs adalah server ID dan rendezvous: daemon ini mendaftarkan setiap ID klien dan memperkenalkan kedua klien tersebut satu sama lain. hbbr adalah server relay: daemon ini membawa byte sesi, tetapi hanya untuk sesi yang tidak dapat berkomunikasi secara langsung. Sebagian besar panduan hanya memasang keduanya, membuat keduanya dapat terhubung, lalu berhenti di sana. Bagian berikut membahas pekerjaan lainnya: key yang berfungsi sebagai kontrol akses, port, upgrade, dan bandwidth.

Kedua daemon tersedia dalam image yang sama, rustdesk/rustdesk-server, dan keduanya membaca pasangan key Ed25519 yang sama dari direktori yang sama. Ed25519 adalah skema tanda tangan public key. Pasangan key tersebut menentukan klien mana yang dapat diajak berkomunikasi oleh server Anda, dan tidak ada database pengguna di baliknya.

hbbs dan hbbr: daemon mana yang menggunakan bandwidth Anda

Trafik hbbs kecil dan konstan: registrasi ID dan heartbeat, serta pertukaran singkat untuk memperkenalkan dua peer. hbbs berjalan sepanjang hari dan hampir tidak menggunakan bandwidth.

Trafik hbbr adalah sesi itu sendiri. Frame layar berjalan ke satu arah, sedangkan input keyboard dan mouse berjalan ke arah lain. Setiap byte yang direlay masuk ke VPS Anda, lalu keluar lagi. Jika provider hanya menghitung egress, sesi yang direlay menghabiskan bandwidth kira-kira sebesar laju sesi tersebut. Jika provider menghitung total transfer, biayanya kira-kira dua kali lipat.

Relay adalah jalur cadangan, bukan jalur normal. hbbs terlebih dahulu mencoba menghubungkan kedua klien secara langsung menggunakan hole punching melalui NAT (network address translation) yang berada di depan masing-masing klien. Jika berhasil, sesi tidak pernah melewati hbbr dan kuota transfer Anda tidak berkurang. Jika salah satu sisi berada di balik NAT yang menetapkan port baru untuk setiap tujuan, atau firewall yang memblokir jalur hasil hole punching, sesi akan beralih ke hbbr dan setiap frame melewati VPS Anda.

Satu variabel lingkungan menghilangkan pilihan tersebut. ALWAYS_USE_RELAY=Y pada hbbs memaksa setiap sesi melewati hbbr. Dokumentasi RustDesk menampilkannya dalam salah satu contoh Compose, sehingga banyak orang menyalinnya. Variabel ini membuat koneksi lebih konsisten, tetapi juga membuat egress Anda benar-benar digunakan. Tetapkan variabel tersebut karena Anda memang memutuskan untuk menggunakannya, bukan karena Anda menyalinnya.

Port apa yang diperlukan server RustDesk yang di-host sendiri

Nomor port di bawah ini telah diperiksa terhadap dokumentasi server RustDesk dan repositori rustdesk-server pada 17 August 2026.

• TCP 21115, pada hbbs: pengujian tipe NAT.
• UDP 21116, pada hbbs: pendaftaran ID dan heartbeat. Tanpa port ini, client tidak pernah online, terlepas dari port lain yang dibuka.
• TCP 21116, pada hbbs: TCP hole punching dan service koneksi.
• TCP 21117, pada hbbr: relay. Port ini meneruskan data sesi, sehingga penggunaan port inilah yang menimbulkan biaya.
• TCP 21118 pada hbbs dan TCP 21119 pada hbbr: WebSocket, yang digunakan oleh client browser. Biarkan keduanya tertutup jika Anda tidak menggunakan fitur ini.
• TCP 21114 adalah konsol web pada RustDesk Server Pro. Build open source tidak listen pada port ini.

Instal hbbs dan hbbr dengan tag image yang ditetapkan

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

Kedua service harus membaca running. Pastikan listener tersedia sebelum mengubah firewall.

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

Anda harus melihat listener TCP pada 21115, 21116, dan 21117, serta listener UDP pada 21116. Baris UDP yang tidak ada berarti hbbs tidak berjalan, karena listener tersebut digunakan klien untuk melakukan registrasi.

Empat hal dalam file tersebut ditetapkan secara sengaja. Tag-nya adalah 1.1.16, yaitu rilis saat ini per Agustus 2026 yang dipublikasikan pada 20 July 2026, bukan latest, karena latest berarti tag apa pun yang paling baru di-push dan docker compose pull enam bulan dari sekarang dapat memberikan server yang belum pernah Anda uji. network_mode: "host" mengikat interface host secara langsung. Ini direkomendasikan dalam dokumentasi RustDesk dan menentukan cara kerja firewall Anda. ./data:/root memetakan direktori kerja image ke host, sehingga pasangan key tersimpan di lokasi yang dapat Anda cadangkan. hbbr -k _ adalah satu-satunya perubahan dari contoh upstream, karena konfigurasi default membuat relay terbuka untuk siapa saja. Jika Compose masih baru bagi Anda, menjalankan Docker Compose pada VPS menjelaskan format file dan perintah untuk mengelola siklus hidupnya.

Jika hbbr dipindahkan ke server kedua, hbbs harus diberi tahu lokasi barunya: teruskan -r relay.example.com:21117 atau tetapkan environment variable RELAY-SERVERS. Pada satu server, Anda tidak memerlukannya.

Pasangan kunci Ed25519 adalah pengendali akses

Saat pertama kali dijalankan, hbbs membuat id_ed25519 dan id_ed25519.pub di direktori kerjanya. Dengan mount di atas, kedua file tersebut akan muncul di host.

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

id_ed25519.pub berisi satu string base64. Masukkan string tersebut ke kolom Key pada setiap client. id_ed25519 adalah bagian privat dan tidak pernah meninggalkan server. Kunci publik bukan rahasia karena memang disalin ke konfigurasi setiap client. Kunci privat adalah rahasia: siapa pun yang memilikinya dapat menjalankan server yang akan dipercaya oleh client Anda.

Cadangkan kedua file tersebut sekarang, sebelum Anda mengonfigurasi dua puluh client.

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

Salin arsip tersebut ke luar server. Berikut alasan langkah ini lebih penting daripada langkah lainnya. Jika Anda menghapus ~/rustdesk/data atau membangun ulang pada VPS baru tanpa menyalinnya, hbbs akan membuat pasangan kunci baru saat dijalankan berikutnya. Setiap client masih menyimpan kunci publik lama, sehingga hbbs menolaknya dan client menjadi offline. Jalankan sudo cat ~/rustdesk/data/id_ed25519.pub dan bandingkan hasilnya dengan kolom Key pada client mana pun: kedua string tersebut tidak lagi cocok, dan ketidakcocokan itu adalah satu-satunya penyebab kegagalan. Untuk memperbaikinya, Anda harus mengedit pengaturan secara manual pada setiap mesin, termasuk mesin yang ingin Anda akses menggunakan RustDesk.

Kunci tersebut bukan kata sandi sesi. Jika keduanya tertukar, salah satunya dapat terlewat. Kunci menentukan client mana yang dapat berkomunikasi dengan server Anda. Kata sandi permanen atau kode sekali pakai pada mesin yang dikendalikan menentukan siapa yang boleh membuka sesi pada mesin tersebut. Anda memerlukan keduanya. Memiliki salah satunya tidak menggantikan yang lain jika yang lain lemah.

Mengapa relay tanpa autentikasi menjadi masalah

Secara default, hbbr tidak memeriksa apa pun. Dokumentasi konfigurasi RustDesk menyatakannya secara langsung: key kosong memungkinkan client tanpa key yang cocok menggunakan relay. Nilai default yang kosong tersedia agar pengguna baru tidak mengalami kegagalan akibat ketidakcocokan key pada proses pertama. Konsekuensinya, siapa pun yang menemukan alamat Anda pada TCP 21117 dapat meneruskan trafik sesi mereka melalui VPS Anda, menggunakan kuota transfer Anda dan alamat IP Anda.

command: hbbr -k _ mengatasi masalah tersebut. Argumen _ memberi tahu hbbr untuk memuat key pair dari working directory-nya. Karena kedua container me-mount ./data yang sama, key pair tersebut adalah key pair yang sebelumnya dibuat oleh hbbs. Tidak ada file yang perlu disalin secara manual, sehingga keduanya tidak dapat berbeda.

Shared volume adalah bagian yang sering salah dikonfigurasi. Jika Anda memberi hbbr direktori sendiri, hbbr akan menghasilkan key pair yang berbeda. Akibatnya, hbbs dan hbbr tidak lagi menggunakan key pair yang sama, semua sesi yang diteruskan melalui relay gagal, sedangkan sesi langsung tetap berfungsi. Gejalanya membingungkan: RustDesk dapat terhubung ke sebagian peer, tetapi tidak ke peer lainnya, bergantung pada apakah hole punching berhasil. Satu ls -l ~/rustdesk/data/ yang menampilkan satu pasangan id_ed25519 akan menghilangkan kemungkinan tersebut.

Arahkan client ke server Anda

Pada setiap mesin, buka RustDesk, lalu Settings, kemudian Network, lalu ID/Relay Server.

• ID Server: hostname Anda, misalnya rustdesk.example.com. Client menggunakan port 21116 kecuali Anda menuliskan port lain.
• Relay Server: biarkan kosong jika hbbr berjalan pada host yang sama dengan hbbs.
• API Server: biarkan kosong. Server open source ini tidak menyediakannya.
• Key: string base64 dari id_ed25519.pub, tempelkan persis tanpa spasi di akhir.

Jendela utama kemudian akan melaporkan bahwa client siap. Jika tidak, UDP 21116 tidak mencapai hbbs karena registrasi dan heartbeat berjalan melalui UDP, dan tidak ada komponen lain yang membuat ID kembali online.

Batasi port agar relay bukan layanan terbuka

Karena container menggunakan host networking, tidak ada aturan Docker NAT di depannya. Dengan demikian, aturan ufw berlaku sesuai yang diharapkan.

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

Tambahkan 21118:21119/tcp hanya jika Anda menjalankan browser client. Biarkan sesi SSH kedua tetap terbuka saat mengaktifkan ufw, sehingga kesalahan pada aturan SSH tidak mengunci Anda dari server sendiri. Dasar-dasar firewall ufw untuk VPS membahas kebijakan default dan urutan aturan.

Sekarang perhatikan masalahnya. Jika Anda beralih ke publikasi port menggunakan blok ports:, seperti pada contoh alternative RustDesk supervisor image, Docker menulis aturan DNAT-nya sendiri. Akibatnya, paket mencapai container tanpa melewati chain tempat aturan ufw berada. Deny ufw pada port 21117 tidak akan berpengaruh, dan relay terbuka ke Internet meskipun ufw status menyatakan sebaliknya. Port yang dipublikasikan Docker melewati ufw menjelaskan urutan chain tersebut. Host networking sepenuhnya menghindari masalah ini. Jika Anda memang memublikasikan port, ikat port tersebut ke satu alamat, seperti "127.0.0.1:21118:21118" di belakang reverse proxy.

Pembatasan berdasarkan alamat sumber hanya berfungsi jika client Anda memiliki alamat yang stabil.

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

Laptop pada jaringan hotel tidak memiliki alamat yang stabil. Karena itu, key pada hbbr lebih berperan dalam situasi ini daripada firewall.

Memutakhirkan stack yang menyimpan key Anda

Key berada di bind mount, bukan di dalam container. Karena itu, proses upgrade aman selama Anda tidak mengubah ./data.

1. Cadangkan direktori data terlebih dahulu: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. Baca catatan rilis untuk tag baru pada halaman rilis rustdesk-server.
3. Edit compose.yml dan ubah kedua baris image: ke tag baru.
4. Jalankan sudo docker compose pull, lalu sudo docker compose up -d.
5. Jalankan sudo cat ~/rustdesk/data/id_ed25519.pub dan pastikan string tersebut sama dengan yang sudah dimiliki klien Anda.

Langkah 5 adalah pemeriksaan yang penting. Key yang berubah tidak menimbulkan indikasi pada server dan akan membuat semua klien gagal pada saat yang sama. Untuk melakukan rollback, kembalikan tag lama lalu jalankan up -d lagi. Ini hanya berfungsi karena tag tersebut ditetapkan secara eksplisit. Dengan latest, docker compose pull memindahkan nama tersebut ke image baru, sehingga tidak ada tag yang masih merujuk ke image lama.

Key biasanya hilang bukan karena docker compose down, yang tidak mengubah bind mount. Penyebabnya adalah migrasi ke VPS baru dan hanya menyalin compose.yml. Salin juga ./data.

Pantau egress pada paket dengan batas transfer

hbbr adalah satu-satunya komponen dalam stack ini yang dapat menghabiskan batas transfer. FAQ RustDesk menyebutkan bahwa satu koneksi yang direlay pada layar 1920x1080 menggunakan antara 30 KB/s dan 3 MB/s, sedangkan pekerjaan kantor biasa menggunakan sekitar 100 KB/s. Angka tersebut adalah angka yang dipublikasikan untuk satu sesi, bukan hasil pengukuran pada pengaturan Anda. Jika dihitung untuk enam puluh jam per bulan, dua jam per hari, hasilnya adalah sebagai berikut.

[
  {
    "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
  }
]

Pada laju pekerjaan kantor, satu sesi menggunakan sekitar 21.6 GB per bulan, sehingga tidak akan terlihat pada paket mana pun. Pada batas atas rentang yang dipublikasikan, enam puluh jam yang sama menggunakan 648 GB, dan dua sesi bersamaan pada laju tersebut akan melampaui batas 1 TB dalam satu bulan. Batas bawahnya adalah 6.5 GB. Di sini, gigabyte berarti 1000 MB, sesuai cara batas transfer biasanya dihitung.

docker stats tidak dapat merincinya untuk Anda karena container yang menggunakan host networking berbagi network namespace milik host. Oleh karena itu, penghitungnya adalah penghitung milik host. Dua alat lain dapat digunakan. vnstat mengukur seluruh server:

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

Seluruh server berarti seluruh server. Jika VPS ini juga menjalankan sesuatu yang memindahkan data dalam jumlah besar, misalnya salah satu server foto yang di-host sendiri yang setiap malam mengambil pustaka foto dari ponsel, upload tersebut dihitung dalam batas bulanan yang sama dengan trafik relay Anda. Media server juga mengikuti prinsip yang sama dari arah sebaliknya. Layanan seperti Halcyon, yang mengubah pustaka Jellyfin menjadi toko video 90-an yang dapat ditelusuri mengirimkan stream kepada siapa pun yang menonton, dan egress tersebut menggunakan batas yang sama dengan yang digunakan relay Anda.

Counter nftables mengukur relay secara khusus:

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

Rule tersebut tidak memiliki verdict. Jadi, rule hanya menghitung paket dan byte tanpa mengubah apa yang diizinkan. Rule tersebut juga berada dalam table tersendiri sehingga tidak mengganggu ufw. Counter ini tidak persisten. Tambahkan baris yang sama ke /etc/nftables.conf jika ingin mengaktifkannya kembali setelah reboot. Counter hanya bertambah saat sesi benar-benar direlay. Jika counter terus bertambah saat tidak ada komputer Anda yang terhubung, berarti orang lain telah menemukan relay Anda. Inilah kondisi yang ingin dicegah oleh hbbr -k _. Karena Anda tidak akan membaca nft list setiap pagi, pasang cron job untuk membandingkan jumlah byte dengan ambang batas dan mengirimkan push alert saat ambang tersebut terlampaui. Tugas ini dapat ditangani oleh server ntfy milik Anda sendiri.

hbbr juga memiliki batas laju yang dapat Anda turunkan. SINGLE_BANDWIDTH secara default bernilai 128 Mb/s untuk setiap koneksi relay, sedangkan TOTAL_BANDWIDTH bernilai 1024 Mb/s untuk seluruh koneksi. Dengan menetapkan SINGLE_BANDWIDTH=8, satu sesi dibatasi hingga sekitar 1 MB/s. Pengaturan ini membatasi kecepatan, bukan total bulanan. Jadi, gunakan pengaturan ini untuk mencegah satu sesi memenuhi kapasitas link, bukan sebagai pengendali anggaran transfer.

Tidak memerlukan relay sama sekali

Untuk penggunaan pribadi, jawaban yang tepat mungkin Anda tidak memerlukan semua ini. Hubungkan kedua mesin ke mesh VPN, lalu sambungkan langsung ke alamat tunnel. Tidak ada hbbs, tidak ada hbbr, tidak ada egress relay, dan tidak ada container pada VPS yang perlu di-upgrade.

Pada mesin yang ingin Anda kendalikan, aktifkan akses IP langsung pada pengaturan keamanan RustDesk. Kolom port secara default berisi 21118. Pastikan port tersebut sedang listening sebelum mencoba terhubung:

ss -tlnp | grep 21118

Selanjutnya, sambungkan ke alamat VPN peer tersebut, bukan ke ID. FAQ RustDesk menyatakan bahwa koneksi dalam mode ini tidak terenkripsi. Karena itu, jalankan koneksi di dalam tunnel dan jangan pernah menggunakannya melalui Internet terbuka. Tunnel tersebut yang menyediakan enkripsi.

Tentukan pilihan berdasarkan kepemilikan mesin. hbbs dan hbbr yang di-self-host sesuai jika Anda mendukung mesin yang bukan milik Anda atau pengguna yang tidak akan pernah memasang VPN client, karena sisi mereka hanya memerlukan ID dan password. Mesh VPN dengan akses IP langsung sesuai jika semua mesin milik Anda dan dapat menggunakan key. WireGuard dibandingkan dengan Tailscale membahas dua cara yang umum untuk membangun mesh tersebut, sedangkan menjalankan remote desktop pada Linux VPS membahas kasus lain, yaitu ketika mesin yang ingin Anda akses layarnya adalah server itu sendiri.

FAQ

Apakah setiap sesi RustDesk melewati relay saya?

Tidak. hbbs terlebih dahulu mencoba menghubungkan kedua client secara langsung menggunakan hole punching melalui NAT di depan masing-masing client. Hanya sesi yang gagal menggunakan metode tersebut yang beralih ke hbbr, dan hanya sesi itulah yang menggunakan bandwidth Anda. Pengecualiannya adalah ALWAYS_USE_RELAY=Y pada hbbs, yang memaksa setiap sesi melewati hbbr meskipun jalur langsung tersedia. Jika variabel tersebut ditetapkan dalam file Compose Anda, setiap byte dari setiap sesi akan masuk ke tagihan transfer Anda.

Di mana kunci server RustDesk disimpan, dan apa yang terjadi jika saya kehilangannya?

hbbs membuat id_ed25519 dan id_ed25519.pub di direktori kerjanya saat pertama kali dijalankan. Direktori tersebut adalah /root di dalam image resmi, sehingga dengan volume mount yang ditunjukkan di atas, file tersebut muncul di ./data pada host. Cadangkan kedua file tersebut di luar server. Jika file tersebut hilang, hbbs membuat pasangan baru saat dijalankan berikutnya, dan setiap client yang masih menyimpan public key lama akan ditolak. Tidak ada cara pemulihan selain mengedit kolom Key secara manual pada setiap client.

Port apa yang perlu dibuka untuk server RustDesk yang di-host sendiri?

TCP 21115, 21116, dan 21117, serta UDP 21116. hbbs menggunakan 21115 untuk pengujian jenis NAT, dan 21116 untuk registrasi ID serta heartbeat melalui UDP dan untuk hole punching melalui TCP. hbbr menggunakan 21117 untuk relay. TCP 21118 dan 21119 adalah port WebSocket untuk client browser, jadi biarkan tetap tertutup jika Anda tidak menggunakannya. TCP 21114 digunakan oleh konsol web Pro, sedangkan build open source tidak memerlukannya.

Apakah orang asing dapat menggunakan relay RustDesk yang saya host sendiri?

Ya, jika Anda menjalankan hbbr dengan konfigurasi default. Dokumentasi RustDesk menyatakan bahwa key kosong memungkinkan client tanpa key yang cocok menggunakan relay, sehingga siapa pun yang mengetahui hostname dan port 21117 Anda dapat mengalirkan trafik melalui server tersebut. Jalankan hbbr dengan -k _ agar memuat pasangan key yang sama dengan yang dibuat hbbs di volume bersama ./data. Setelah itu, hanya client yang dikonfigurasi dengan public key Anda yang dapat menggunakan relay Anda.