RustDesk relay server zelf hosten op een VPS

Wat een zelfgehoste RustDesk relay-server is

Een zelfgehoste RustDesk relay-server bestaat uit twee daemons op één VPS. hbbs is de ID- en rendezvous-server: deze registreert elk client-ID en brengt de verbinding tussen twee clients tot stand. hbbr is de relay-server: deze transporteert de sessiegegevens, maar alleen voor sessies waarbij een directe verbinding niet mogelijk was. De meeste handleidingen installeren beide, zorgen voor de koppeling en stoppen daar. Wat volgt is de rest van het werk: de sleutel die dient als toegangscontrole, de poorten, de upgrade en de bandbreedte.

Beide daemons worden geleverd in dezelfde image, rustdesk/rustdesk-server, en beide lezen hetzelfde Ed25519-sleutelpaar uit dezelfde map. Ed25519 is een cryptografisch systeem voor digitale handtekeningen op basis van publieke sleutels. Dat sleutelpaar bepaalt met welke clients uw server communiceert; er is geen achterliggende gebruikersdatabase.

hbbs en hbbr: welke daemon verbruikt bandbreedte

Het verkeer van hbbs is klein en constant: ID-registratie en heartbeats, plus de korte uitwisseling die twee peers met elkaar verbindt. Het draait de hele dag en kost vrijwel niets.

Het verkeer van hbbr betreft de sessie zelf. Schermbeelden gaan in één richting, toetsenbord- en muisinput in de andere, en elke doorgegeven byte komt aan op uw VPS en verlaat deze vervolgens weer. Als uw provider alleen uitgaand verkeer (egress) meet, kost een relayed sessie u ongeveer de sessiesnelheid. Als de provider het totale dataverkeer meet, kost het u ongeveer het dubbele.

De relay is een fallback, niet het normale pad. hbbs probeert eerst de twee clients rechtstreeks met elkaar te verbinden via hole punching door de NAT (network address translation) die zich voor elk van hen bevindt. Wanneer dit werkt, raakt de sessie hbbr nooit aan en blijft uw databundel onaangetast. Wanneer één kant zich achter een NAT bevindt die een nieuwe poort per bestemming toewijst, of achter een firewall die het gepunchte pad blokkeert, valt de sessie terug op hbbr en passeert elk frame uw VPS.

Eén omgevingsvariabele neemt de keuze weg. ALWAYS_USE_RELAY=Y op hbbs dwingt elke sessie door hbbr. De documentatie van RustDesk toont dit in een van de Compose-voorbeelden, waardoor het vaak wordt gekopieerd. Het maakt verbindingen voorspelbaarder en zorgt voor daadwerkelijk uitgaand verkeer. Stel dit in omdat u dat zelf heeft besloten, niet omdat u het heeft gekopieerd en geplakt.

Welke poorten heeft een zelfgehoste RustDesk-server nodig

De onderstaande poortnummers zijn op 17 augustus 2026 gecontroleerd aan de hand van de RustDesk-serverdocumentatie en de rustdesk-server-repository.

• TCP 21115, op hbbs: de NAT-type-test.
• UDP 21116, op hbbs: ID-registratie en heartbeat. Zonder deze poort komt de client nooit online, ongeacht welke andere poorten openstaan.
• TCP 21116, op hbbs: TCP hole punching en de verbindingsservice.
• TCP 21117, op hbbr: de relay. Dit is de poort die sessiedata verplaatst; dit is dus de poort die bandbreedte verbruikt.
• TCP 21118 op hbbs en TCP 21119 op hbbr: WebSocket, gebruikt door de browser-client. Laat beide gesloten als u deze niet gebruikt.
• TCP 21114 is de webconsole in RustDesk Server Pro. De open-source-versie luistert hier niet op.

Installatie van hbbs en hbbr met een vastgezette image-tag

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

Beide services moeten running inlezen. Controleer of de listeners actief zijn voordat u de firewall aanpast.

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

U hoort TCP-listeners te zien op 21115, 21116 en 21117, en een UDP-listener op 21116. Een ontbrekende UDP-regel betekent dat hbbs niet draait, aangezien clients zich bij die specifieke listener registreren.

Vier zaken in dat bestand zijn bewust gekozen. De tag is 1.1.16, de huidige release per augustus 2026, gepubliceerd op 20 juli 2026, in plaats van latest. Dit is omdat latest betekent dat de meest recent gepushte versie wordt gebruikt, en een docker compose pull over zes maanden kan resulteren in een serverversie die u nooit heeft getest. network_mode: "host" koppelt de host-interfaces direct, wat de aanbeveling is in de RustDesk-documentatie en bepaalt hoe uw firewall zich gedraagt. ./data:/root mapt de werkdirectory van de image naar de host, zodat het sleutelpaar op een locatie terechtkomt waarvan u back-ups kunt maken. En hbbr -k _ is de enige wijziging ten opzichte van het upstream-voorbeeld, omdat de standaardinstelling uw relay openstelt voor iedereen. Als Compose nieuw voor u is, behandelt Docker Compose draaien op een VPS het bestandsformaat en de lifecycle-commando's.

Als hbbr ooit naar een tweede server verhuist, moet hbbs worden geïnformeerd over de nieuwe locatie: geef -r relay.example.com:21117 mee, of stel de omgevingsvariabele RELAY-SERVERS in. Op een enkele server is dit niet nodig.

Het Ed25519-sleutelpaar vormt de toegangscontrole

Bij de eerste start genereert hbbs id_ed25519 en id_ed25519.pub in de werkmap. Dankzij de bovenstaande mount verschijnen beide bestanden op de host.

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

id_ed25519.pub bevat één base64-tekenreeks. Deze tekenreeks moet worden ingevoerd in het veld Key op elke client. id_ed25519 is het private gedeelte en mag de server nooit verlaten. De publieke sleutel is niet geheim, omdat deze toch naar elke clientconfiguratie wordt gekopieerd. De private sleutel is wel geheim: iedereen die hierover beschikt, kan een server opzetten die uw clients zullen vertrouwen.

Maak nu een back-up van beide bestanden, voordat u twintig clients heeft geconfigureerd.

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

Kopieer dat archief naar een externe locatie. Dit is om de volgende reden belangrijker dan elke andere stap. Als u ~/rustdesk/data verwijdert, of de server opnieuw opbouwt op een nieuwe VPS zonder het bestand te kopiëren, genereert hbbs bij de volgende start een nieuw sleutelpaar. Elke client bevat nog steeds de oude publieke sleutel, waardoor hbbs de verbinding weigert en de client offline gaat. Voer sudo cat ~/rustdesk/data/id_ed25519.pub uit en vergelijk de uitvoer met het veld Key op een willekeurige client: de twee tekenreeksen komen niet langer overeen, en dit verschil is de enige oorzaak van de fout. Het herstellen hiervan betekent dat u de instellingen op elke machine handmatig moet aanpassen, inclusief de machines waarvoor u afhankelijk was van RustDesk om ze te bereiken.

De sleutel is niet hetzelfde als het sessiewachtwoord; het verwarren van deze twee zorgt ervoor dat mensen een van beide overslaan. De sleutel bepaalt met welke clients uw server communiceert. Het permanente wachtwoord of de eenmalige code op de beheerde machine bepaalt wie een sessie op die machine mag openen. U heeft beide nodig, en het hebben van de een compenseert niet voor een zwakke beveiliging van de ander.

Waarom een niet-geauthenticeerde relay een probleem is

Standaard controleert hbbr niets. De configuratiedocumentatie van RustDesk stelt dit expliciet: een lege sleutel staat toe dat clients zonder overeenkomende sleutel de relay gebruiken. De lege standaardwaarde bestaat zodat nieuwe gebruikers bij de eerste uitvoering geen foutmeldingen krijgen door sleutelconflicten. Het nadeel is dat iedereen die uw adres op TCP 21117 vindt, sessieverkeer via uw VPS kan pushen, ten koste van uw datalimiet en vanaf uw IP-adres.

command: hbbr -k _ lost dit op. Het argument _ instrueert hbbr om een sleutelpaar uit de werkmap te laden, en omdat beide containers dezelfde ./data mounten, is dat het paar dat hbbs al heeft gegenereerd. Niets wordt handmatig gekopieerd, waardoor er geen inconsistenties kunnen ontstaan.

Het gedeelde volume is het onderdeel waar mensen fouten maken. Geef hbbr een eigen map en het genereert een ander sleutelpaar. hbbs en hbbr zijn het vervolgens oneens, elke gerelayeerde sessie mislukt, en directe sessies blijven werken. Het symptoom is verwarrend: RustDesk bereikt sommige peers wel en andere niet, afhankelijk van of hole punching toevallig slaagde. Eén ls -l ~/rustdesk/data/ die een enkel id_ed25519 paar toont, sluit dit uit.

Configureer de clients voor uw server

Open op elke machine RustDesk, ga naar Settings, vervolgens naar Network en daarna naar ID/Relay Server.

• ID Server: uw hostnaam, bijvoorbeeld rustdesk.example.com. De client gebruikt poort 21116, tenzij u een andere poort opgeeft.
• Relay Server: laat dit leeg wanneer hbbr op dezelfde host draait als hbbs.
• API Server: laat dit leeg. De open source-server biedt deze functionaliteit niet.
• Key: de base64-string uit id_ed25519.pub; plak deze exact, zonder spaties aan het einde.

Het hoofdvenster zou vervolgens moeten aangeven dat de client gereed is. Als dit niet het geval is, bereikt UDP 21116 de hbbs niet, aangezien registratie en heartbeat via UDP verlopen en er geen andere manier is om de ID online te krijgen.

Beperk de poorten zodat de relay geen open service is

Omdat de containers host-networking gebruiken, is er geen Docker NAT-regel voor aanwezig. Hierdoor werken ufw-regels zoals u verwacht.

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

Voeg 21118:21119/tcp alleen toe als u de browser-client gebruikt. Houd een tweede SSH-sessie open terwijl u ufw inschakelt, zodat een fout in de SSH-regel u niet buitensluit van uw eigen server. De basis van de ufw-firewall voor een VPS behandelt de standaardbeleidsregels en de volgorde van de regels.

Nu het knelpunt. Als u overschakelt naar het publiceren van poorten met een ports:-blok, zoals het alternatieve RustDesk supervisor-imagevoorbeeld doet, schrijft Docker zijn eigen DNAT-regels. Pakketten bereiken de container dan zonder de keten te passeren waarin uw ufw-regels zich bevinden. Een ufw-deny op 21117 heeft dan geen effect en de relay staat open voor het internet, terwijl ufw status het tegendeel beweert. Docker gepubliceerde poorten omzeilen ufw legt de volgorde van de keten uit. Host-networking vermijdt dit probleem volledig. Als u toch een poort publiceert, bind deze dan aan één adres, zoals in "127.0.0.1:21118:21118" achter een reverse proxy.

Beperken op bronadres werkt alleen wanneer uw clients stabiele adressen hebben.

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

Laptops op hotelnetwerken hebben geen stabiele adressen. Dit is precies de reden waarom de sleutel op hbbr hier meer daadwerkelijk werk verricht dan de firewall.

Een stack upgraden die uw key bevat

De key bevindt zich in de bind mount en niet in de container zelf. Een upgrade is daarom veilig, zolang u ./data ongewijzigd laat.

1. Maak eerst een back-up van de datamap: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. Lees de release notes voor de nieuwe tag op de rustdesk-server releases-pagina.
3. Bewerk compose.yml en wijzig beide image:-regels naar de nieuwe tag.
4. Voer sudo docker compose pull uit en daarna sudo docker compose up -d.
5. Voer sudo cat ~/rustdesk/data/id_ed25519.pub uit en controleer of de string overeenkomt met de string die uw clients al gebruiken.

Stap 5 is de belangrijkste controle, omdat een gewijzigde key op de server niet wordt opgemerkt, maar direct alle clients de verbinding laat verbreken. Een rollback voert u uit door de oude tag terug te plaatsen en opnieuw up -d uit te voeren. Dit werkt alleen omdat u de versie heeft vastgezet: bij latest heeft docker compose pull de naam naar de nieuwe image verplaatst, waardoor er geen tag meer is die naar de oude image verwijst.

De gebruikelijke manier om de key te verliezen is niet via docker compose down, aangezien dit een bind mount ongemoeid laat. Het gebeurt bij het migreren naar een nieuwe VPS waarbij alleen compose.yml wordt gekopieerd. Kopieer ook ./data mee.

Monitor uitgaand verkeer bij een abonnement met een datalimiet

hbbr is het enige onderdeel van deze stack dat een datalimiet kan verbruiken. De FAQ van RustDesk stelt dat een gerelayeerde verbinding op een 1920x1080 scherm tussen 30 KB/s en 3 MB/s verbruikt, en schat standaard kantoorwerkzaamheden op ongeveer 100 KB/s. Dit zijn gepubliceerde cijfers voor een enkele sessie, geen meting van uw specifieke opstelling. Uitgerekend over zestig uur per maand, twee uur per dag, ziet dit er als volgt uit.

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

Bij het verbruik voor kantoorwerkzaamheden kost één sessie ongeveer 21.6 GB per maand, wat binnen elk abonnement valt. Aan de bovenkant van het gepubliceerde bereik kosten dezelfde zestig uur 648 GB, en twee gelijktijdige sessies tegen dat tarief overschrijden een limiet van 1 TB binnen de maand. De ondergrens is 6.5 GB. Gigabytes worden hier gerekend als 1000 MB, wat de standaardmanier is waarop datalimieten worden geteld.

docker stats zal dit niet voor u uitsplitsen, omdat een container die host-netwerken gebruikt de netwerk-namespace van de host deelt; de tellers zijn dus die van de host. Twee andere tools werken wel. vnstat meet de gehele server:

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

De gehele server betekent ook echt de gehele server: als deze VPS ook andere taken uitvoert die data verplaatsen, zoals een van de zelfgehoste fotoservers die elke nacht fotobibliotheken van telefoons ophaalt, dan tellen die uploads mee in hetzelfde maandelijkse totaal als uw relay-verkeer. Voor een mediaserver geldt hetzelfde vanaf de andere kant, aangezien software zoals Halcyon, die een Jellyfin-bibliotheek omzet in een doorbladerbare videotheek uit de jaren 90 streams verstuurt naar iedereen die kijkt, en dat uitgaande verkeer deelt de limiet die uw relay verbruikt.

Een nftables-teller meet specifiek de 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

Die regel bevat geen verdict, dus telt deze pakketten en bytes zonder de toegestane acties te wijzigen, en de regel staat in een eigen tabel zodat deze ufw niet verstoort. Dit is niet persistent: plaats dezelfde regels in /etc/nftables.conf als u wilt dat deze na een herstart behouden blijven. De teller loopt alleen op terwijl er daadwerkelijk een sessie wordt gerelayeerd. Een teller die blijft oplopen terwijl geen van uw eigen machines verbonden is, betekent dat iemand anders uw relay heeft gevonden; dit is het scenario dat hbbr -k _ moet voorkomen. Omdat u niet elke ochtend nft list zult lezen, kunt u een cron-job instellen die het byte-aantal vergelijkt met een drempelwaarde en een push-notificatie verstuurt wanneer deze wordt overschreden; dit is een taak voor uw eigen ntfy-server.

hbbr heeft ook snelheidslimieten die u kunt verlagen. SINGLE_BANDWIDTH staat standaard op 128 Mb/s per relay-verbinding en TOTAL_BANDWIDTH op 1024 Mb/s voor alle verbindingen samen. Het instellen van SINGLE_BANDWIDTH=8 begrenst één sessie tot ongeveer 1 MB/s. Dit beperkt de snelheid, niet het maandelijkse totaal, dus beschouw dit als een manier om te voorkomen dat één sessie de verbinding verzadigt, in plaats van als een budgetbeheerder.

Wanneer u helemaal geen relay nodig heeft

Voor een persoonlijke opstelling is het eerlijke antwoord dat u dit wellicht helemaal niet nodig heeft. Plaats beide machines in een mesh-VPN en verbind direct met het tunneladres. Er is dan geen hbbs, geen hbbr, geen relay-egress en geen container op een VPS die u hoeft bij te werken.

Schakel op de machine die u wilt besturen directe IP-toegang in via de beveiligingsinstellingen van RustDesk. Het poortveld staat standaard op 21118. Controleer of de poort luistert voordat u probeert verbinding te maken:

ss -tlnp | grep 21118

Verbind vervolgens met het VPN-adres van die peer in plaats van met een ID. De FAQ van RustDesk vermeldt over deze modus dat de verbinding onversleuteld is; voer deze daarom uit binnen de tunnel en nooit via het openbare internet. De tunnel levert in dat geval de versleuteling.

Maak uw keuze op basis van wie de machines bezit. Een zelfgehoste hbbs en hbbr is de juiste keuze wanneer u machines ondersteunt die niet van u zijn, of mensen die nooit een VPN-client zullen installeren, omdat hun kant van de opstelling enkel uit een ID en een wachtwoord bestaat. Een mesh-VPN met directe IP-toegang is de juiste keuze wanneer elke machine van u is en een sleutel kan dragen. WireGuard vergeleken met Tailscale behandelt de twee gebruikelijke manieren om zo'n mesh op te bouwen, en een remote desktop draaien op een Linux VPS behandelt het andere scenario, waarbij de machine waarvan u het scherm wilt zien de server zelf is.

FAQ

Verloopt elke RustDesk-sessie via mijn relay?

Nee. hbbs probeert eerst de twee clients rechtstreeks met elkaar te verbinden via hole punching door de NAT die voor elk van hen staat. Alleen sessies waarbij dit mislukt, vallen terug op hbbr, en alleen die sessies kosten u bandbreedte. De uitzondering is ALWAYS_USE_RELAY=Y op hbbs, die elke sessie via hbbr dwingt, ongeacht of er een rechtstreeks pad beschikbaar was. Als die variabele in uw Compose-bestand is ingesteld, telt elke byte van elke sessie mee voor uw datagebruik.

Waar wordt de RustDesk-serversleutel opgeslagen en wat als ik deze verlies?

hbbs genereert bij de eerste start id_ed25519 en id_ed25519.pub in de werkmap. Die map is /root binnen de officiële image, dus met de volume-mount zoals hierboven getoond, verschijnen de bestanden in ./data op de host. Maak van beide bestanden een back-up buiten de server. Als ze verloren gaan, genereert hbbs bij de volgende start een nieuw paar en wordt elke client die nog de oude publieke sleutel heeft, geweigerd. Er is geen herstelmethode anders dan het handmatig bewerken van het Key-veld op elke client.

Welke poorten moet ik openen voor een zelfgehoste RustDesk-server?

TCP 21115, 21116 en 21117, plus UDP 21116. hbbs gebruikt 21115 voor de NAT-typetest en 21116 voor ID-registratie en heartbeat via UDP, en voor hole punching via TCP. hbbr gebruikt 21117 voor de relay. TCP 21118 en 21119 zijn de WebSocket-poorten voor de browser-client; laat deze gesloten als u die niet gebruikt. TCP 21114 hoort bij de Pro-webconsole en de open-source-versie heeft deze niet nodig.

Kunnen vreemden mijn zelfgehoste RustDesk-relay gebruiken?

Ja, als u hbbr uitvoert met de standaardconfiguratie. De documentatie van RustDesk stelt dat een lege sleutel toestaat dat clients zonder overeenkomende sleutel de relay gebruiken, dus iedereen die uw hostnaam en poort 21117 achterhaalt, kan verkeer via uw server sturen. Voer hbbr uit met -k _ zodat deze hetzelfde sleutelpaar laadt dat hbbs in het gedeelde ./data-volume heeft gegenereerd. Daarna kunnen alleen clients die zijn geconfigureerd met uw publieke sleutel via u relayen.