Cara Hosting Server Relay RustDesk di VPS Sendiri

Apa itu server relay RustDesk yang di-host sendiri

Server relay RustDesk yang di-host sendiri terdiri atas dua daemon pada satu VPS. hbbs adalah server ID dan rendezvous: daemon ini mendaftarkan setiap ID klien dan memperkenalkan dua klien 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 memasang keduanya, membuat keduanya terhubung, lalu berhenti sampai di situ. Bagian berikut menjelaskan pekerjaan lainnya: kunci yang berfungsi sebagai kontrol akses, port, upgrade, dan bandwidth.

Kedua daemon tersedia dalam image yang sama, rustdesk/rustdesk-server, dan pada konfigurasi di bawah ini keduanya membaca pasangan kunci Ed25519 yang sama dari direktori yang sama. Hal tersebut harus Anda konfigurasi dan bukan merupakan perilaku default: hbbs memuat atau membuat pasangan kunci sendiri, tetapi hbbr mengabaikan kunci kecuali Anda menjalankannya dengan kunci tersebut. Ed25519 adalah skema tanda tangan kunci publik. Pasangan kunci tersebut menentukan klien mana yang dapat berkomunikasi dengan 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 berdasarkan dokumentasi server RustDesk dan repositori rustdesk-server pada 10 October 2026.

• TCP 21115, pada hbbs: pengujian jenis NAT.
• UDP 21116, pada hbbs: pendaftaran ID dan heartbeat. Ini adalah jalur yang digunakan client secara default.
• TCP 21116, pada hbbs: pendaftaran ID untuk client yang hanya menggunakan TCP, serta TCP hole punching dan layanan koneksi.
• TCP 21117, pada hbbr: relay. Port ini memindahkan 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 menggunakannya.
• TCP 21114 adalah server HTTP API di 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. Jika baris UDP tidak ada, berarti hbbs tidak berjalan, karena hbbs membuka listener tersebut saat start dan secara default listener itu digunakan client untuk melakukan registrasi.

Ada empat hal dalam file tersebut yang sengaja ditetapkan. Tag-nya adalah 1.1.16, yang masih merupakan rilis saat ini per Oktober 2026 dan dipublikasikan pada 20 Juli 2026, bukan latest, karena latest berarti versi apa pun yang terakhir kali 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. Inilah yang direkomendasikan dokumentasi RustDesk dan yang menentukan perilaku firewall Anda. ./data:/root memetakan direktori kerja image ke host, sehingga pasangan key tersimpan di lokasi yang dapat Anda backup. hbbr -k _ adalah satu-satunya perubahan dari contoh upstream, karena konfigurasi default membuat relay terbuka untuk siapa pun. Jika Compose masih baru bagi Anda, menjalankan Docker Compose pada VPS menjelaskan format file dan command untuk mengelola lifecycle.

Jika hbbr dipindahkan ke server kedua, hbbs harus diberi tahu tentang 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 ada agar pengguna baru tidak mengalami kegagalan karena ketidakcocokan key saat pertama kali menjalankan aplikasi. Konsekuensinya, siapa pun yang menemukan alamat Anda pada TCP 21117 dapat meneruskan trafik sesi mereka melalui VPS Anda, menggunakan kuota transfer dan alamat IP Anda.

command: hbbr -k _ mengatasi masalah tersebut. Argumen _ memberi tahu hbbr untuk memuat pasangan key dari direktori kerjanya, atau membuatnya jika belum ada. Karena kedua container me-mount ./data yang sama, pasangan tersebut sama dengan yang digunakan hbbs. Tidak ada yang perlu disalin secara manual, sehingga tidak ada risiko ketidaksesuaian.

Volume bersama adalah bagian yang sering dikonfigurasi secara keliru. Jika hbbr diberi direktori sendiri, hbbr akan membuat pasangan key yang berbeda. Akibatnya, hbbs dan hbbr tidak lagi menggunakan pasangan yang sama, semua sesi yang direlay 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 menyingkirkan kemungkinan ketidakcocokan tersebut. Namun, hal itu tidak membuktikan bahwa relay memeriksa key, karena hbbr mengabaikan file tersebut jika tidak dijalankan dengan key yang tidak kosong. Karena itu, periksa juga command yang sedang berjalan:

ps -eo args | grep '[h]bbr'

Perintah tersebut seharusnya menampilkan hbbr -k _. hbbr tanpa argumen berarti relay masih terbuka, terlepas dari isi direktori tersebut.

Arahkan klien ke server Anda

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

• ID Server: hostname Anda, misalnya rustdesk.example.com. Klien 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 tidak menyediakan API tersebut.
• Key: string base64 dari id_ed25519.pub, tempelkan persis tanpa spasi di akhir.

Jendela utama kemudian seharusnya melaporkan bahwa klien siap. Jika tidak, dan klien berjalan dengan pengaturan default, penyebab yang umum adalah UDP 21116 tidak dapat mencapai hbbs. Pada port tersebut klien default melakukan registrasi dan mengirim heartbeat. Namun, ID offline saja tidak cukup untuk membuktikan hal itu. Klien dengan opsi disable-udp yang diatur ke Y melakukan registrasi melalui TCP 21116 dan tidak pernah menggunakan UDP 21116. Untuk klien tersebut, periksa TCP 21116 terlebih dahulu.

Batasi port agar relay bukan layanan terbuka

Karena container menggunakan host networking, tidak ada aturan Docker NAT di depannya. Oleh karena itu, 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, agar kesalahan pada aturan SSH tidak membuat Anda terkunci dari server sendiri. Dasar-dasar firewall ufw untuk VPS menjelaskan kebijakan default dan urutan aturan.

Sekarang perhatikan jebakannya. Jika Anda beralih ke publikasi port dengan blok ports:, seperti yang digunakan banyak contoh RustDesk dengan satu container, Docker menulis aturan DNAT-nya sendiri. Akibatnya, paket mencapai container tanpa melewati chain tempat aturan ufw Anda berada. Deny ufw pada 21117 tidak akan berpengaruh, dan relay terbuka ke Internet sementara ufw status menyatakan sebaliknya. Port yang dipublikasikan Docker melewati ufw menjelaskan urutan chain tersebut. Host networking sepenuhnya menghindari masalah ini. Jika Anda memublikasikan port, bind port tersebut ke satu alamat, seperti pada "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 kasus 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 klien secara langsung menggunakan hole punching melalui NAT di depan masing-masing klien. Hanya sesi yang gagal menggunakan cara tersebut yang dialihkan ke hbbr, dan hanya sesi itu 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. Dengan volume mount yang ditunjukkan di atas, file tersebut akan muncul di ./data pada host. Cadangkan kedua file tersebut di luar server. Jika file tersebut hilang, hbbs akan membuat pasangan kunci baru saat dijalankan berikutnya, dan setiap klien yang masih menyimpan kunci publik lama akan ditolak. Tidak ada cara pemulihan selain mengedit kolom Key pada setiap klien secara manual.

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 tipe NAT dan 21116 untuk registrasi ID serta heartbeat melalui UDP, dan untuk registrasi serta hole punching melalui TCP. hbbr menggunakan 21117 untuk relay. TCP 21118 dan 21119 adalah port WebSocket untuk klien browser. Biarkan port tersebut tertutup jika Anda tidak menggunakannya. TCP 21114 digunakan oleh server HTTP API Pro, dan tidak diperlukan oleh build open source.

Dapatkah orang asing menggunakan relay RustDesk yang saya host sendiri?

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