RustDesk self-hosted permette di gestire il desktop remoto usando un server sotto il tuo controllo. È una soluzione interessante per accedere ai computer di casa, amministrare un homelab o fornire assistenza senza affidare l’infrastruttura di collegamento ai server pubblici del servizio.
In questa guida installeremo RustDesk Server OSS con Docker Compose su Linux, configureremo i client e vedremo come proteggere le connessioni, salvare le chiavi e risolvere i problemi più comuni.
La configurazione utilizza due componenti: hbbs, che aiuta i dispositivi a trovarsi, e hbbr, che inoltra il traffico quando una connessione diretta non è possibile. Non serve installare un ambiente desktop sul server: il desktop da controllare è quello dei dispositivi sui quali viene eseguito il client RustDesk.
Cos’è RustDesk e come funziona il self-hosting
RustDesk è un software di desktop remoto open source che consente di collegarsi a un altro computer, visualizzarne lo schermo e controllarlo nei limiti dei permessi concessi.
Con il self-hosting sostituisci l’infrastruttura pubblica di identificazione e relay con un server gestito da te. I dispositivi devono essere configurati per utilizzare il tuo server: installare il backend, da solo, non modifica le impostazioni dei client.
A cosa servono hbbs e hbbr
hbbs: è il server ID, chiamato anche rendezvous o signaling server. Gestisce la registrazione dei client e li aiuta a stabilire una connessione diretta.hbbr: è il server relay. Inoltra il traffico quando i dispositivi non riescono a comunicare direttamente.
Quando avvii una sessione, RustDesk tenta prima una connessione diretta tra i dispositivi. Se il tentativo fallisce, ad esempio a causa delle caratteristiche della rete o del NAT, può utilizzare il relay.
Il traffico della sessione non passa quindi sempre attraverso il server: con una connessione diretta, il server svolge soprattutto il ruolo di coordinamento. Quando viene usato il relay, invece, banda disponibile e posizione del server incidono maggiormente sulle prestazioni.
RustDesk self-hosted è davvero privato?
Il self-hosting offre maggiore controllo sull’infrastruttura di collegamento, ma non rende automaticamente sicura ogni installazione e non equivale ad anonimato.
Il server gestisce informazioni di connessione necessarie al funzionamento del servizio. Devi quindi proteggere sia il backend sia i dispositivi controllati, configurare correttamente la chiave pubblica e mantenere aggiornati server e client.
- Configura entrambi i dispositivi per usare il tuo server.
- Inserisci nei client la chiave pubblica generata dal server.
- Proteggi l’accesso al computer remoto con password robuste e permessi appropriati.
- Non distribuire la chiave privata del server.
- Apri soltanto le porte necessarie.
- Utilizza il desktop remoto esclusivamente su dispositivi tuoi o con il consenso del proprietario.
RustDesk Server OSS e Pro: quale scegliere?
RustDesk offre un backend open source e una versione commerciale self-hosted. Questa guida riguarda RustDesk Server OSS.
| Versione | Cosa offre | A chi è adatta |
|---|---|---|
| RustDesk Server OSS | Server ID e relay, configurazione manuale dei client | Uso personale, homelab e installazioni che non richiedono una console di gestione centralizzata |
| RustDesk Server Pro | Console web e funzionalità di amministrazione, identità e controllo degli accessi secondo il piano scelto | Organizzazioni con esigenze di gestione centralizzata |
Non confondere il server OSS con la console Pro: il backend gratuito descritto qui non fornisce una dashboard amministrativa sulla porta 21114.
Requisiti
Per seguire il tutorial servono:
- Un server Linux con Docker Engine e Docker Compose Plugin;
- Un utente con permessi amministrativi;
- Un indirizzo IP del server raggiungibile dai dispositivi da collegare;
- Facoltativamente, un dominio o sottodominio dedicato;
- Accesso alla configurazione del firewall e, se necessario, del router;
- Il client RustDesk sui dispositivi coinvolti nella sessione.
Il server può essere un dispositivo dell’homelab oppure un VPS. Per le sessioni che usano il relay, considera soprattutto la velocità di upload, il traffico incluso e la latenza della connessione.
La configurazione seguente utilizza network_mode: host su Linux, come nell’esempio ufficiale. I container condividono la rete del server e non utilizzano la sezione ports:.
Scegliere come raggiungere il server
Prima dell’installazione, decidi da quali reti vuoi usare RustDesk.
| Scenario | Indirizzo da usare nei client | Cosa configurare |
|---|---|---|
| Solo rete locale | IP LAN o nome DNS interno | Accesso alle porte RustDesk dalla LAN |
| Rete privata tramite VPN | IP o nome raggiungibile dalla VPN | Routing e firewall della VPN |
| Accesso attraverso Internet | Dominio o IP pubblico del server | DNS, firewall ed eventuale port forwarding |
Negli esempi useremo rustdesk.example.com. Sostituiscilo con il dominio del tuo server oppure con un indirizzo IP raggiungibile da tutti i client.
Se utilizzi un dominio pubblico, configura il relativo record DNS verso l’indirizzo del server. Un normale proxy HTTP non sostituisce l’inoltro delle porte TCP e UDP richieste da questa configurazione.
Porte necessarie per RustDesk
Per il collegamento con i client desktop utilizzeremo queste porte:
| Porta | Protocollo | Funzione |
|---|---|---|
| 21115 | TCP | Test del tipo di NAT |
| 21116 | TCP | Registrazione, servizio di connessione e attraversamento del NAT |
| 21116 | UDP | Registrazione e heartbeat dei dispositivi |
| 21117 | TCP | Traffico relay |
Non è necessario aprire la porta 21114, riservata all’API e alla console Pro. Le porte 21118 e 21119 sono destinate al supporto WebSocket e non vengono utilizzate in questa guida: mantienile chiuse nel firewall.
Firewall del server
Se utilizzi UFW e vuoi rendere il servizio raggiungibile attraverso Internet, puoi autorizzare le porte necessarie con:
sudo ufw allow 21115:21117/tcp
sudo ufw allow 21116/udpQueste regole consentono l’accesso da qualsiasi indirizzo. Se il server deve essere usato soltanto dalla LAN o dalla VPN, non applicare le regole generali: limita invece l’origine alla subnet effettivamente utilizzata.
Ad esempio, per una LAN 192.168.1.0/24:
sudo ufw allow from 192.168.1.0/24 to any port 21115:21117 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 21116 proto udpSostituisci la subnet con quella della tua rete. Verifica anche le regole già presenti: una precedente autorizzazione generale non viene annullata aggiungendo una regola più restrittiva.
Se lavori tramite SSH, non attivare o riconfigurare il firewall senza aver prima autorizzato il tuo accesso amministrativo. Controlla anche l’eventuale firewall del provider della VPS.
Port forwarding sul router
Se il server si trova in casa e vuoi raggiungerlo da Internet senza VPN, inoltra le porte TCP 21115, 21116 e 21117 e la porta UDP 21116 verso il suo indirizzo LAN.
Assegna al server un indirizzo LAN stabile. Se la connessione è dietro CGNAT, il normale port forwarding non è sufficiente: valuta un VPS raggiungibile pubblicamente oppure una rete privata VPN adatta alla tua configurazione.
Creare la cartella di RustDesk
Creiamo una cartella dedicata in /opt:
sudo mkdir -p /opt/rustdesk/data
sudo chown -R "$USER:$(id -gn)" /opt/rustdesk
cd /opt/rustdeskLa cartella data conserverà i dati persistenti del server, comprese le chiavi generate al primo avvio.
Installare RustDesk Server con Docker Compose
Crea il file Compose:
nano compose.yamlInserisci questa configurazione, sostituendo rustdesk.example.com con il tuo dominio o IP:
name: rustdesk
services:
hbbs:
image: rustdesk/rustdesk-server:latest
command: ["hbbs", "-r", "rustdesk.example.com:21117"]
network_mode: host
volumes:
- ./data:/root
depends_on:
- hbbr
restart: unless-stopped
hbbr:
image: rustdesk/rustdesk-server:latest
command: ["hbbr"]
network_mode: host
volumes:
- ./data:/root
restart: unless-stoppedIl parametro -r indica a hbbs l’indirizzo del relay da comunicare ai client. Deve essere un indirizzo raggiungibile dai dispositivi, non il nome del servizio Docker.
Non aggiungere una sezione ports:: con la rete host i processi utilizzano direttamente le porte del server Linux. Assicurati che non siano già occupate da un’altra installazione RustDesk.
Salva con Ctrl+O, premi Invio e chiudi Nano con Ctrl+X.
Verificare e avviare i servizi
docker compose config
docker compose pull
docker compose up -dControlla lo stato:
docker compose psPer visualizzare i log:
docker compose logs -f --tail=100Premi Ctrl+C per interrompere la visualizzazione: i container continueranno a funzionare.
Con network_mode: host, la colonna delle porte di Docker può non mostrare le consuete mappature. Per verificare le porte TCP e UDP in ascolto:
sudo ss -lntup | grep -E ':2111[5-9]\b'La presenza di una porta in ascolto non significa che debba essere aperta nel firewall. In questa guida autorizziamo soltanto TCP 21115–21117 e UDP 21116.
Recuperare la chiave pubblica del server
Al primo avvio, hbbs genera una coppia di chiavi nella directory dei dati. Per leggere la chiave pubblica:
cd /opt/rustdesk
sudo cat data/id_ed25519.pubCopia l’intero contenuto del file: servirà per configurare i client.
id_ed25519.pubè la chiave pubblica da distribuire ai client.id_ed25519è la chiave privata e deve restare protetta sul server e nei backup.
La chiave pubblica non è la password di accesso al computer remoto e non è una licenza Pro. Non sostituisce l’autorizzazione necessaria per controllare il dispositivo.
Non cancellare la cartella data durante gli aggiornamenti: rigenerare le chiavi cambia l’identità crittografica del server e può richiedere di riconfigurare i client.
Configurare i client RustDesk
Scarica RustDesk dal sito ufficiale e installalo sia sul computer dal quale ti collegherai sia sul dispositivo da controllare.
Su entrambi i dispositivi:
- Apri RustDesk;
- Accedi alle impostazioni di rete, eventualmente dal menu accanto al tuo ID;
- Sblocca le impostazioni se vengono richiesti privilegi amministrativi;
- Inserisci l’indirizzo del tuo server ID;
- Inserisci il server relay;
- Incolla la chiave pubblica nel campo dedicato;
- Applica la configurazione.
I nomi e la posizione dei menu possono cambiare tra versioni e sistemi operativi. I valori del nostro esempio sono:
| Campo | Valore |
|---|---|
| ID Server | rustdesk.example.com:21116 |
| Relay Server | rustdesk.example.com:21117 |
| Key | Contenuto di data/id_ed25519.pub |
| API Server | Lascia vuoto: questa guida utilizza il server OSS |
Il campo relay può essere lasciato vuoto quando viene dedotto o comunicato correttamente dal server. Lo impostiamo esplicitamente per rendere la configurazione più facile da verificare.
Se RustDesk è già attivo, applica le modifiche e, se necessario, riavvia il client. Controlla che segnali di essere pronto per le connessioni.
Eseguire la prima connessione remota
- Apri RustDesk sul dispositivo da controllare;
- Annota il suo ID;
- Dal computer di controllo, inserisci quell’ID nel campo per la connessione;
- Avvia la sessione;
- Autorizza la richiesta sul dispositivo remoto oppure utilizza la modalità di autenticazione configurata.
Per verificare l’accesso da fuori casa, prova anche con un dispositivo collegato a una rete differente, ad esempio tramite hotspot del telefono. Un test eseguito soltanto nella LAN non dimostra che il servizio sia raggiungibile da Internet.
Entrambi i client devono utilizzare il tuo server ID e la sua chiave pubblica. Un client configurato con i valori predefiniti potrebbe non trovare un dispositivo registrato soltanto sulla tua infrastruttura.
Accesso non presidiato
Se vuoi collegarti quando nessuno è davanti al computer remoto, configura l’accesso non presidiato nelle impostazioni di sicurezza del client.
Usa una password lunga e univoca, limita i permessi alle funzioni necessarie e verifica il funzionamento dopo un riavvio. L’avvio automatico e l’accesso alla schermata di login dipendono dal sistema operativo, dall’installazione del servizio e dai permessi concessi.
Non pubblicare ID e password insieme e non riutilizzare le credenziali di altri servizi.
Serve Nginx o un certificato HTTPS?
Per la configurazione con client desktop descritta in questa guida non serve un reverse proxy HTTP. I client comunicano con le porte RustDesk e devono conoscere la chiave pubblica del server.
Un normale blocco Nginx con proxy_pass http://... non sostituisce questa configurazione, perché non inoltra automaticamente i protocolli TCP e UDP utilizzati.
Il supporto WebSocket e le configurazioni WSS richiedono un’impostazione diversa. Se non le utilizzi, mantieni chiuse le porte 21118 e 21119 e non aprire la porta 21114 del server Pro.
Backup di RustDesk Server
Il backup deve includere almeno il file Compose e la directory data, che contiene anche la chiave privata.
Per creare una copia coerente con i servizi temporaneamente arrestati:
cd /opt/rustdesk
docker compose stop
sudo tar -czf "/opt/rustdesk-backup-$(date +%F-%H%M%S).tar.gz" compose.yaml data
docker compose startL’arresto interrompe le sessioni che dipendono dal relay e rende temporaneamente indisponibile il servizio di registrazione. Esegui il backup in una finestra di manutenzione.
Trasferisci l’archivio in una destinazione separata dal server e proteggilo con cifratura e permessi adeguati. Una copia presente soltanto sullo stesso disco non protegge dal guasto del server.
Ripristinare il server
Su un server predisposto con Docker, ripristina compose.yaml e data nella cartella di lavoro, mantenendo protette le chiavi, quindi avvia:
cd /opt/rustdesk
docker compose up -dSe cambi indirizzo del server, aggiorna il DNS o la configurazione dei client. Conservare le chiavi non rende automaticamente raggiungibile un server con un nuovo indirizzo.
Aggiornare RustDesk
Prima dell’aggiornamento, consulta le note di rilascio e crea un backup. Poi scarica le immagini e ricrea i container:
cd /opt/rustdesk
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100Il tag latest semplifica l’esempio, ma cambia nel tempo. Per installazioni nelle quali è importante controllare ogni aggiornamento, usa un tag di versione verificato o un digest e aggiorna intenzionalmente entrambi i servizi.
Aggiorna anche i client e verifica una connessione dopo ogni intervento.
Comandi utili
Visualizzare tutti i log
cd /opt/rustdesk
docker compose logs -f --tail=100Controllare soltanto il server ID
docker compose logs -f hbbsControllare soltanto il relay
docker compose logs -f hbbrRiavviare i servizi
docker compose restartArrestare lo stack
docker compose downIl comando rimuove i container e non cancella la cartella locale data usata in questa guida.
Avviare nuovamente lo stack
docker compose up -dProblemi comuni e soluzioni
Il client non si collega al server ID
Verifica l’indirizzo configurato nei client, la risoluzione DNS e l’apertura di TCP 21116 e UDP 21116. Controlla inoltre il firewall del server, quello del provider e l’eventuale port forwarding.
cd /opt/rustdesk
docker compose ps
docker compose logs --tail=100 hbbsNon verificare le porte RustDesk aprendo il loro indirizzo nel browser: non sono normali pagine web.
Compare un errore relativo alla chiave
Confronta il valore del campo Key con il contenuto attuale di data/id_ed25519.pub. Controlla di non aver copiato la chiave privata e di non aver rigenerato accidentalmente la directory dei dati.
Correggi la chiave sui client coinvolti e riprova. Non aggirare il problema eliminando la verifica della chiave.
I dispositivi risultano disponibili, ma la sessione fallisce
La registrazione al server ID può funzionare anche quando il relay non è raggiungibile. Verifica TCP 21117 e l’indirizzo indicato nel parametro -r e nel campo relay dei client.
docker compose logs --tail=100 hbbrFunziona fuori casa, ma non nella stessa LAN del server
Se utilizzi il dominio pubblico anche dalla LAN, il router potrebbe non supportare il NAT loopback. Valuta una configurazione DNS interna che risolva lo stesso nome verso l’IP LAN del server.
Evita di cambiare casualmente porte e chiavi: prima verifica quale indirizzo ottengono i client dal DNS.
Il collegamento è lento
Controlla se la sessione è diretta o utilizza il relay, secondo le informazioni disponibili nel client. Se passa dal relay, verifica latenza, upload del server, limiti della VPS e traffico contemporaneo.
Ridurre qualità dell’immagine e risoluzione può aiutare sulle connessioni meno veloci.
Vedo lo schermo, ma non riesco a controllare il computer
Controlla i permessi concessi alla sessione e quelli richiesti dal sistema operativo per controllo remoto e registrazione dello schermo. Il server ID e il relay non assegnano automaticamente questi permessi al client.
Conclusioni
RustDesk self-hosted è una soluzione pratica per costruire un’infrastruttura di desktop remoto sotto il proprio controllo. Con Docker Compose puoi separare il servizio ID dal relay, conservare i dati in una cartella persistente e gestire aggiornamenti e backup in modo ripetibile.
La parte più importante non è soltanto avviare i container: configura entrambi i client, distribuisci correttamente la chiave pubblica, proteggi l’accesso ai dispositivi e apri esclusivamente le porte necessarie.
Per un homelab che non deve essere raggiungibile pubblicamente, valuta l’uso attraverso una VPN. Se invece esponi il backend su Internet, controlla con particolare attenzione firewall, aggiornamenti e credenziali dei computer remoti.
Per approfondimenti, consulta la documentazione ufficiale sul self-hosting, la guida Docker del server OSS e la configurazione dei client.
Domande frequenti
RustDesk self-hosted è gratuito?
RustDesk Server OSS consente di eseguire un backend ID e relay open source senza acquistare RustDesk Server Pro. Restano i costi del server, della connessione e dell’eventuale VPS.
Devo installare RustDesk anche sui computer?
Sì. Il backend non sostituisce i client: RustDesk deve essere eseguito sui dispositivi coinvolti e configurato per utilizzare il tuo server.
Il server deve avere un ambiente grafico?
No. I componenti hbbs e hbbr non richiedono un desktop. L’interfaccia da controllare appartiene al computer remoto.
Devo aprire la porta 3389 di Windows?
No. Questa guida utilizza RustDesk, non una connessione RDP diretta. Non devi aprire la porta RDP per far funzionare il backend descritto.
Tutte le sessioni passano dal relay?
No. RustDesk tenta una connessione diretta. Il relay viene utilizzato quando la comunicazione diretta non riesce.
La chiave pubblica permette di controllare i computer?
No. Serve alla configurazione della connessione con il server. L’accesso al computer remoto dipende dall’approvazione della sessione o dai meccanismi di autenticazione configurati sul dispositivo.
Posso usare RustDesk soltanto in rete locale?
Sì. Utilizza un indirizzo del server raggiungibile dalla LAN e limita il firewall alle reti necessarie. Non serve aprire le porte sul router se non vuoi accesso da Internet.
È obbligatorio un dominio?
No. Puoi utilizzare un indirizzo IP raggiungibile dai client. Un dominio semplifica la gestione quando cambia l’IP e quando vuoi adottare una risoluzione DNS diversa tra LAN e rete pubblica.
Perché non vedo una console web?
Questa guida installa RustDesk Server OSS. La console amministrativa e l’API sulla porta 21114 appartengono a RustDesk Server Pro.