Come ospitare un relay server RustDesk

Che cos'è un relay server RustDesk self-hosted

Un relay server RustDesk self-hosted è costituito da due daemon eseguiti su un unico VPS. hbbs è il server ID e rendezvous: registra l'ID di ogni client e mette in contatto i due client. hbbr è il relay server: trasporta i dati della sessione, ma solo per le sessioni che non sono riuscite a comunicare direttamente. La maggior parte delle guide installa entrambi i componenti, configura l'associazione tra i client e si ferma qui. Il resto del lavoro comprende la chiave che controlla l'accesso, le porte, l'aggiornamento e la larghezza di banda.

Entrambi i daemon sono distribuiti nella stessa image, rustdesk/rustdesk-server, e leggono la stessa coppia di chiavi Ed25519 dalla stessa directory. Ed25519 è uno schema di firma a chiave pubblica. La coppia di chiavi determina con quali client il server comunicherà; non esiste alcun database degli utenti.

hbbs e hbbr: quale daemon consuma la tua larghezza di banda

Il traffico di hbbs è ridotto e costante: registrazione degli ID e heartbeat, oltre al breve scambio che presenta tra loro due peer. Il servizio rimane attivo tutto il giorno e ha un costo quasi nullo.

Il traffico di hbbr corrisponde alla sessione vera e propria. I fotogrammi dello schermo viaggiano in una direzione, la tastiera e il mouse nell’altra, e ogni byte inoltrato arriva al tuo VPS e poi ne esce. Se il provider misura solo il traffico in uscita, una sessione inoltrata ti costa circa quanto il traffico della sessione. Se misura il trasferimento totale, il costo è circa il doppio.

Il relay è un percorso di fallback, non quello normale. hbbs prova prima a collegare direttamente i due client, usando il hole punching attraverso il NAT (network address translation) presente davanti a ciascuno di essi. Quando funziona, la sessione non passa mai da hbbr e il limite di trasferimento non viene consumato. Se un lato si trova dietro un NAT che assegna una porta diversa per ogni destinazione, oppure dietro un firewall che blocca il percorso creato dal hole punching, la sessione passa a hbbr e ogni fotogramma attraversa il tuo VPS.

Una variabile d’ambiente elimina questa scelta. ALWAYS_USE_RELAY=Y su hbbs forza il passaggio di ogni sessione attraverso hbbr. La documentazione di RustDesk la mostra in uno degli esempi Compose, quindi viene copiata spesso. In questo modo le connessioni diventano più prevedibili, ma il traffico in uscita diventa effettivo. Impostala perché hai deciso di farlo, non perché l’hai incollata.

Quali porte richiede un server RustDesk self-hosted

I numeri di porta riportati di seguito sono stati verificati nella documentazione del server RustDesk e nel repository rustdesk-server il 17 agosto 2026.

• TCP 21115, su hbbs: test del tipo di NAT.
• UDP 21116, su hbbs: registrazione dell'ID e heartbeat. Senza questa porta il client non risulta mai online, indipendentemente dalle altre porte aperte.
• TCP 21116, su hbbs: TCP hole punching e servizio di connessione.
• TCP 21117, su hbbr: relay. Questa è la porta che trasferisce i dati delle sessioni, quindi è quella che genera costi.
• TCP 21118 su hbbs e TCP 21119 su hbbr: WebSocket, utilizzato dal client browser. Lascia entrambe le porte chiuse se non utilizzi questa funzione.
• TCP 21114 è la console Web di RustDesk Server Pro. La build open source non è in ascolto su questa porta.

Installare hbbs e hbbr con il tag dell'immagine fissato

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

Entrambi i servizi devono leggere running. Verifica che le porte siano in ascolto prima di modificare il firewall.

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

Dovresti vedere listener TCP sulle porte 21115, 21116 e 21117, oltre a un listener UDP sulla porta 21116. L'assenza della riga UDP indica che hbbs non è in esecuzione, perché i client usano quel listener per registrarsi.

In quel file ci sono quattro scelte deliberate. Il tag è 1.1.16, la release corrente ad agosto 2026, pubblicata il 20 luglio 2026, invece di latest, perché latest indica qualunque versione sia stata pubblicata più di recente e un docker compose pull tra sei mesi potrebbe fornirti un server che non hai mai testato. network_mode: "host" associa direttamente le interfacce dell'host, come raccomandato dalla documentazione di RustDesk, e determina il comportamento del firewall. ./data:/root mappa la directory di lavoro dell'immagine sull'host, così la coppia di chiavi viene salvata in una posizione di cui puoi eseguire il backup. hbbr -k _ è l'unica modifica rispetto all'esempio upstream, perché la configurazione predefinita lascia il relay aperto a chiunque. Se Compose è una novità per te, eseguire Docker Compose su un VPS spiega il formato del file e i comandi per gestirne il ciclo di vita.

Se hbbr viene spostato su un secondo server, devi indicare a hbbs dove si trova: passa -r relay.example.com:21117 oppure imposta la variabile d'ambiente RELAY-SERVERS. Su un singolo server non è necessario.

La coppia di chiavi Ed25519 controlla l'accesso

Al primo avvio, hbbs genera id_ed25519 e id_ed25519.pub nella directory di lavoro. Con il mount precedente, entrambi i file sono disponibili sull'host.

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

id_ed25519.pub contiene una stringa base64. Inserisci questa stringa nel campo Key di ogni client. id_ed25519 è la parte privata e non deve mai lasciare il server. La chiave pubblica non è un dato segreto, perché viene copiata nella configurazione di ogni client. La chiave privata è invece un secret: chiunque ne disponga può avviare un server considerato attendibile dai client.

Esegui subito il backup di entrambi i file, prima di configurare venti client.

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

Copia l'archivio al di fuori del server. Ecco perché questo passaggio è più importante di qualsiasi altro. Se elimini ~/rustdesk/data o ricrei il servizio su un nuovo VPS senza copiarlo, al successivo avvio hbbs genera una nuova coppia di chiavi. Ogni client contiene ancora la vecchia chiave pubblica, quindi hbbs rifiuta la connessione e il client passa offline. Esegui sudo cat ~/rustdesk/data/id_ed25519.pub e confrontalo con il campo Key di un client qualsiasi: le due stringhe non corrispondono più, e questa mancata corrispondenza è l'unica causa del problema. Per risolverlo devi modificare manualmente le impostazioni su ogni macchina, comprese quelle che contavi di raggiungere tramite RustDesk.

La chiave non è la password della sessione. Confondere i due elementi porta spesso a ignorarne uno. La chiave determina con quali client il server può comunicare. La password permanente o il codice monouso sulla macchina controllata determina chi può aprire una sessione su quella macchina. Servono entrambi; la presenza di uno non compensa la debolezza dell'altro.

Perché un relay senza autenticazione è un problema

Per impostazione predefinita, hbbr non verifica nulla. La documentazione di configurazione di RustDesk lo indica chiaramente: una chiave vuota consente ai client senza una chiave corrispondente di usare il relay. Il valore predefinito vuoto serve a evitare che i nuovi utenti ricevano errori di mancata corrispondenza della chiave al primo avvio. Il costo è che chiunque trovi il tuo indirizzo sulla porta TCP 21117 può instradare il traffico delle proprie sessioni attraverso il tuo VPS, consumando il tuo traffico disponibile e usando il tuo indirizzo IP.

command: hbbr -k _ risolve il problema. L'argomento _ indica a hbbr di caricare una coppia di chiavi dalla propria directory di lavoro. Poiché entrambi i container montano lo stesso ./data, si tratta della coppia già generata da hbbs. Non viene copiato nulla manualmente, quindi le chiavi non possono divergere.

Il volume condiviso è il punto in cui si commette più spesso un errore. Se assegni a hbbr una directory separata, il servizio genera una coppia di chiavi diversa. hbbs e hbbr non avranno quindi chiavi corrispondenti: ogni sessione inoltrata fallirà, mentre le sessioni dirette continueranno a funzionare. Il sintomo è difficile da interpretare: RustDesk raggiunge alcuni peer ma non altri, in base al fatto che il hole punching abbia avuto successo. Un singolo ls -l ~/rustdesk/data/ che mostra una sola coppia id_ed25519 permette di escludere questo problema.

Indirizza i client al tuo server

Su ogni macchina, apri RustDesk, quindi Settings, Network e infine ID/Relay Server.

• ID Server: il tuo hostname, ad esempio rustdesk.example.com. Il client usa la porta 21116, a meno che tu non ne specifichi un'altra.
• Relay Server: lascia il campo vuoto quando hbbr è in esecuzione sullo stesso host di hbbs.
• API Server: lascia il campo vuoto. Il server open source non ne fornisce uno.
• Key: la stringa base64 ottenuta da id_ed25519.pub, incollata esattamente e senza spazi finali.

La finestra principale dovrebbe quindi indicare che il client è pronto. In caso contrario, UDP 21116 non raggiunge hbbs, perché la registrazione e l'heartbeat utilizzano UDP e nessun altro componente porta online l'ID.

Limitare le porte per evitare che il relay sia un servizio aperto

Poiché i container usano la rete dell’host, davanti a essi non è presente alcuna regola Docker NAT. Le regole di ufw si applicano quindi nel modo previsto.

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

Aggiungi 21118:21119/tcp solo se esegui il client nel browser. Mantieni aperta una seconda sessione SSH mentre abiliti ufw, in modo che un errore nella regola SSH non ti impedisca di accedere al server. Nozioni di base sul firewall ufw per un VPS descrive i criteri predefiniti e l’ordine delle regole.

Ora considera il problema più comune. Se passi alla pubblicazione delle porte con un blocco ports:, come nell’esempio dell’immagine alternativa del supervisore RustDesk, Docker scrive regole DNAT proprie. I pacchetti raggiungono quindi il container senza passare dalla catena in cui risiedono le regole ufw. Un rifiuto ufw sulla porta 21117 non ha alcun effetto e il relay rimane aperto a Internet, anche se ufw status sostiene il contrario. Le porte pubblicate da Docker bypassano ufw spiega l’ordine delle catene. La rete dell’host evita completamente il problema. Se pubblichi una porta, assoc**iala a un solo indirizzo, come in "127.0.0.1:21118:21118" dietro un reverse proxy.

La limitazione in base all’indirizzo sorgente funziona solo quando i client hanno indirizzi stabili.

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

I laptop connessi a reti di hotel non hanno indirizzi stabili. Per questo, in questo scenario, la chiave configurata su hbbr svolge un ruolo più importante del firewall.

Aggiornamento di uno stack che contiene la chiave

La chiave si trova nel bind mount, non all’interno del container. L’aggiornamento è quindi sicuro purché ./data resti invariato.

1. Esegui prima il backup della directory dei dati: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. Leggi le note di rilascio del nuovo tag nella pagina delle release di rustdesk-server.
3. Modifica compose.yml e sostituisci il tag con quello nuovo in entrambe le righe image:.
4. Esegui sudo docker compose pull, quindi sudo docker compose up -d.
5. Esegui sudo cat ~/rustdesk/data/id_ed25519.pub e verifica che la stringa corrisponda a quella già presente sui client.

Il controllo del punto 5 è quello importante, perché sul server una chiave modificata non genera alcun avviso e interrompe contemporaneamente il funzionamento di tutti i client. Per eseguire il rollback, ripristina il tag precedente ed esegui di nuovo up -d. Questa procedura funziona solo perché il tag era fissato: con latest, docker compose pull ha spostato il nome sull’immagine nuova, quindi non esiste più alcun tag che identifichi quella precedente.

Il modo più comune per perdere la chiave non è docker compose down, che lascia invariato il bind mount. Il problema si verifica durante la migrazione a un nuovo VPS, quando si copia soltanto compose.yml. Copia anche ./data.

Monitorare l'egress su un piano con un limite di trasferimento

hbbr è l'unico componente di questo stack che può consumare il limite di trasferimento. Le FAQ di RustDesk indicano, per una connessione inoltrata con schermo 1920x1080, un consumo compreso tra 30 KB/s e 3 MB/s, mentre per il normale lavoro d'ufficio indicano circa 100 KB/s. Sono valori pubblicati per una singola sessione, non misurazioni del tuo ambiente. Moltiplicati per sessanta ore al mese, cioè due ore al giorno, producono questi risultati.

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

Al ritmo del lavoro d'ufficio, una sessione consuma circa 21.6 GB al mese, un valore che nessun piano noterà. Al limite superiore dell'intervallo pubblicato, le stesse sessanta ore consumano 648 GB; con due sessioni simultanee a questa velocità, il limite di 1 TB viene superato nel corso del mese. Il limite inferiore è 6.5 GB. In questo contesto, i gigabyte sono calcolati come 1000 MB, secondo il criterio normalmente usato per i limiti di trasferimento.

docker stats non suddivide questi dati, perché un container che usa la rete dell'host condivide il namespace di rete dell'host e quindi i suoi contatori sono quelli dell'host. Sono disponibili altri due strumenti. vnstat misura l'intero server:

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

L'intero server significa davvero l'intero server: se questo VPS esegue anche qualcosa che trasferisce dati reali, ad esempio uno dei server fotografici self-hosted che ogni notte importa le librerie dai telefoni, i relativi upload vengono conteggiati nella stessa voce mensile del traffico inoltrato. Lo stesso vale per un media server in senso opposto: qualcosa come Halcyon, che trasforma una libreria Jellyfin in un videonoleggio degli anni '90 consultabile, trasmette contenuti agli utenti che guardano i video e questo egress condivide il limite utilizzato dal relay.

Un contatore nftables misura nello specifico il 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

Questa regola non contiene alcun verdict, quindi conta pacchetti e byte senza modificare ciò che è consentito. Inoltre si trova in una tabella separata, quindi non interferisce con ufw. Non è persistente: inserisci le stesse righe in /etc/nftables.conf per ripristinarla dopo un riavvio. Il contatore cresce solo mentre una sessione viene effettivamente inoltrata. Se continua a crescere quando nessuno dei tuoi computer è connesso, significa che qualcun altro ha trovato il tuo relay. È proprio il caso che hbbr -k _ serve a prevenire. Poiché non leggerai nft list ogni mattina, configura un cron job che confronti il conteggio dei byte con una soglia e invii una notifica push quando la supera. Per questo puoi usare il tuo server ntfy.

hbbr dispone anche di limiti di velocità che puoi ridurre. SINGLE_BANDWIDTH ha come valore predefinito 128 Mb/s per ogni connessione relay, mentre TOTAL_BANDWIDTH ha come valore predefinito 1024 Mb/s per tutte le connessioni. Impostando SINGLE_BANDWIDTH=8, una singola sessione viene limitata a circa 1 MB/s. Questo limita la velocità, non il totale mensile. Usalo quindi per impedire che una sessione saturi il collegamento, non come strumento per controllare il budget.

Quando non serve affatto un relay

Per una configurazione personale, la risposta corretta è che potresti non aver bisogno di nulla di tutto questo. Inserisci entrambe le macchine in una VPN mesh e connettiti direttamente all'indirizzo del tunnel. Non servono hbbs, hbbr o traffico in uscita tramite relay, né un container su un VPS da aggiornare.

Sulla macchina che vuoi controllare, abilita l'accesso IP diretto nelle impostazioni di sicurezza di RustDesk. Il campo della porta è impostato per impostazione predefinita su 21118. Verifica che la porta sia in ascolto prima di tentare la connessione:

ss -tlnp | grep 21118

Connettiti quindi all'indirizzo VPN del peer invece di usare un ID. Nelle FAQ di RustDesk è specificato che questa modalità non cifra la connessione. Usala quindi all'interno del tunnel e mai tramite Internet pubblico. È il tunnel a fornire la cifratura.

Scegli in base a chi possiede le macchine. Un'istanza self-hosted di hbbs e hbbr è adatta quando gestisci macchine che non sono tue o utenti che non installeranno mai un client VPN, perché sul loro lato della configurazione servono soltanto un ID e una password. Una VPN mesh con accesso IP diretto è adatta quando tutte le macchine appartengono a te e possono gestire una chiave. WireGuard a confronto con Tailscale illustra i due metodi più comuni per creare questa mesh, mentre eseguire un desktop remoto su un VPS Linux tratta l'altro caso, in cui la macchina sulla quale vuoi visualizzare una schermata è il server stesso.

FAQ

Ogni sessione RustDesk passa dal mio relay?

No. hbbs tenta prima di connettere direttamente i due client, usando il hole punching attraverso il NAT davanti a ciascuno di essi. Solo le sessioni per cui questo tentativo non riesce ricorrono a hbbr, e soltanto queste consumano la banda. Fa eccezione ALWAYS_USE_RELAY=Y su hbbs, che forza ogni sessione a passare da hbbr, anche quando è disponibile un percorso diretto. Se questa variabile è impostata nel file Compose, ogni byte di ogni sessione incide sui costi di trasferimento.

Dove viene archiviata la chiave del server RustDesk e cosa succede se la perdo?

Al primo avvio, hbbs genera id_ed25519 e id_ed25519.pub nella propria directory di lavoro. Nell'immagine ufficiale, questa directory è /root; quindi, con il volume mount mostrato sopra, i file sono disponibili in ./data sull'host. Esegui il backup di entrambi i file su un sistema esterno al server. Se vengono persi, al successivo avvio hbbs genera una nuova coppia e rifiuta tutti i client che conservano ancora la vecchia chiave pubblica. Non esiste un metodo di ripristino diverso dalla modifica manuale del campo Key su ogni client.

Quali porte devo aprire per un server RustDesk self-hosted?

TCP 21115, 21116 e 21117, oltre a UDP 21116. hbbs usa 21115 per il test del tipo di NAT e 21116 per la registrazione degli ID e l'heartbeat su UDP, nonché per il hole punching su TCP. hbbr usa 21117 per il relay. TCP 21118 e 21119 sono le porte WebSocket per il client browser; lasciale chiuse se non usi questa funzionalità. TCP 21114 appartiene alla console Web Pro e non è necessaria per la build open source.

Persone estranee possono usare il relay RustDesk self-hosted?

Sì, se esegui hbbr con la configurazione predefinita. La documentazione di RustDesk specifica che una chiave vuota consente ai client senza una chiave corrispondente di usare il relay. Di conseguenza, chiunque scopra il tuo hostname e la porta 21117 può inoltrare traffico attraverso il server. Esegui hbbr con -k _ in modo che carichi la stessa coppia di chiavi generata da hbbs nel volume condiviso ./data. Da quel momento, solo i client configurati con la tua chiave pubblica potranno usare il relay.