RustDesk Docker: Containerisierte RustDesk-Server-Anleitung

Sie möchten RustDesk selbst hosten, ohne sich mit manuellen Builds, Abhängigkeitsproblemen oder fragilen VM‑Images herumzuschlagen. Diese Anleitung zeigt, wie Sie einen produktionsreifen RustDesk‑Server‑Stack mit Docker und Docker Compose betreiben, sodass Sie Updates, Backups und Skalierung wie ein Ops‑Profi — nicht wie ein Hobbyist — verwalten.

Warum Docker für RustDesk verwenden

Container bieten zwei unmittelbare Vorteile für eine selbst gehostete Remote‑Access‑Umgebung: reproduzierbare Deployments und Isolation. Statt hbbs/hbbr lokal zu kompilieren oder plattformspezifische Pakete zu betreiben, ziehen Sie ein Docker‑Image, mounten ein persistentes Volume und starten den Dienst. Das vereinfacht Upgrades, CI/CD und Host‑Migrationen. Wenn Sie bereits andere Dienste in Containern betreiben (NGINX, certbot, Monitoring), hält die Integration von RustDesk auf diese Weise Ihre Infrastruktur konsistent.

Wann nicht containerisieren: Wenn Sie angepasste, gepatchte Binärdateien oder tiefe Kernel‑Integration für extrem leistungsfähige Relays benötigen, ist eine native Installation möglicherweise vorzuziehen. Ebenfalls relevant: Wenn Sie eine offiziell unterstützte Enterprise‑SLA vom Anbieter brauchen, prüfen Sie, ob Container von diesem Anbieter unterstützt werden.

RustDesk-Server‑Komponenten — kurzer Überblick

RustDesk teilt die Serverrolle mindestens in zwei Komponenten auf:

• hbbs — der ID-/Signalisierungs‑Server. Er übernimmt Registrierung und Rendezvous der Clients.
• hbbr — der Relay‑Server (falls NAT‑Traversal fehlschlägt). Er leitet den Datenverkehr zwischen Peers weiter.

In Produktion betreiben Sie in der Regel beide Dienste. Ein einzelner, leichtgewichtiger Host kann beide Services ausführen; in größeren Deployments trennt man sie, stellt hbbr‑Instanzen hinter einen Load‑Balancer und fügt Autoscaling für Relay‑Kapazität hinzu.

Quickstart: Beispiel‑Deployment mit Docker Compose

Voraussetzungen: Ubuntu 22.04 LTS (oder jedes Linux mit Docker Engine 20.10+), Docker Compose v2.x, ein Domainname (Beispiel: rustdesk.example.com). Planen Sie mindestens 512 MB RAM für einen kleinen Testserver ein; für ein Relay, das mehrere aktive Sitzungen bedienen soll, werden 1 GB+ empfohlen.

Unten ein praktisches Docker Compose‑Beispiel, das hbbs und hbbr als separate Services betreibt, persistente Daten mountet und die üblichen RustDesk‑Ports veröffentlicht. Prüfen Sie vor dem Start die offiziellen rustdesk/rustdesk-server-Image‑Tags auf den neuesten stabilen Tag und ersetzen Sie rustdesk/rustdesk-server:latest, wenn Sie eine feste Version verwenden möchten.

version: '3.8'

services:
  hbbs:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbs
    command: ["hbbs", "--listen", "0.0.0.0:21115"]
    ports:
      - "21115:21115/tcp"
      - "21115:21115/udp"
    volumes:
      - ./data/hbbs:/data
    restart: unless-stopped

  hbbr:
    image: rustdesk/rustdesk-server:latest
    container_name: rustdesk-hbbr
    command: ["hbbr", "--listen", "0.0.0.0:21116", "--relay", "0.0.0.0:21116"]
    ports:
      - "21116:21116/tcp"
      - "21116:21116/udp"
    volumes:
      - ./data/hbbr:/data
    restart: unless-stopped

networks:
  default:
    external: false

Erläuterung:

• Wir betreiben hbbs auf TCP/UDP‑Port 21115 und hbbr auf 21116 — das sind die gängigen Defaults für RustDesk‑Server‑Builds. Bestätigen Sie die Port‑Zuordnung für das von Ihnen verwendete Image (einige Community‑Builds verwenden andere Defaults).
• Persistente Volumes ./data/hbbs und ./data/hbbr sichern Ihre Registrierungs‑ und Relay‑Daten über Neustarts hinweg.
• Verwenden Sie restart: unless-stopped für grundlegende Resilienz; für Produktion binden Sie sich an die Neustart‑Policies Ihrer Orchestrierungsplattform.

Sicher veröffentlichen: TLS, Reverse‑Proxy und Firewall

Signalisierungs‑ und Relay‑Traffic von RustDesk lassen sich mit TLS und üblichen Firewall‑Regeln absichern. Es gibt zwei gebräuchliche Ansätze:

1. Direktes TLS mit einem Proxy vor hbbs (empfohlen für das Zertifikats‑Management auf Web‑Ebene).
2. hbbr als rohes TCP/UDP‑Relay belassen und das Host‑Netzwerk absichern (z. B. ufw/nftables), während hbbs mit TLS geschützt wird.

Die meisten Setups nutzen NGINX oder Traefik, um TLS zu terminieren und den Traffic an hbbs weiterzuleiten. Beispiel für einen NGINX‑Serverblock, der TLS für rustdesk.example.com terminiert:

server {
  listen 443 ssl;
  server_name rustdesk.example.com;

  ssl_certificate /etc/letsencrypt/live/rustdesk.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/rustdesk.example.com/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:21115;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

# Optional: redirect http to https
server {
  listen 80;
  server_name rustdesk.example.com;
  return 301 https://$host$request_uri;
}

Verwenden Sie certbot (Let's Encrypt) oder Ihre CA, um Zertifikate zu beziehen. Wenn Ihr Relay (hbbr) öffentlich über UDP/TCP läuft, öffnen Sie diese Ports direkt und beschränken den Zugriff per Firewall auf die erwarteten IP‑Bereiche oder stellen Sie Relay‑Knoten in einem privaten Subnetz hinter einem Load‑Balancer bereit.

DNS, Clients und NAT‑Traversal

Richten Sie einen DNS‑A‑Record (z. B. rustdesk.example.com) auf die öffentliche IP Ihres Servers. Im RustDesk‑Client tragen Sie diese Domain als Server‑Adresse für ID‑ und Relay‑Lookup ein. Clients nutzen den ID‑Server für das Rendezvous; wenn beide Clients hinter restriktiven NATs liegen, leitet hbbr die Sitzung über Ihren Relay‑Server.

Wenn Sie Client‑Maschinen in einem LAN verwalten, können Sie ein internes DNS betreiben oder eine Konfigurationsdatei verteilen, die Clients auf die interne IP von hbbs verweist, um lokale Verbindungen zu beschleunigen.

Skalierung und Ressourcenempfehlungen

Wie viel CPU/RAM benötigt ein Relay? Das hängt von gleichzeitigen Sitzungen und dem Sitzungs‑Typ ab:

• Kleiner Testserver: 1 vCPU, 512 MB RAM — wenige inaktive Verbindungen.
• Produktions‑Relay (leichte Nutzung): 2 vCPU, 1–2 GB RAM — dutzende gleichzeitige Verbindungen.
• High‑Throughput‑Relay: 4+ vCPU, 4+ GB RAM und Netzwerk‑Kapazität entsprechend der erwarteten Bandbreite (z. B. 100+ Mbps).

Wir empfehlen, hbbr‑Instanzen hinter einem Load‑Balancer automatisch zu skalieren, wenn Sie Lastspitzen erwarten (medienintensive Fernsteuerung, Bildschirmfreigabe). Nutzen Sie Container‑Orchestrierung (Kubernetes, Docker Swarm) oder einfaches horizontales Scaling mit einem TCP/UDP‑Load‑Balancer (haproxy, Cloud‑LB), der Client‑IPs erhält.

Backups, Updates und Version‑Pinning

Mounten Sie stets persistente Volumes für Daten und sichern Sie diese regelmäßig. Ein minimales Backup‑Skript:

# daily-backup.sh
TIMESTAMP=$(date +%F)
mkdir -p /backups/rustdesk/$TIMESTAMP
rsync -a ./data /backups/rustdesk/$TIMESTAMP/
# rotate: keep 14 days
find /backups/rustdesk -maxdepth 1 -type d -mtime +14 -exec rm -rf {} \;

Für Updates pinnen Sie das Docker‑Image mit einem Tag statt :latest. Testen Sie in einer Staging‑Umgebung, bevor Sie das Server‑Image aktualisieren. Beispiel‑Workflow:

1. Neues Image ziehen: docker pull rustdesk/rustdesk-server:1.3.0 (Beispiel).
2. Starten Sie einen Testcontainer mit denselben Volumes und führen Sie Smoke‑Tests durch.
3. Planen Sie ein Wartungsfenster und ersetzen Sie die Container auf den Produktions‑Hosts.

Fehlerbehebung und häufige Probleme

Beginnen Sie mit den Logs: docker logs rustdesk-hbbs und docker logs rustdesk-hbbr. Typische Probleme:

• Clients können sich nicht registrieren: Prüfen Sie, ob hbbs über die Domain erreichbar ist und das TLS‑Zertifikat gültig ist.
• Sitzungen fallen auf Relay zurück, die Performance ist schlecht: Überprüfen Sie CPU/Memory und Netzwerk des Relay‑Hosts. Relay‑Pakete laufen typischerweise über UDP; stellen Sie sicher, dass UDP in Firewall und Cloud‑Security‑Group erlaubt ist.
• Clients zeigen inkompatible Versionen: Verwenden Sie kompatible RustDesk‑Client/Server‑Versionen. Wenn Sie das Server‑Image pinnen, stellen Sie sicher, dass Clients keine veralteten Protokollfeatures nutzen.

Wenn NAT‑Traversal bei vielen Clients konsequent fehlschlägt, liegt das meist an symmetric NATs oder Unternehmensfirewalls. In solchen Fällen setzen Sie auf hbbr‑Relays und überwachen Latenz/Bandbreite, um eine akzeptable Nutzererfahrung sicherzustellen.

Sicherheitsaspekte

Beim Self‑Hosting liegt die Verantwortung bei Ihnen. Wichtige Maßnahmen:

• Terminate TLS am Reverse‑Proxy und verwenden Sie starke Cipher. Beschaffen Sie Zertifikate von Let's Encrypt oder einer vertrauenswürdigen CA.
• Härten Sie den Host: Öffnen Sie nur notwendige Ports, aktivieren Sie automatische Sicherheitsupdates im OS und nutzen Sie eine Firewall (ufw/nftables).
• Beschränken Sie den Zugriff auf Verwaltungsoberflächen und überwachen Sie Logs auf Brute‑Force‑Versuche. Erwägen Sie Netzwerksegmentierung; platzieren Sie Relay‑Knoten in einem separaten Subnetz, wenn möglich.

Wenn Sie eine umfassendere Diskussion zur Absicherung von Remote‑Zugriff wünschen, siehe unsere Beiträge zu remote desktop security und die praktischen Trade‑offs in self‑hosted remote desktop.

Wenn ein Managed‑Anbieter besser ist

Self‑Hosting mit Docker gibt Kontrolle und Privatsphäre, aber wenn Sie eine vollständig verwaltete SLA, offizielle Enterprise‑Features (User‑Management, zentrales Billing) oder turn‑key Windows‑AD‑Integration benötigen, sind kommerzielle Anbieter wie TeamViewer oder AnyDesk oft die bessere Wahl. Seien Sie ehrlich bei den Trade‑offs: Self‑Hosting spart wiederkehrende Per‑Seat‑Kosten und bietet Datenlokalität, kostet aber Operations‑Zeit für Wartung, Monitoring und Absicherung.

Nächste Schritte und Referenzen

Checkliste für den Weg von Labor zu Produktion:

1. Wählen Sie einen Host mit Docker Engine 20.10+ und Docker Compose v2.x.
2. Erstellen Sie persistente Volumes und einen täglichen Backup‑Job.
3. Pinnen Sie das Server‑Image und validieren Sie Updates in Staging.
4. Terminieren Sie TLS mit NGINX/Traefik und beziehen Sie Zertifikate von Let's Encrypt.
5. Überwachen Sie die Relay‑Hosts und skalieren Sie hbbr, wenn CPU oder Bandbreite kritische Schwellenwerte erreichen.

Möchten Sie einen sauberen Download zum Vergleich neben dem Container‑Ansatz? Laden Sie Tenvo’s Binaries oder Installer unter /download herunter und prüfen Sie unsere /pricing-Seite für Bereitstellungsoptionen. Falls Sie eine umfassendere Remote‑Access‑Einrichtung bevorzugen, behandelt unser remote access setup guide Netzwerk‑, Auth‑ und Usability‑Themen über verschiedene Tools hinweg.

RustDesk unter Docker zu betreiben ist für die meisten Self‑Hoster ein wartbarer Ansatz: Es vereinfacht Upgrades und fügt sich gut in bestehende Container‑Infrastrukturen ein. Wenn Sie eine Kopie der Compose‑Datei oder Unterstützung bei der Anpassung an Kubernetes benötigen, fragen Sie nach — ich stelle ein K8s‑Manifest und ein Helm‑Chart‑Beispiel zur Verfügung.

Bereit, es auszuprobieren? Laden Sie die notwendigen Clients oder Test‑Images von /download herunter und bringen Sie Ihren containerisierten RustDesk‑Server noch heute in Betrieb.