RustDesk Relay-Server selbst hosten: Ports und Schlüssel

Was ein selbst gehosteter RustDesk-Relay-Server ist

Ein selbst gehosteter RustDesk-Relay-Server besteht aus zwei Daemons auf einem VPS. hbbs ist der ID- und Rendezvous-Server: Er registriert jede Client-ID und stellt zwei Clients miteinander in Verbindung. hbbr ist der Relay-Server: Er überträgt die Sitzungsdaten, aber nur für Sitzungen, bei denen keine direkte Verbindung möglich war. 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 in der folgenden Konfiguration dasselbe Ed25519-Schlüsselpaar aus demselben Verzeichnis. Das müssen Sie konfigurieren; es ist keine Standardeinstellung: hbbs lädt oder erzeugt das Schlüsselpaar selbst, hbbr ignoriert Schlüssel jedoch, wenn Sie es nicht mit einem Schlüssel starten. Ed25519 ist ein Verfahren für Signaturen mit öffentlichen Schlüsseln. Das Schlüsselpaar legt fest, mit welchen Clients Ihr Server kommuniziert. Eine Benutzerdatenbank gibt es dahinter nicht.

hbbs und hbbr: Welcher Daemon Bandbreite verursacht

Der Datenverkehr von hbbs ist gering und konstant: ID-Registrierungen und Heartbeats sowie der kurze Austausch, mit dem zwei Peers einander bekannt gemacht werden. Er läuft den ganzen Tag und verursacht nahezu keinen Datenverbrauch.

Der Datenverkehr von hbbr ist die Sitzung selbst. Bildschirm-Frames laufen in eine Richtung, Tastatur- und Mausdaten in die andere. Jedes weitergeleitete Byte erreicht zuerst Ihren VPS und verlässt ihn anschließend wieder. Wenn Ihr Provider nur den ausgehenden Datenverkehr misst, kostet Sie eine weitergeleitete Sitzung ungefähr die Sitzungsrate. Wenn er den gesamten Datentransfer misst, 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, indem es Hole Punching durch das NAT (Network Address Translation) verwendet, das jeweils vor den Clients liegt. Wenn das funktioniert, berührt die Sitzung hbbr nicht, und Ihr Transferkontingent bleibt unangetastet. Wenn sich eine Seite hinter einem NAT befindet, 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 durchläuft jedes Frame Ihren VPS.

Eine Umgebungsvariable nimmt Ihnen diese Wahl ab. ALWAYS_USE_RELAY=Y auf hbbs erzwingt, dass jede Sitzung über hbbr läuft. Die RustDesk-Dokumentation zeigt diese Variable in einem ihrer Compose-Beispiele. Deshalb wird sie häufig kopiert. Dadurch werden Verbindungen vorhersehbarer, und der ausgehende Datenverkehr fällt tatsächlich an. Setzen Sie die Variable, weil Sie sich bewusst dafür entschieden haben, nicht weil Sie sie eingefügt haben.

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

Die folgenden Portnummern wurden am 10. Oktober 2026 anhand der RustDesk-Serverdokumentation und des rustdesk-server-Repositorys geprüft.

• TCP 21115 auf hbbs: der Test des NAT-Typs.
• UDP 21116 auf hbbs: ID-Registrierung und Heartbeat. Dies ist der Pfad, den ein Client standardmäßig verwendet.
• TCP 21116 auf hbbs: ID-Registrierung für Clients, die ausschließlich TCP verwenden, sowie TCP Hole Punching und der Verbindungsdienst.
• TCP 21117 auf hbbr: das Relay. Über diesen Port werden Sitzungsdaten übertragen. Dieser Port verursacht daher Kosten.
• 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 der HTTP-API-Server in RustDesk Server Pro. Der Open-Source-Build lauscht nicht auf diesem Port.

hbbs und hbbr mit fest gesetztem 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 ändern.

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 hbbs diesen Listener beim Start öffnet und Clients standardmäßig über ihn registriert werden.

Vier Dinge in dieser Datei sind bewusst so festgelegt. Der Tag ist 1.1.16, weiterhin das aktuelle Release im Oktober 2026, veröffentlicht am 20. Juli 2026, und nicht latest, weil latest für den zuletzt veröffentlichten Stand steht und ein docker compose pull sechs Monate später einen Server installieren kann, den Sie nie getestet haben. network_mode: "host" bindet die Host-Schnittstellen direkt, wie es die RustDesk-Dokumentation empfiehlt, und legt fest, wie sich Ihre Firewall verhält. ./data:/root stellt das Arbeitsverzeichnis des Images auf dem Host bereit, damit das Schlüsselpaar an einem Ort liegt, den Sie sichern können. hbbr -k _ ist die einzige Änderung gegenüber dem Upstream-Beispiel, weil der Standardwert Ihr Relay für jeden offen lässt. Wenn Compose für Sie neu ist, erklärt 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 wissen, wohin der Dienst verschoben wurde: Ü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 sind beide Dateien auf dem Host sichtbar.

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

id_ed25519.pub enthält eine einzelne Base64-Zeichenfolge. Diese Zeichenfolge tragen Sie bei jedem Client in das Feld Key ein. id_ed25519 ist der private Teil und verlässt den Server niemals. 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 auf einem neuen VPS neu aufbauen, 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. Deshalb weist hbbs ihn zurück, und der Client geht offline. Führen Sie sudo cat ~/rustdesk/data/id_ed25519.pub aus und vergleichen Sie die Ausgabe mit dem Feld Key auf einem beliebigen Client: Die beiden Zeichenfolgen stimmen nicht mehr überein. Diese Abweichung verursacht den gesamten Fehler. Sie beheben ihn, indem Sie die Einstellungen auf jedem Rechner manuell bearbeiten, auch auf den Rechnern, auf die Sie eigentlich mit RustDesk zugreifen wollten.

Der Schlüssel ist nicht das Sitzungspasswort. Wenn Sie beides verwechseln, wird häufig eines davon weggelassen. Der Schlüssel legt fest, mit welchen Clients Ihr Server kommuniziert. Das permanente Passwort oder der Einmalcode auf dem gesteuerten Rechner legt fest, wer eine Sitzung auf diesem Rechner öffnen darf. Sie benötigen beides. Das Vorhandensein des einen gleicht ein schwaches anderes nicht aus.

Warum ein nicht authentifiziertes Relay problematisch ist

Standardmäßig prüft hbbr nichts. Die RustDesk-Konfigurationsdokumentation weist ausdrücklich darauf hin: Ein leerer Schlüssel erlaubt Clients ohne passenden Schlüssel die Nutzung des Relays. Der leere Standardwert verhindert, dass neue Benutzer beim ersten Start an einem Schlüsselkonflikt scheitern. Der Nachteil: Jeder, der Ihre Adresse auf TCP 21117 findet, kann seinen Sitzungsverkehr über Ihren VPS und auf Ihre Kosten für das Datenübertragungsvolumen von Ihrer IP-Adresse aus weiterleiten.

command: hbbr -k _ behebt dieses Problem. Das Argument _ weist hbbr an, ein Schlüsselpaar aus seinem Arbeitsverzeichnis zu laden oder eines zu generieren, falls dort keines vorhanden ist. Da beide Container dasselbe ./data einbinden, verwenden sie dasselbe Schlüsselpaar wie hbbs. Es wird nichts manuell kopiert. Dadurch können die Schlüssel nicht voneinander abweichen.

Das gemeinsam verwendete Volume ist der Punkt, an dem häufig Fehler passieren. Wenn Sie hbbr ein eigenes Verzeichnis geben, generiert der Dienst ein anderes Schlüsselpaar. hbbs und hbbr verwenden dann unterschiedliche Schlüssel, alle weitergeleiteten Sitzungen schlagen fehl und direkte Sitzungen funktionieren weiterhin. Das Fehlerbild ist verwirrend: RustDesk erreicht einige Peers, andere jedoch nicht. Das hängt davon ab, ob Hole Punching zufällig erfolgreich war. Ein einzelnes ls -l ~/rustdesk/data/ mit nur einem id_ed25519-Paar schließt diesen Schlüsselkonflikt aus. Es beweist jedoch nicht, dass das Relay Schlüssel prüft, denn hbbr ignoriert diese Dateien, sofern es nicht mit einem nicht leeren Schlüssel gestartet wurde. Prüfen Sie daher zusätzlich den laufenden Befehl:

ps -eo args | grep '[h]bbr'

Dies sollte hbbr -k _ ausgeben. Ein reines hbbr bedeutet, dass das Relay weiterhin offen ist, unabhängig davon, welche Dateien im Verzeichnis liegen.

Clients auf Ihren Server verweisen

Öffnen Sie auf jeder Maschine RustDesk, 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, exakt und ohne nachgestelltes Leerzeichen einfügen.

Im Hauptfenster sollte anschließend angezeigt werden, dass der Client bereit ist. Falls dies nicht der Fall ist und der Client mit den Standardeinstellungen ausgeführt wird, liegt die Ursache meistens darin, dass UDP 21116 hbbs nicht erreicht. Über diesen Port registriert sich ein Client mit Standardeinstellungen und sendet seinen Heartbeat. Eine Offline-ID beweist das allein jedoch nicht. Ein Client mit gesetzter Option disable-udp auf Y registriert sich stattdessen über TCP 21116 und verwendet UDP 21116 nie. Prüfen Sie bei diesem Client daher zuerst TCP 21116.

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

Da die Container das Host-Netzwerk verwenden, gibt es keine Docker-NAT-Regel vor ihnen. Daher greifen 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. Andernfalls kann ein Fehler in der SSH-Regel den Zugriff auf Ihren eigenen Server sperren. 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 es viele Beispiele für einzelne RustDesk-Container tun, schreibt Docker eigene DNAT-Regeln. Die Pakete erreichen den Container dann, ohne die Kette zu durchlaufen, in der Ihre ufw-Regeln greifen. Eine ufw-Sperre für 21117 hat dann keine Wirkung. Der Relay-Dienst ist aus dem Internet erreichbar, obwohl ufw status etwas anderes angibt. 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.

Einen Stack aktualisieren, 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 bereits auf Ihren Clients gespeichert ist.

Schritt 5 ist die entscheidende Prüfung. Ein geänderter Schlüssel bleibt auf dem Server unbemerkt und führt dazu, dass alle Clients gleichzeitig nicht mehr funktionieren. Für ein Rollback tragen Sie wieder den alten Tag ein und führen erneut up -d aus. Das funktioniert nur, weil Sie den Tag fest angegeben haben: Mit latest hat docker compose pull den Namen auf das neue Image verschoben. Dadurch 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. Häufiger geschieht das bei der Migration auf einen neuen VPS, wenn nur compose.yml kopiert wird. Kopieren Sie ./data ebenfalls.

Ausgehenden Datenverkehr bei einem Tarif mit Übertragungsvolumen überwachen

hbbr ist der einzige Teil dieses Stacks, der ein Übertragungsvolumen verbrauchen kann. Laut der FAQ von RustDesk liegt eine weitergeleitete Verbindung bei einer Auflösung von 1920x1080 zwischen 30 KB/s und 3 MB/s. Normale Büroarbeit liegt dabei bei etwa 100 KB/s. Das sind veröffentlichte Werte für eine einzelne Sitzung und keine Messung Ihrer Umgebung. Hochgerechnet auf sechzig Stunden pro Monat, also zwei Stunden täglich, 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 fällt bei keinem Tarif ins Gewicht. Am oberen Ende des veröffentlichten Bereichs kosten dieselben sechzig Stunden 648 GB. Zwei gleichzeitige Sitzungen mit dieser Rate überschreiten innerhalb eines Monats ein Übertragungsvolumen von 1 TB. Am unteren Ende sind es 6.5 GB. Gigabytes entsprechen hier 1000 MB, wie Übertragungsvolumen normalerweise berechnet wird.

docker stats kann dies nicht für Sie aufschlüsseln, weil ein Container mit Host-Netzwerk den Netzwerk-Namespace des Hosts verwendet. Seine Zähler sind daher die Zähler des Hosts. Zwei andere Werkzeuge funktionieren dafür. vnstat misst den gesamten Server:

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

Der gesamte Server bedeutet tatsächlich der gesamte Server. Wenn auf dieser VPS zusätzlich etwas läuft, das große Datenmengen überträgt, beispielsweise einer der selbst gehosteten Fotoserver, die jede Nacht die Fotobibliotheken von Smartphones abrufen, werden diese Uploads im selben monatlichen Verbrauch wie der Relay-Datenverkehr erfasst. Bei einem Medienserver gilt dasselbe in umgekehrter Richtung. Etwas wie Halcyon, das eine Jellyfin-Bibliothek in eine durchsuchbare Videothek der 90er-Jahre verwandelt, streamt Inhalte an die jeweiligen Zuschauer. Dieser ausgehende Datenverkehr belastet dasselbe Übertragungsvolumen, das auch Ihr Relay verwendet.

Ein nftables-Zähler misst gezielt den Datenverkehr des Relays:

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 keine Entscheidung. Sie zählt daher Pakete und Bytes, ohne die Zulässigkeit des Datenverkehrs zu ändern. Außerdem liegt sie in einer eigenen Tabelle und beeinträchtigt ufw nicht. Sie ist nicht dauerhaft: Tragen Sie dieselben Zeilen in /etc/nftables.conf ein, wenn die Regel nach einem Reboot wieder vorhanden sein soll. Der Zähler steigt nur, während tatsächlich eine Sitzung weitergeleitet wird. Ein Zähler, der weiter ansteigt, obwohl keine Ihrer eigenen Maschinen verbunden ist, bedeutet, dass jemand anderes Ihr Relay gefunden hat. Genau diesen Fall soll hbbr -k _ verhindern. Da Sie nft list nicht jeden Morgen lesen werden, richten Sie dafür einen Cronjob ein. Dieser vergleicht den Byte-Zähler mit einem Schwellenwert und sendet eine Push-Benachrichtigung, sobald der Schwellenwert überschritten wird. Dafür eignet sich Ihr eigener ntfy-Server.

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 eingestellt. Mit SINGLE_BANDWIDTH=8 wird eine einzelne Sitzung auf etwa 1 MB/s begrenzt. Dadurch wird die Geschwindigkeit begrenzt, nicht die monatliche Gesamtmenge. Verwenden Sie diese Einstellung daher, um zu verhindern, dass eine einzelne Sitzung die Verbindung auslastet, und nicht als Kontrolle des verfügbaren Übertragungsvolumens.

Wenn Sie überhaupt kein Relay benötigen

Für eine persönliche Umgebung benötigen Sie möglicherweise nichts davon. Verbinden Sie beide Rechner mit einem Mesh-VPN und stellen Sie die Verbindung direkt zur Tunneladresse her. Es gibt dann kein hbbs, kein hbbr, keinen Relay-Egress 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 ihn daher innerhalb des Tunnels und niemals über das offene Internet. Die Verschlüsselung wird durch den Tunnel bereitgestellt.

Entscheiden Sie anhand der Eigentumsverhältnisse der Rechner. Ein selbst gehostetes hbbs und hbbr eignet sich, wenn Sie Rechner unterstützen, die Ihnen nicht gehören, oder Personen, die niemals einen VPN-Client installieren werden. Auf deren Seite besteht die Einrichtung dann aus einer ID und einem Passwort. Ein Mesh-VPN mit direktem IP-Zugriff eignet sich, wenn jeder Rechner Ihnen gehört und einen Schlüssel verwenden kann. WireGuard im Vergleich zu Tailscale behandelt die beiden üblichen Möglichkeiten zum Aufbau dieses Meshs. einen Remote Desktop auf einem Linux-VPS betreiben behandelt den anderen Fall, in dem der Rechner, dessen Bildschirm Sie benötigen, 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 NAT-Traversal per Hole Punching durch das NAT vor den jeweiligen Clients verwendet. Nur Sitzungen, bei denen dies fehlschlägt, werden auf hbbr zurückgesetzt. Nur diese Sitzungen verbrauchen Ihre Bandbreite. 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 die Variable in Ihrer Compose-Datei gesetzt ist, wird jedes Byte jeder Sitzung auf Ihre Transferabrechnung angerechnet.

Wo wird der RustDesk-Serverschlüssel gespeichert, und was passiert, wenn ich ihn verliere?

hbbs erzeugt id_ed25519 und id_ed25519.pub beim ersten Start in seinem Arbeitsverzeichnis. Dieses Verzeichnis ist /root innerhalb des offiziellen Images. Mit dem oben gezeigten Volume-Mount erscheinen die Dateien daher unter ./data auf dem Host. Sichern Sie beide Dateien außerhalb des Servers. Wenn sie verloren gehen, 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-Typentest und 21116 für die ID-Registrierung und den Heartbeat über UDP sowie für die Registrierung und das 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 sie daher geschlossen, wenn Sie ihn nicht verwenden. TCP 21114 gehört zum Pro-HTTP-API-Server. 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 erlaubt ein leerer Schlüssel Clients ohne passenden Schlüssel die Nutzung des Relays. Jeder, der Ihren Hostnamen und Port 21117 kennt, kann dann Datenverkehr über Ihren Server leiten. Starten Sie hbbr mit -k _, damit es dasselbe Schlüsselpaar aus dem gemeinsamen Volume ./data lädt, das auch hbbs verwendet. Danach können nur Clients mit Ihrem öffentlichen Schlüssel Datenverkehr über Ihr Relay leiten.