Server desktop jarak jauh Linux: pengaturan X11VNC dan daemon RustDesk

Anda ingin memungkinkan orang lain (atau diri Anda sendiri) terhubung ke desktop Linux secara andal, aman, dan tanpa melewati layanan proprietari berbiaya tinggi — dan panduan yang Anda temukan terlalu kabur atau ditulis untuk pengguna yang hanya memakai GUI. Panduan ini menunjukkan dua pendekatan server-side praktis untuk server desktop jarak jauh Linux: pengaturan X11VNC yang terbukti untuk mengekspos sesi X secara langsung, dan daemon RustDesk yang di-host sendiri (hbbs/hbbr) untuk traversal NAT modern dan relay — disertai perintah nyata, unit systemd, contoh Docker, dan langkah penguatan konkret.

Mengapa menjalankan server desktop jarak jauh Linux? Pohon keputusan singkat

Sebelum masuk ke perintah: pilih model yang sesuai kebutuhan Anda.

• Jika Anda membutuhkan akses langsung ke sesi X fisik pada mesin (mendukung pengguna yang sedang login, status sesi lokal, beberapa monitor), X11VNC adalah alat sisi-server yang paling sederhana.
• Jika Anda menginginkan model klien/server yang mendukung traversal NAT, server ID, relay, dan klien lintas platform yang lebih mudah — dan Anda ingin meng-host komponen server tersebut sendiri — jalankan daemon hbbs/hbbr milik RustDesk.
• Jika Anda hanya ingin tunnel cepat satu mesin untuk dukungan sekali pakai, tunnel SSH atau menggunakan layanan hosted mungkin tetap lebih cepat. Lihat juga panduan kami tentang self-hosted remote desktop untuk strategi dan tradeoff.

Catatan: produk komersial seperti TeamViewer dan AnyDesk sering unggul dalam hal kenyamanan murni (traversal NAT otomatis dan codec yang dioptimalkan langsung). Mereka pilihan yang masuk akal jika Anda membutuhkan keandalan plug-and-play dan dukungan komersial; lihat perbandingan kami untuk tradeoff fitur di rustdesk-vs-anydesk.

1) X11VNC: server desktop jarak jauh Linux minimal yang mengekspos sesi X fisik

X11VNC terhubung ke server X yang sudah berjalan dan menyajikan desktop saat ini. Ini bukan desktop virtual terpisah — melainkan mencerminkan GUI yang dilihat pengguna lokal. Itu membuatnya sangat cocok untuk dukungan jarak jauh dan administrasi ketika Anda ingin berinteraksi dengan sesi yang sama seperti yang dilihat pengguna lokal.

Prasyarat dan versi yang disarankan

• Bekerja pada desktop berbasis X11. Untuk Wayland, gunakan API remote spesifik compositor atau pendekatan berbeda.
• Instal x11vnc >= 0.9.16 (0.9.16+ mendukung fitur modern dan peningkatan stabilitas).
• Pastikan Anda memiliki display manager (gdm/lightdm/sddm) atau sesi X berjalan pada :0.

Instal di Debian/Ubuntu (contoh):

sudo apt update
sudo apt install -y x11vnc xauth

Buat file password (simpan dengan aman):

sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo chown root:root /etc/x11vnc.pass
sudo chmod 600 /etc/x11vnc.pass

Unit systemd sederhana untuk auto-start pada display :0 (letakkan sebagai /etc/systemd/system/x11vnc.service):

[Unit]
Description=x11vnc - VNC server for :0
After=display-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared -ncache 10
User=root
Restart=on-failure

[Install]
WantedBy=graphical.target

Aktifkan dan mulai:

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo systemctl status x11vnc.service

Catatan keamanan untuk X11VNC

• Jangan membuka TCP/5900 langsung ke internet tanpa proteksi tambahan. Autentikasi VNC cukup untuk penggunaan LAN tetapi harus dianggap lemah di jaringan publik.
• Prefer tunnel SSH untuk akses jarak jauh: ssh -L 5900:localhost:5900 user@your-server dan kemudian hubungkan klien VNC ke localhost:5900.
• Jika Anda membutuhkan TLS langsung, gunakan stunnel atau VPN. Atau tempatkan VNC di balik firewall yang tepat dan wajibkan akses VPN.

Tips performa

• Gunakan -ncache 10 untuk mengurangi lonjakan bandwidth saat konten desktop berubah cepat.
• Jika Anda melihat CPU tinggi pada link 1–2 Mbps, kurangi kedalaman warna atau gunakan flag kompresi (x11vnc mendukung -compresslevel dan -quality). Eksperimen — kualitas lebih rendah sering memberikan respons yang dirasakan lebih baik.

2) RustDesk daemon: relay dan server ID yang di-host sendiri untuk akses jarak jauh modern

RustDesk menyediakan klien yang dapat menggunakan server ID pusat (hbbs) dan relay (hbbr) untuk menghubungkan peer bahkan ketika berada di balik NAT. Menjalankan hbbs/hbbr sendiri memberi Anda kontrol penuh atas ID dan relay — penting jika Anda ingin menghindari server pihak ketiga. Ini adalah pengaturan sisi-server yang dimaksud kebanyakan orang ketika mereka menanyakan server desktop jarak jauh Linux dalam model yang di-host sendiri.

Mengapa menjalankan hbbs/hbbr alih-alih satu binary? Hbbs adalah server ID (autentikasi, penugasan), hbbr adalah server relay (relay TCP/UDP untuk media ketika P2P langsung gagal). Keduanya ringan dan umum dijalankan di Docker.

Versi yang disarankan: gunakan komponen server rustdesk versi 1.1.9+ (atau tag stabil terbaru saat Anda melakukan deploy). Tinjau catatan rilis di proyek RustDesk sebelum roll-out produksi.

Contoh Docker Compose untuk hbbs + hbbr (minimal)

version: '3.3'
services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"  # hbbs TCP (ID server)
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbs:/data

  hbbr:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbr
    restart: unless-stopped
    ports:
      - "21116:21116/tcp"  # hbbr TCP (relay)
      - "21116:21116/udp"  # hbbr UDP for hole punching/relay
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbr:/data

Catatan tentang port dan NAT

• Port default RustDesk yang umum dipetakan adalah 21115 (hbbs ID server) dan 21116 (hbbr relay). UDP berguna untuk traversal NAT; buka TCP dan UDP jika memungkinkan.
• Tempatkan server pada IP publik atau host dengan IP/DNS statis. Gunakan record A/AAAA untuk hostname yang Anda konfigurasi di klien.

Mengonfigurasi sisi klien

Arahkan klien RustDesk ke hostname hbbs Anda dan aktifkan relay sesuai kebutuhan. Anda bisa memaksa penggunaan relay untuk privasi atau membolehkan peer-to-peer jika kedua klien dapat melakukan hole punching NAT. UI konfigurasi klien menerima hostname dan port server Anda (mis. server.example.com:21115).

Mengamankan deployment daemon RustDesk yang di-host sendiri

Traffic default RustDesk terenkripsi antar peer, tetapi komponen server mengautentikasi dan mengoordinasikan. Pertimbangkan langkah penguatan berikut:

• Jalankan hbbs/hbbr di balik firewall dan buka hanya port yang diperlukan (21115 TCP, 21116 TCP/UDP). Gunakan UFW atau firewall-cmd; contoh: sudo ufw allow 21115/tcp; sudo ufw allow 21116/tcp; sudo ufw allow 21116/udp.
• Gunakan TLS/HTTPS untuk UI admin yang menghadap web jika Anda menambahkannya. Jika TLS diakhiri di reverse proxy (nginx/caddy), jaga backend tetap terisolasi.
• Monitor log dan penggunaan sumber daya. Komponen RustDesk ringan tetapi Anda harus memantau jumlah koneksi dan bandwidth relay.
• Pertimbangkan pembatasan laju dan fail2ban pada host jika Anda melihat percobaan brute-force terhadap port hbbs.

Kapan memilih RustDesk vs X11VNC

• Pilih RustDesk ketika Anda membutuhkan dukungan klien lintas platform (Windows/Mac/Linux/Android/iOS), traversal NAT, dan satu ID/relay yang di-host sendiri untuk banyak endpoint. Ini solusi modern untuk fleet terdistribusi.
• Pilih X11VNC ketika Anda melayani mesin desktop tertentu dan perlu berinteraksi dengan sesi X lokal (misalnya, memecahkan masalah pengguna yang sedang login atau masalah boot grafis).

Catatan produksi praktis dan tuning performa

Bandwidth dan CPU: perkirakan sesi desktop jarak jauh langsung mengonsumsi antara 1–5 Mbps untuk tugas kantor umum dengan codec terkompresi; screen-sharing video atau game akan menyebabkan lonjakan jauh lebih tinggi. Jika Anda men-host relay sendiri (hbbr), anggarkan bandwidth relay: 100 sesi bersamaan pada 2 Mbps = ~200 Mbps kapasitas kontinu.

Monitoring dan autoscaling: untuk organisasi besar, jalankan hbbs dengan HA proxy kecil atau load balancer di depan, dan jalankan beberapa relay hbbr yang didistribusikan di berbagai region. Gunakan orkestrasi container standar (Docker Swarm atau Kubernetes) jika Anda membutuhkan auto-scaling; jika tidak, satu VM relay yang kuat cukup untuk tim kecil.

Logging dan troubleshooting

• Log x11vnc muncul di systemd journal: sudo journalctl -u x11vnc.service
• Container RustDesk: docker logs rustdesk_hbbs dan docker logs rustdesk_hbbr untuk kesalahan startup. Periksa keterjangkauan port dengan ss atau netstat dan uji UDP/TCP dari klien remote.
• Jika koneksi langsung gagal, pastikan UDP tidak diblokir oleh NAT perantara atau firewall; banyak operator memblokir rentang UDP yang tidak umum.

Perbandingan keamanan dan pandangan vendor yang jujur

Jika keamanan dan privasi adalah prioritas utama, meng-host hbbs/hbbr sendiri memberi Anda kontrol metadata dan endpoint relay. Namun, vendor proprietari seperti TeamViewer atau AnyDesk mungkin menyediakan traversal NAT siap-pakai yang lebih kuat, codec proprietari dengan bitrate lebih rendah untuk link buruk, dan dukungan/ SLA kelas enterprise. Mereka bisa lebih baik jika Anda membutuhkan dukungan komersial 24/7 yang terjamin dan onboarding yang lebih mudah untuk pengguna non-teknis — tapi kenyamanan itu berbiaya. Lihat anydesk-pricing-explained untuk perbedaan harga dan tradeoff.

Checklist praktis sebelum go-live

1. Tentukan model yang sesuai (X11VNC untuk sesi fisik vs RustDesk untuk akses berbasis ID/relay).
2. Kuatkan server: firewall, hanya SSH key, fail2ban untuk pembatasan laju, dan TLS bila relevan.
3. Uji dari luar jaringan Anda: verifikasi perilaku relay, latensi, dan failover.
4. Atur monitoring (log, bandwidth, restart proses) dan kebijakan alert untuk outage.

Bacaan lanjutan dan sumber internal

Jika Anda mengevaluasi opsi self-hosted yang lebih luas dan tradeoff, baca panduan self-hosted kami di /self-hosted-remote-desktop. Untuk perbandingan fitur terfokus antara RustDesk dan opsi komersial, lihat /rustdesk-vs-anydesk.

Catatan praktis terakhir

Kedua pendekatan dapat dipelihara, tetapi mereka memecahkan masalah yang sedikit berbeda. X11VNC sederhana dan dapat diprediksi untuk desktop tunggal; daemon RustDesk lebih mudah diskalakan untuk fleet dan menangani traversal NAT dengan baik bila dikonfigurasi dengan benar. Dalam semua kasus, jangan pernah mengekspos VNC tidak terenkripsi langsung ke internet — selalu gunakan tunnel SSH, VPN, atau relay yang diperteguh.

Siap mencoba sendiri? Unduh klien Tenvo (godeskflow) atau periksa dokumentasi server kami di /download — dan jika Anda membutuhkan opsi harga atau enterprise, lihat /pricing. Deploy instance uji, uji aturan firewall Anda, dan validasi perilaku klien sebelum rollout ke pengguna.