RustDesk Relayserver selbst hosten: Ports und Schlüssel

Was ein selbst betriebener RustDesk-Relayserver ist

Ein selbst betriebener RustDesk-Relayserver besteht aus zwei Daemons auf einem VPS. hbbs ist der ID- und Rendezvous-Server: Er registriert jede Client-ID und stellt zwei Clients einander vor. hbbr ist der Relayserver: Er überträgt die Sitzungsdaten, aber nur für Sitzungen, bei denen keine direkte Verbindung hergestellt werden konnte. Die meisten Anleitungen installieren beide Komponenten, stellen die Verbindung her und enden dort. Im Folgenden geht es um die übrigen Aufgaben: den Schlüssel als Zugriffskontrolle, die Ports, das Upgrade und die Bandbreite.

Beide Daemons werden im selben Image ausgeliefert, rustdesk/rustdesk-server, und lesen dasselbe Ed25519-Schlüsselpaar aus demselben Verzeichnis. Ed25519 ist ein Verfahren für Signaturen mit öffentlichen Schlüsseln. Das Schlüsselpaar legt fest, mit welchen Clients Ihr Server kommuniziert. Dahinter steht keine Benutzerdatenbank.

hbbs und hbbr: Welcher Daemon verursacht Bandbreite

Der Datenverkehr von hbbs ist gering und konstant: ID-Registrierung und Heartbeats sowie der kurze Austausch, der zwei Peers miteinander bekannt macht. Er läuft den ganzen Tag und verursacht nahezu keinen Datenverbrauch.

Der Datenverkehr von hbbr ist die eigentliche Sitzung. Bildschirmdaten werden in eine Richtung übertragen, Tastatur- und Mausdaten in die andere. Jedes weitergeleitete Byte erreicht zuerst Ihre VPS und verlässt sie anschließend wieder. Wenn Ihr Provider nur den ausgehenden Datenverkehr abrechnet, kostet eine weitergeleitete Sitzung Sie ungefähr die Sitzungsrate. Wenn er die gesamte Übertragungsmenge abrechnet, kostet sie ungefähr das Doppelte.

Das Relay ist ein Fallback und nicht der normale Pfad. hbbs versucht zunächst, die beiden Clients direkt zu verbinden. Dazu verwendet es Hole Punching durch das NAT (Network Address Translation), das jeweils vor den Clients liegt. Wenn das funktioniert, berührt die Sitzung hbbr nicht und Ihr Übertragungskontingent wird nicht belastet. Wenn eine Seite hinter einem NAT liegt, das für jedes Ziel einen neuen Port zuweist, oder hinter einer Firewall, die den per Hole Punching hergestellten Pfad verwirft, fällt die Sitzung auf hbbr zurück. Dann durchquert jedes Bild Ihren VPS.

Eine Umgebungsvariable erzwingt diese Entscheidung. ALWAYS_USE_RELAY=Y auf hbbs leitet jede Sitzung über hbbr. Die RustDesk-Dokumentation zeigt diese Variable in einem ihrer Compose-Beispiele. Deshalb wird sie häufig übernommen. Sie macht Verbindungen vorhersehbarer und verursacht tatsächlich ausgehenden Datenverkehr. Setzen Sie sie nur, wenn Sie sich bewusst dafür entschieden haben, nicht weil Sie sie lediglich kopiert haben.

Welche Ports benötigt ein selbst gehosteter RustDesk-Server?

Die folgenden Portnummern wurden am 17. August 2026 mit der RustDesk-Serverdokumentation und dem Repository rustdesk-server abgeglichen.

• TCP 21115 auf hbbs: Test des NAT-Typs.
• UDP 21116 auf hbbs: ID-Registrierung und Heartbeat. Ohne diesen Port kommt der Client nie online, unabhängig davon, welche anderen Ports geöffnet sind.
• TCP 21116 auf hbbs: TCP-Hole-Punching und Verbindungsdienst.
• TCP 21117 auf hbbr: Relay. Über diesen Port werden Sitzungsdaten übertragen. Dieser Port verursacht daher den Netzwerkverkehr, der Kosten erzeugt.
• TCP 21118 auf hbbs und TCP 21119 auf hbbr: WebSocket für den Browser-Client. Lassen Sie beide Ports geschlossen, wenn Sie diese Funktion nicht verwenden.
• TCP 21114 ist die Webkonsole in RustDesk Server Pro. Der Open-Source-Build lauscht nicht auf diesem Port.

hbbs und hbbr mit festgelegtem Image-Tag installieren

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 Dienste sollten running lesen. Prüfen Sie, ob die Listener vorhanden sind, bevor Sie die Firewall konfigurieren.

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

Sie sollten TCP-Listener auf 21115, 21116 und 21117 sowie einen UDP-Listener auf 21116 sehen. Eine fehlende UDP-Zeile bedeutet, dass hbbs nicht läuft, weil sich die Clients an diesem Listener registrieren.

Vier Angaben in dieser Datei sind bewusst gewählt. Das Tag ist 1.1.16, das im August 2026 aktuelle Release, veröffentlicht am 20 July 2026, und nicht latest. latest bedeutet, dass jeweils das zuletzt veröffentlichte Image verwendet wird. Ein docker compose pull in sechs Monaten kann Ihnen dadurch einen Server bereitstellen, den Sie nie getestet haben. network_mode: "host" bindet die Host-Schnittstellen direkt. Das empfiehlt die RustDesk-Dokumentation und bestimmt, wie sich Ihre Firewall verhält. ./data:/root bindet das Arbeitsverzeichnis des Images in den Host ein, sodass das Schlüsselpaar an einem Ort gespeichert wird, den Sie sichern können. hbbr -k _ ist die einzige Änderung gegenüber dem Upstream-Beispiel, weil die Standardkonfiguration Ihr Relay für beliebige Zugriffe öffnet. Wenn Compose für Sie neu ist, beschreibt Docker Compose auf einem VPS ausführen das Dateiformat und die Befehle für den Lebenszyklus.

Wenn hbbr auf einen zweiten Server verschoben wird, muss hbbs über den neuen Speicherort informiert werden: Übergeben Sie -r relay.example.com:21117 oder setzen Sie die Umgebungsvariable RELAY-SERVERS. Auf einem einzelnen Server ist das nicht erforderlich.

Das Ed25519-Schlüsselpaar steuert die Zugriffskontrolle

Beim ersten Start erzeugt hbbs id_ed25519 und id_ed25519.pub in seinem Arbeitsverzeichnis. Mit dem obigen Mount werden beide Dateien auf dem Host sichtbar.

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

id_ed25519.pub enthält eine Base64-Zeichenfolge. Diese Zeichenfolge tragen Sie auf jedem Client in das Feld Key ein. id_ed25519 ist der private Teil und verlässt den Server nie. Der öffentliche Schlüssel ist kein Geheimnis, weil er ohnehin in die Konfiguration jedes Clients kopiert wird. Der private Schlüssel ist geheim: Jeder, der ihn besitzt, kann einen Server bereitstellen, dem Ihre Clients vertrauen würden.

Sichern Sie jetzt beide Dateien, bevor Sie zwanzig Clients konfiguriert haben.

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

Kopieren Sie dieses Archiv vom Server weg. Der Grund dafür ist wichtiger als jeder andere Schritt. Wenn Sie ~/rustdesk/data löschen oder einen neuen VPS einrichten, ohne die Datei zu kopieren, erzeugt hbbs beim nächsten Start ein neues Schlüsselpaar. Jeder Client enthält weiterhin den alten öffentlichen Schlüssel. Daher weist hbbs ihn zurück, und der Client geht offline. Führen Sie sudo cat ~/rustdesk/data/id_ed25519.pub aus und vergleichen Sie den Wert mit dem Feld Key auf einem beliebigen Client: Die beiden Zeichenfolgen stimmen nicht mehr überein, und diese Abweichung ist die vollständige Ursache des Fehlers. Sie beheben das Problem, indem Sie die Einstellungen auf jedem Rechner manuell ändern. Das gilt auch für die Rechner, die Sie eigentlich mit RustDesk erreichen wollten.

Der Schlüssel ist nicht das Sitzungspasswort. Wenn Sie beides verwechseln, lassen Sie leicht einen der beiden Werte weg. Der Schlüssel legt fest, mit welchen Clients Ihr Server kommuniziert. Das permanente Passwort oder der Einmalcode auf dem gesteuerten Rechner legt fest, wer auf diesem Rechner eine Sitzung öffnen darf. Sie benötigen beides. Ein vorhandener Wert gleicht einen schwachen anderen nicht aus.

Warum ein nicht authentifizierter Relay problematisch ist

Standardmäßig prüft hbbr nichts. In der RustDesk-Konfigurationsdokumentation steht das ausdrücklich: Ein leerer Schlüssel erlaubt Clients ohne passenden Schlüssel, das Relay zu verwenden. Der leere Standardwert sorgt dafür, dass neue Benutzer beim ersten Start nicht an einem Schlüsselkonflikt scheitern. Der Nachteil ist, dass jeder, der Ihre Adresse auf TCP 21117 findet, seinen Sitzungsverkehr über Ihren VPS und damit über Ihr Übertragungsvolumen und Ihre IP-Adresse leiten kann.

command: hbbr -k _ behebt das. Das Argument _ weist hbbr an, ein Schlüsselpaar aus seinem Arbeitsverzeichnis zu laden. Da beide Container dasselbe ./data einbinden, ist dies das Schlüsselpaar, das hbbs bereits erzeugt hat. Es wird nichts manuell kopiert. Dadurch können die Dateien nicht voneinander abweichen.

Das gemeinsame Volume ist der Punkt, an dem häufig Fehler gemacht werden. Wenn Sie hbbr ein eigenes Verzeichnis geben, erzeugt der Dienst ein anderes Schlüsselpaar. hbbs und hbbr verwenden dann unterschiedliche Schlüssel, sodass jede weitergeleitete Sitzung fehlschlägt, während direkte Sitzungen weiterhin funktionieren. Das Symptom ist verwirrend: RustDesk erreicht einige Peers, andere jedoch nicht, abhängig davon, ob Hole Punching zufällig erfolgreich war. Ein einzelnes ls -l ~/rustdesk/data/ mit nur einem id_ed25519-Paar schließt diese Ursache aus.

Verweisen Sie die Clients auf Ihren Server

Öffnen Sie auf jedem Rechner RustDesk und anschließend Settings, Network und ID/Relay Server.

• ID Server: Ihr Hostname, zum Beispiel rustdesk.example.com. Der Client verwendet Port 21116, sofern Sie keinen anderen Port angeben.
• Relay Server: Lassen Sie das Feld leer, wenn hbbr auf demselben Host wie hbbs ausgeführt wird.
• API Server: Lassen Sie das Feld leer. Der Open-Source-Server stellt keinen solchen Server bereit.
• Key: Die Base64-Zeichenfolge aus id_ed25519.pub. Fügen Sie sie exakt und ohne abschließendes Leerzeichen ein.

Im Hauptfenster sollte anschließend angezeigt werden, dass der Client bereit ist. Falls dies nicht der Fall ist, erreicht UDP 21116 hbbs nicht. Registrierung und Heartbeat laufen über UDP. Ohne diese Verbindung wird die ID nicht online geschaltet.

Ports so beschränken, dass das Relay kein offener Dienst ist

Da die Container das Host-Netzwerk verwenden, gibt es keine Docker-NAT-Regel vor ihnen. Daher gelten die ufw-Regeln wie erwartet.

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

Fügen Sie 21118:21119/tcp nur hinzu, wenn Sie den Browser-Client ausführen. Lassen Sie eine zweite SSH-Sitzung geöffnet, während Sie ufw aktivieren. So sperrt Sie ein Fehler in der SSH-Regel nicht aus Ihrem eigenen Server aus. Die Grundlagen der ufw-Firewall für einen VPS behandelt die Standardrichtlinien und die Reihenfolge der Regeln.

Jetzt kommt die Falle. Wenn Sie stattdessen Ports mit einem ports:-Block veröffentlichen, wie im Beispiel für das alternative RustDesk-Supervisor-Image, schreibt Docker eigene DNAT-Regeln. Die Pakete erreichen den Container dann, ohne die Kette zu durchlaufen, in der Ihre ufw-Regeln gelten. Eine ufw-Deny-Regel für 21117 hat dann keine Wirkung. Das Relay ist für das Internet geöffnet, obwohl ufw status etwas anderes behauptet. Veröffentlichte Docker-Ports umgehen ufw erklärt die Reihenfolge der Ketten. Das Host-Netzwerk vermeidet dieses Problem vollständig. Wenn Sie einen Port veröffentlichen, binden Sie ihn an eine Adresse, wie bei "127.0.0.1:21118:21118" hinter einem Reverse Proxy.

Eine Einschränkung nach Quelladresse funktioniert nur, wenn Ihre Clients stabile Adressen haben.

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 in Hotelnetzwerken haben keine stabilen Adressen. Genau deshalb leistet der Schlüssel auf hbbr hier mehr als die Firewall.

Aktualisieren eines Stacks, der Ihren Schlüssel enthält

Der Schlüssel liegt im Bind-Mount und nicht im Container. Das Upgrade ist daher sicher, solange Sie ./data unverändert lassen.

1. Sichern Sie zuerst das Datenverzeichnis: sudo tar czf ~/rustdesk-data-backup.tgz -C ~/rustdesk data.
2. Lesen Sie die Release Notes für den neuen Tag auf der Releases-Seite von rustdesk-server.
3. Bearbeiten Sie compose.yml und ändern Sie beide image:-Zeilen auf den neuen Tag.
4. Führen Sie sudo docker compose pull und anschließend sudo docker compose up -d aus.
5. Führen Sie sudo cat ~/rustdesk/data/id_ed25519.pub aus und bestätigen Sie, dass die Zeichenfolge mit der übereinstimmt, die Ihre Clients bereits verwenden.

Schritt 5 ist die entscheidende Prüfung. Ein geänderter Schlüssel bleibt auf dem Server unbemerkt und führt gleichzeitig bei allen Clients zu Fehlern. Für ein Rollback tragen Sie den alten Tag wieder ein und führen erneut up -d aus. Das funktioniert nur, weil Sie den Tag festgelegt haben: Mit latest hat docker compose pull den Namen auf das neue Image verschoben. Daher gibt es keinen Tag mehr, der das alte Image bezeichnet.

Der Schlüssel geht normalerweise nicht durch docker compose down verloren, da ein Bind-Mount dabei unverändert bleibt. Das Problem entsteht meist bei der Migration auf einen neuen VPS, wenn Sie nur compose.yml kopieren. Kopieren Sie auch ./data.

Egress bei einem Tarif mit Transferlimit überwachen

hbbr ist der einzige Teil dieses Stacks, der ein Transferlimit verbrauchen kann. In der FAQ von RustDesk wird eine weitergeleitete Verbindung bei einer Auflösung von 1920x1080 mit 30 KB/s bis 3 MB/s angegeben. Für normale Büroarbeit werden etwa 100 KB/s genannt. Das sind veröffentlichte Werte für eine einzelne Sitzung und keine Messung Ihrer Umgebung. Auf sechzig Stunden pro Monat hochgerechnet, also zwei Stunden pro Tag, ergibt sich folgendes Bild.

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

Bei der Rate für Büroarbeit verbraucht eine Sitzung etwa 21.6 GB pro Monat. Das wird kein Tarif bemerken. Am oberen Ende des veröffentlichten Bereichs kosten dieselben sechzig Stunden 648 GB. Zwei gleichzeitig aktive Sitzungen mit dieser Rate überschreiten innerhalb eines Monats ein Transferlimit von 1 TB. Am unteren Ende sind es 6.5 GB. Gigabytes entsprechen hier 1000 MB, wie Transferlimits üblicherweise berechnet werden.

docker stats schlüsselt dies nicht für Sie auf, weil ein Container mit Host-Netzwerk denselben Netzwerk-Namespace wie der Host verwendet. Seine Zähler sind daher die Zähler des Hosts. Zwei andere Werkzeuge sind dafür geeignet. vnstat misst den gesamten Server:

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

Der gesamte Server bedeutet wirklich der gesamte Server. Wenn auf dieser VPS zusätzlich ein Dienst läuft, der große Datenmengen überträgt, beispielsweise einer der selbst gehosteten Fotoserver, der jede Nacht die Fotobibliotheken von Telefonen abruft, werden dessen Uploads in derselben monatlichen Statistik wie der Relay-Verkehr erfasst.

Ein nftables-Zähler misst gezielt das 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

Diese Regel enthält kein Verdict. Sie zählt daher Pakete und Bytes, ohne die erlaubten Verbindungen zu ändern. Außerdem befindet sie sich in einer eigenen Tabelle und beeinträchtigt ufw nicht. Sie ist nicht persistent. Fügen Sie dieselben Zeilen in /etc/nftables.conf ein, wenn der Zähler nach einem Reboot wieder vorhanden sein soll. Der Zähler steigt nur, während tatsächlich eine Sitzung weitergeleitet wird. Steigt er weiter, obwohl keine Ihrer eigenen Maschinen verbunden ist, hat jemand anderes Ihr Relay gefunden. Genau das soll hbbr -k _ verhindern.

hbbr verfügt außerdem über Ratenbegrenzungen, die Sie reduzieren können. SINGLE_BANDWIDTH ist standardmäßig auf 128 Mb/s pro Relay-Verbindung und TOTAL_BANDWIDTH auf 1024 Mb/s über alle Verbindungen hinweg gesetzt. Mit SINGLE_BANDWIDTH=8 begrenzen Sie eine Sitzung auf ungefähr 1 MB/s. Das begrenzt die Geschwindigkeit, nicht das monatliche Gesamtvolumen. Betrachten Sie diese Einstellung daher als Möglichkeit, zu verhindern, dass eine einzelne Sitzung die Verbindung auslastet, und nicht als Budgetkontrolle.

Wenn Sie kein Relay benötigen

Bei einer persönlichen Umgebung benötigen Sie möglicherweise überhaupt keine dieser Komponenten. Verbinden Sie beide Rechner mit einem Mesh-VPN und stellen Sie die Verbindung direkt über die Tunneladresse her. Es gibt dann kein hbbs, kein hbbr, keinen Relay-Ausgang und keinen Container auf einem VPS, den Sie aktualisieren müssen.

Aktivieren Sie auf dem Rechner, den Sie steuern möchten, den direkten IP-Zugriff in den Sicherheitseinstellungen von RustDesk. Das Portfeld ist standardmäßig auf 21118 gesetzt. Prüfen Sie vor dem Verbindungsversuch, ob der Port auf Verbindungen wartet:

ss -tlnp | grep 21118

Verbinden Sie sich anschließend mit der VPN-Adresse dieses Peers statt mit einer ID. Laut der FAQ von RustDesk ist die Verbindung in diesem Modus unverschlüsselt. Verwenden Sie diesen Modus daher innerhalb des Tunnels und niemals über das offene Internet. Der Tunnel stellt die Verschlüsselung bereit.

Entscheiden Sie danach, wem die Rechner gehören. Ein selbst gehostetes hbbs und hbbr ist sinnvoll, wenn Sie Rechner betreuen, die Ihnen nicht gehören, oder Personen unterstützen, die niemals einen VPN-Client installieren werden. Auf deren Seite der Einrichtung benötigen sie dann nur eine ID und ein Passwort. Ein Mesh-VPN mit direktem IP-Zugriff ist sinnvoll, wenn jeder Rechner Ihnen gehört und einen Schlüssel verwenden kann. WireGuard im Vergleich zu Tailscale beschreibt die beiden üblichen Möglichkeiten zum Aufbau dieses Mesh-Netzwerks. einen Remote-Desktop auf einem Linux-VPS betreiben behandelt den anderen Fall, in dem der Rechner, dessen Bildschirm Sie anzeigen möchten, selbst der Server ist.

FAQ

Läuft jede RustDesk-Sitzung über mein Relay?

Nein. hbbs versucht zunächst, die beiden Clients direkt zu verbinden, indem es ein Hole Punching durch das NAT vor den beiden Clients verwendet. Nur Sitzungen, bei denen dies fehlschlägt, werden auf hbbr zurückgesetzt. Nur diese Sitzungen verursachen bei Ihnen Bandbreitenkosten. Eine Ausnahme ist ALWAYS_USE_RELAY=Y auf hbbs. Diese Einstellung zwingt jede Sitzung unabhängig davon über hbbr, ob ein direkter Pfad verfügbar war. Wenn diese Variable in Ihrer Compose-Datei gesetzt ist, wird jedes Byte jeder Sitzung Ihrem Transferkostenkonto zugerechnet.

Wo wird der RustDesk-Serverschlüssel gespeichert, und was passiert bei einem Verlust?

hbbs erzeugt id_ed25519 und id_ed25519.pub beim ersten Start in seinem Arbeitsverzeichnis. Dieses Verzeichnis ist /root im offiziellen Image. Mit dem oben gezeigten Volume-Mount erscheinen die Dateien daher unter ./data auf dem Host. Sichern Sie beide Dateien außerhalb des Servers. Bei einem Verlust erzeugt hbbs beim nächsten Start ein neues Schlüsselpaar. Jeder Client, der noch den alten öffentlichen Schlüssel verwendet, wird dann abgewiesen. Es gibt keine andere Wiederherstellungsmöglichkeit, als das Feld Key auf jedem Client manuell zu bearbeiten.

Welche Ports muss ich für einen selbst gehosteten RustDesk-Server öffnen?

TCP 21115, 21116 und 21117 sowie UDP 21116. hbbs verwendet 21115 für den NAT-Typ-Test und 21116 für die ID-Registrierung und den Heartbeat über UDP sowie für Hole Punching über TCP. hbbr verwendet 21117 für das Relay. TCP 21118 und 21119 sind die WebSocket-Ports für den Browser-Client. Lassen Sie diese Ports geschlossen, wenn Sie den Browser-Client nicht verwenden. TCP 21114 gehört zur Pro-Webkonsole. Der Open-Source-Build benötigt diesen Port nicht.

Können Fremde mein selbst gehostetes RustDesk-Relay verwenden?

Ja, wenn Sie hbbr mit der Standardkonfiguration ausführen. Laut der RustDesk-Dokumentation ermöglicht ein leerer Schlüssel Clients ohne passenden Schlüssel die Nutzung des Relays. Jeder, der Ihren Hostnamen und Port 21117 kennt, kann dann Netzwerkverkehr über Ihren Server leiten. Führen Sie hbbr mit -k _ aus, damit das Programm dasselbe Schlüsselpaar aus dem gemeinsamen ./data-Volume lädt, das hbbs erzeugt hat. Danach können nur Clients mit Ihrem öffentlichen Schlüssel Ihr Relay verwenden.