Categories

Rustdesk Server selbst hosten mit Docker Compose

Donate with

Donate BAT now

Verified BAT publisher

Ein selbst gehosteter RustDesk Server schafft eine kontrollierbare Basis für Fernwartung, Remote-Support und den Zugriff auf eigene Endgeräte. Statt für die Vermittlung und gegebenenfalls für den Relay-Datenverkehr ausschliesslich auf eine externe Plattform zu setzen, betreiben Sie die zentralen RustDesk-Dienste auf einem eigenen Linux-Server oder VPS. Dieser Leitfaden zeigt Schritt für Schritt, wie Sie einen RustDesk Server mit Docker Compose aufsetzen, die notwendigen Firewall-Ports freigeben und Windows- sowie Linux-Clients mit der korrekten Serveradresse und dem Public Key verbinden.

Die Anleitung richtet sich sowohl an Einsteiger, die einen zuverlässigen Remote-Desktop-Server im Homelab oder kleinen Unternehmen betreiben möchten, als auch an Systemadministratoren, die eine reproduzierbare Alternative zu klassischen Fernwartungsdiensten suchen. Vorausgesetzt wird lediglich, dass Docker und Docker Compose auf dem Linux-Host bereits ausgeführt werden können.

Was macht ein selbst gehosteter RustDesk Server?

RustDesk ist eine Remote-Desktop-Lösung. Der selbst gehostete Server übernimmt dabei nicht einfach die vollständige Bildschirmübertragung. Seine Kernaufgabe ist zunächst die Vermittlung zwischen den Endgeräten: Er registriert RustDesk-IDs, hilft bei NAT-Erkennung und unterstützt den Verbindungsaufbau. Kann zwischen zwei Clients keine direkte Verbindung hergestellt werden, leitet ein Relay-Dienst den Datenverkehr weiter. Dadurch funktionieren Verbindungen auch dann, wenn sich PCs hinter Firewalls, NAT-Routern oder unterschiedlichen Internetanschlüssen befinden.

• hbbs ist der ID-, Rendezvous- und Signalisierungsdienst. Er hilft Clients dabei, sich zu finden und einen direkten Verbindungsweg auszuhandeln.
• hbbr ist der Relay-Dienst. Er transportiert Bildschirm-, Steuerungs- und Dateidaten, wenn eine direkte Peer-to-Peer-Verbindung technisch nicht möglich ist.
• Der Public Key bestätigt dem RustDesk-Client, mit welchem selbst gehosteten Server er eine vertrauenswürdige Verbindung aufbauen soll.

Der wichtigste Vorteil eines eigenen RustDesk Servers liegt in der Infrastrukturkontrolle. Sie bestimmen den Serverstandort, die IP-Adresse beziehungsweise Domain, Firewall-Regeln, Backups und Update-Zeitpunkte selbst. Das ist für technisch versierte Privatanwender, IT-Dienstleister und Organisationen relevant, die Fernwartung nachvollziehbar in ihre bestehende Betriebs- und Sicherheitsarchitektur einbetten möchten. Ein eigener Server ersetzt jedoch weder ein Berechtigungskonzept noch sichere Endgeräte, starke Passwörter oder saubere Supportprozesse.

Typische Einsatzszenarien für RustDesk mit Docker

Fernwartung von Windows- und Linux-Arbeitsplätzen

Administratoren können Windows-Clients, Linux-Desktops und weitere unterstützte Endgeräte über eine eigene RustDesk-Infrastruktur erreichen. Das ist besonders praktisch, wenn Support-Mitarbeitende externe Arbeitsplätze betreuen, ohne für jeden Zugriff eine neue Plattform oder ein separates Kundenkonto verwenden zu müssen. Die zentrale Vorgabe von ID-Server, Relay-Server und Schlüssel sorgt dafür, dass alle eingerichteten Clients denselben RustDesk Server verwenden.

Homelab, Entwicklungsumgebung und private Infrastruktur

Für Homelabs eignet sich RustDesk als schlanke Lösung, um Testsysteme, einen Heim-PC oder Linux-VMs von unterwegs aus zu erreichen. Wer Docker Compose bereits für andere Services nutzt, erhält mit der Compose-Datei eine klar dokumentierte und bei Bedarf schnell wiederherstellbare Bereitstellung. Gerade Entwickler profitieren davon, dass Serverkonfiguration und Datenpfad nachvollziehbar im Verzeichnis /opt/rustdesk liegen.

KMU, Managed Services und kundengetrennte Betriebsmodelle

In kleineren und mittleren Unternehmen kann ein RustDesk Server eine technisch eigenständige Fernwartungsplattform bilden. IT-Dienstleister können einen dedizierten Server je Mandant oder eine zentral betriebene Instanz mit klaren Zuständigkeiten vorsehen. Entscheidend ist dabei die Kapazitätsplanung: Solange Verbindungen direkt zwischen zwei Clients zustande kommen, fällt deutlich weniger Relay-Traffic an. Werden viele Verbindungen über hbbr vermittelt, benötigt der Server insbesondere ausreichende Internetbandbreite.

Voraussetzungen und Abhängigkeiten

Diese Installation setzt einen Linux-Server mit öffentlicher IPv4-Adresse oder sauber eingerichteter Portweiterleitung voraus. Für professionelle Nutzung ist eine feste öffentliche IP-Adresse oder besser eine DNS-Domain sinnvoll. Der Server muss aus dem Internet erreichbar sein. Befindet er sich hinter Carrier-Grade NAT, genügt eine lokale UFW-Freigabe nicht. In diesem Fall benötigen Sie eine öffentliche IP, einen VPS oder eine vom Internetanbieter unterstützte Portweiterleitung.

• Docker Engine ist installiert und kann Container starten.
• Docker Compose v2 ist verfügbar, sodass docker compose funktioniert.
• Sie haben sudo-Rechte auf dem Linux-Server.
• Der Host kann ausgehende HTTPS-Verbindungen aufbauen. Dies wird für das Abrufen der externen IPv4-Adresse benötigt.
• curl, nano und optional ufw sind verfügbar. Auf Debian- und Ubuntu-Systemen lassen sich fehlende Hilfsprogramme bei Bedarf mit der Paketverwaltung installieren.
• Die Ports 21115/TCP, 21116/TCP, 21116/UDP und 21117/TCP sind lokal und auf jeder vorgeschalteten Netzwerk- oder Cloud-Firewall freigegeben.

Prüfen Sie die zwei zentralen Docker-Abhängigkeiten vor dem Start:

docker --version docker compose version

Fehlt der Befehl docker compose, ist das Compose-v2-Plugin nicht installiert oder die Docker-Installation unvollständig. Installieren Sie in diesem Fall das zur Linux-Distribution passende Docker-Compose-Plugin über die offizielle Docker-Paketquelle. Verwenden Sie nicht einfach docker up -d, denn up gehört zum Compose-Unterbefehl.

RustDesk Server mit Docker Compose installieren

1. Persistentes Datenverzeichnis und Compose-Datei anlegen

Die folgenden Befehle erstellen das Arbeitsverzeichnis und öffnen die Compose-Datei. Der Ordner data ist besonders wichtig: Hier speichert RustDesk unter anderem seinen Schlüsselbestand. Löschen Sie diesen Ordner nicht bei einem Update oder einer Bereinigung von Docker, da eingerichtete Clients sonst nicht mehr zum Server passen.

sudo mkdir -p /opt/rustdesk/data sudo nano /opt/rustdesk/compose.yml

Fügen Sie danach diesen Inhalt in /opt/rustdesk/compose.yml ein:

services: hbbs: container_name: hbbs image: rustdesk/rustdesk-server:latest command: hbbs volumes: - ./data:/root network_mode: "host" depends_on: - hbbr restart: unless-stopped hbbr: container_name: hbbr image: rustdesk/rustdesk-server:latest command: hbbr volumes: - ./data:/root network_mode: "host" restart: unless-stopped

Die Einstellung network_mode: "host" verwendet die Netzwerkschnittstellen des Linux-Hosts direkt. Daher sind in dieser Variante keine separaten Docker-Portmappings erforderlich. Die Firewall des Servers und gegebenenfalls die Firewall Ihres Providers oder Routers bleiben dennoch zuständig. Beide Container verwenden denselben Datenordner, damit der Relay-Dienst und der ID-Dienst auf denselben Schlüsselbestand zugreifen können.

2. Container starten und Status prüfen

Wechseln Sie in das Projektverzeichnis und starten Sie die beiden Dienste im Hintergrund. Docker lädt das RustDesk-Image beim ersten Start automatisch herunter. Durch restart: unless-stopped werden die Dienste nach einem Serverneustart wieder gestartet, solange Sie sie nicht bewusst beendet haben.

cd /opt/rustdesk sudo docker compose up -d sudo docker compose ps

In der Statusausgabe sollen die Container hbbs und hbbr als laufend erscheinen.

3. RustDesk Firewall-Ports auf dem Server freigeben

Für den RustDesk Server in dieser Konfiguration sind die folgenden Ports relevant. TCP 21115 unterstützt die NAT-Typ-Erkennung. TCP und UDP 21116 werden für Registrierung, Heartbeats, Hole Punching und Verbindungsaufbau benötigt. TCP 21117 wird vom Relay-Dienst hbbr verwendet. Öffnen Sie diese Ports nur, wenn Ihre Sicherheitsvorgaben und Ihr Betriebskonzept dies erlauben.

sudo ufw allow 21115/tcp sudo ufw allow 21116/tcp sudo ufw allow 21116/udp sudo ufw allow 21117/tcp sudo ufw status

Die UFW-Regeln gelten ausschliesslich für den Linux-Host. Steht der Server hinter einem Router, müssen Sie dieselben Ports zusätzlich auf die interne Server-IP weiterleiten. Bei einem VPS sind die Regeln häufig zusätzlich in einer Provider-Firewall, Security Group oder Netzwerk-ACL zu hinterlegen. Ist UFW deaktiviert, zeigt sudo ufw status den Status inactive. Das ist keine Erfolgsbestätigung für die externe Erreichbarkeit, sondern nur ein Hinweis, dass UFW selbst keine Regeln durchsetzt.

4. Öffentliche Serveradresse und RustDesk Public Key auslesen

Nach dem ersten Start erzeugt RustDesk den Schlüsselbestand im Ordner /opt/rustdesk/data. Mit dem folgenden Befehl lesen Sie die externe IPv4-Adresse und den für Clients benötigten Public Key aus. Übernehmen Sie den Befehl unverändert:

cd /opt/rustdesk && \ HOST=$(curl -4fsS https://api.ipify.org) && \ KEY=$(tr -d '\r\n' < data/id_ed25519.pub) && \ printf '\nID-Server: %s\nRelay-Server: %s\nAPI-Server: LEER\nKey: %s\n\n' "$HOST" "$HOST" "$KEY"

Die Ausgabe enthält alle Werte für die manuelle Client-Konfiguration. Der angezeigte Schlüssel stammt aus id_ed25519.pub und darf an RustDesk-Clients verteilt werden. Die private Datei id_ed25519 darf den Server dagegen nie verlassen. Sichern Sie den gesamten Datenordner geschützt und beschränken Sie die Zugriffsrechte auf Administratoren.

RustDesk Client unter Windows oder Linux mit dem eigenen Server verbinden

Öffnen Sie im RustDesk-Client das Menü mit den drei Punkten neben der eigenen RustDesk-ID und wechseln Sie zu Netzwerk. Je nach Client und Betriebssystem müssen Sie die Netzwerkeinstellungen zuerst entsperren. Tragen Sie die Werte aus der vorherigen Befehlsausgabe wie folgt ein:

• ID-Server: Öffentliche IPv4-Adresse oder bevorzugt DNS-Name Ihres RustDesk Servers.
• Relay-Server: Dieselbe öffentliche IPv4-Adresse oder derselbe DNS-Name, wenn hbbr auf demselben Host läuft.
• API-Server: Leer lassen. Die hier beschriebene OSS-Installation enthält keine Pro-Webkonsole und keinen API-Server.
• Key: Den vollständigen Inhalt von id_ed25519.pub aus der Befehlsausgabe einfügen.

Der Relay-Server kann in einfachen Umgebungen teilweise automatisch erkannt werden. Das explizite Eintragen ist jedoch sinnvoll, weil es die Konfiguration transparent macht und Fehler bei der Inbetriebnahme reduziert. Nutzen Sie anstelle einer wechselnden IP-Adresse möglichst einen DNS-Namen. Dadurch können Sie den Server später auf eine neue IP umziehen, ohne jeden Client manuell umzukonfigurieren.

Funktionstest, Betrieb und Fehleranalyse

Testen Sie den RustDesk Server nicht nur innerhalb desselben LANs. Verwenden Sie mindestens einen Client über einen externen Internetanschluss, zum Beispiel über Mobilfunk oder einen zweiten Standort. So erkennen Sie fehlende Portweiterleitungen, DNS-Probleme und CGNAT-Einschränkungen frühzeitig. Prüfen Sie parallel den Containerstatus und die aktuellen Dienstprotokolle:

cd /opt/rustdesk sudo docker compose logs --tail=100 hbbs hbbr

Typische Ursachen für Probleme sind schnell eingegrenzt. Ist data/id_ed25519.pub nicht vorhanden, sind die Container meist nicht erfolgreich gestartet oder der Befehl wurde im falschen Verzeichnis ausgeführt. Meldet Docker, dass eine Adresse bereits verwendet wird, belegt ein anderer Dienst einen RustDesk-Port. Prüfen Sie dies mit sudo ss -tulpn und passen Sie die kollidierende Konfiguration an. Funktioniert der ID-Server, aber Sitzungen brechen ab oder starten nur im selben LAN, kontrollieren Sie insbesondere TCP 21117 sowie die Router- und Provider-Firewall.

Für Updates sichern Sie zuerst /opt/rustdesk/data. Danach können Sie das aktuelle Container-Image laden und die Dienste neu erstellen:

cd /opt/rustdesk sudo docker compose pull sudo docker compose up -d

Das Tag latest vereinfacht Updates, bedeutet aber auch, dass ein späterer Pull eine neue Version liefern kann. In produktiven Umgebungen sollten Sie Updates zuerst testen und bei hohen Stabilitätsanforderungen ein geprüftes Image-Tag statt latest verwenden. Ein eigener RustDesk Server ist keine VPN-Lösung und ersetzt weder Patch-Management noch Endpoint-Schutz. Er ist ein Baustein für Fernwartung, der in ein umfassendes Sicherheitskonzept gehört.

RustDesk Server vs. TeamViewer: Wann passt welche Lösung?

RustDesk und TeamViewer lösen dieselbe Grundaufgabe, verfolgen aber unterschiedliche Betriebsmodelle. RustDesk mit eigenem Docker-Server eignet sich für Teams, die Infrastruktur, Datenpfade und Update-Fenster selbst steuern möchten. TeamViewer reduziert dagegen den administrativen Aufwand, weil die Plattform als Dienst bereitsteht. Die folgende Übersicht fokussiert auf eine selbst gehostete RustDesk-OSS-Installation gegenüber dem üblichen kommerziellen Einsatz von TeamViewer.

Fazit: Kontrollierte Fernwartung mit einem reproduzierbaren Docker-Setup

Ein RustDesk Server mit Docker Compose lässt sich mit wenigen Bausteinen dauerhaft und nachvollziehbar betreiben: persistenter Datenordner, die Dienste hbbs und hbbr, korrekt freigegebene Ports sowie die Client-Konfiguration mit Serveradresse und Public Key. Für Linux- und Windows-Administratoren ist diese Architektur besonders interessant, weil sie sich gut dokumentieren, sichern, aktualisieren und in vorhandene Serverprozesse integrieren lässt.

Die Entscheidung zwischen RustDesk und TeamViewer ist keine reine Funktionsfrage. Wer möglichst schnell ohne eigene Serverinfrastruktur Fernzugriff bereitstellen will, profitiert von einer gemanagten Plattform. Wer hingegen Datenwege, Serverstandort, Netzwerkregeln und Wartungsfenster selbst steuern kann und möchte, erhält mit einem selbst gehosteten RustDesk Server eine technisch klare TeamViewer-Alternative. Entscheidend bleiben eine öffentlich erreichbare Infrastruktur, sorgfältiger Umgang mit dem privaten Schlüssel, regelmässige Updates und ein verantwortungsvoller Umgang mit Fernzugriffsrechten.