RustDesk self hosted setup — vollständige Docker + Caddy TLS Schritt-für-Schritt-Anleitung

Sie wollen RustDesk selbst hosten, stoßen aber immer wieder auf dieselben Blocker: NAT und Firewalls, verwirrende Serverkomponenten und die Frage, ob zusätzliches TLS neben der von RustDesk eingebauten Verschlüsselung erforderlich ist. Diese Anleitung führt technisch versierte Leser Schritt für Schritt durch ein vollständiges, reproduzierbares RustDesk Self‑Hosted‑Setup auf einem einzelnen VPS — Docker Compose für hbbs/hbbr und TLS‑Vorlauf mit Caddy, damit Clients von restriktiven Netzwerken aus über Port 443 verbinden können.

Was wir bauen und warum

Das Ziel: ein Rendezvous‑ und Relay‑Server auf einem einzelnen VPS, auf den Ihre Clients per DNS‑Name zeigen. Beteiligte Komponenten:

• rustdesk Serverkomponenten (hbbs und hbbr) laufen in Docker — in dieser Anleitung getestet mit rustdesk-server v1.2.1 Images.
• Caddy v2 (Zertifikatsverwaltung via Let's Encrypt) als TLS‑Frontdoor auf Port 443, damit Clients das Relay auch erreichen, wenn ausgehendes 21115 blockiert ist.
• Optionales UDP‑Passthrough oder zusätzliche Relays zur Skalierung (in den Anmerkungen behandelt).

Warum so? Das Protokoll von RustDesk stellt bereits End‑to‑End‑Verschlüsselung für die Sitzung bereit, aber viele Netzwerke erlauben nur ausgehendes 443/80. TLS am VPS zu terminieren (und Caddy die Zertifikate automatisch beziehen und erneuern zu lassen) ist praktisch, um den Dienst erreichbar zu machen, ohne nicht standardmäßige Ports zu öffnen. Wenn Sie nur LAN‑Zugriff oder NAT‑Kontrolle mit Reverse‑Tunnels wünschen, siehe unseren Artikel zu remote-desktop-without-port-forwarding.

Voraussetzungen und Entscheidungen

Was ich beim Schreiben verwendet habe:

• Ubuntu 22.04 LTS auf einem öffentlichen VPS (1 vCPU / 2 GB RAM genügt für Tests; für viele Clients auf 4+ CPU hoch skalieren und CPU/RAM beobachten).
• Docker 24.x und Docker Compose v2 (compose V2 CLI Syntax).
• rustdesk-server Docker Image (Tag v1.2.1 in dieser Anleitung) — bei neueren stabilen Releases anpassen.
• Caddy v2.6+ (Caddys automatische ACME‑Funktionen machen Zertifikatserneuerungen unkompliziert).
• Ein DNS A‑Record wie rustdesk.example.com, der auf die öffentliche IP des VPS zeigt, und geöffnete Ports 80/443 (Caddy benötigt 80/443 zur Validierung).

Anmerkungen, wann ein gehostetes kommerzielles Produkt besser passt: Wenn Sie SLA‑Garantie, erweiterte Sitzungsprüfung oder kommerziellen Support benötigen, sind TeamViewer/AnyDesk möglicherweise geeigneter — siehe rustdesk-vs-anydesk und unsere Preisvergleichsartikel. Self‑Hosting lohnt sich, wenn Sie Kontrolle, geringere laufende Kosten oder die Vermeidung dritter Server wünschen.

Schritt 1 — RustDesk Server mit Docker Compose bereitstellen

Erstellen Sie ein Projektverzeichnis auf dem VPS und legen Sie die unten stehende docker-compose.yml ab. Dieses Beispiel exponiert die typischen RustDesk Serverports auf dem Host. Ersetzen Sie Umgebungsvariablen und Image‑Tags entsprechend Ihrer Umgebung.

mkdir -p ~/rustdesk-server
cd ~/rustdesk-server
cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  rustdesk-server:
    image: rustdesk/rustdesk-server:1.2.1
    container_name: rustdesk-server
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"   # rendezvous / TCP relay
      - "21115:21115/udp"   # optional UDP relay (if your image supports it)
      - "21116:21116/udp"   # additional UDP (some builds use multiple UDP ports)
    volumes:
      - ./data:/root/.config/rustdesk-server
    environment:
      - RUSTDESK_RELAY_IPV4=0.0.0.0
      - RUSTDESK_RELAY_PORT=21115
EOF

Starten:

docker compose up -d
# watch logs
docker compose logs -f rustdesk-server

Bestätigen Sie, dass der Container gestartet ist und auf 21115 hört. Auf dem VPS:

ss -tuln | grep 21115

Wenn das von Ihnen verwendete Image andere Ports exponiert oder einen anderen Konfigurationsstil hat, konsultieren Sie das README des Images. Manche Betreiber kompilieren hbbs/hbbr manuell und nutzen eigene Ports; passen Sie die Schritte entsprechend an.

Schritt 2 — Caddy verwenden, um TLS über das Relay (443) zu legen

Es gibt zwei gängige Muster, um RustDesk über Port 443 erreichbar zu machen:

1. TCP‑TLS‑Termination mit Caddy 2.6+ (Caddy terminiert TLS und leitet rohen TCP‑Traffic an das RustDesk‑Relay weiter). Caddy hat in v2.6 verbesserte TCP‑Funktionen hinzugefügt; mit diesem Ansatz erhalten Sie automatische ACME‑Zertifikate und Erneuerungen.
2. Lassen Sie Caddy nur die Zertifikate verwalten und verwenden Sie einen TCP‑Proxy (stunnel, HAProxy oder Nginx stream), der diese Cert‑Dateien nutzt. Dies ist ein Fallback, wenn Ihre Caddy‑Version oder Umgebung die benötigten TCP‑Proxy‑Funktionen nicht unterstützt.

Unten ein minimales, pragmatisches Caddy‑Setup, das Caddy TLS auf Port 443 terminiert und die rohe TCP‑Verbindung an das RustDesk‑Relay auf localhost:21115 weiterleitet. Das erfordert Caddy v2.6+ (prüfen mit caddy version).

# Caddyfile (save as ./Caddyfile in the same folder as docker-compose.yml)
rustdesk.example.com:443 {
    # Caddy will obtain/renew certificates automatically
    reverse_proxy 127.0.0.1:21115 {
        # Use plain TCP transport; Caddy will accept TLS from clients and connect to the backend via TCP
        transport http {
            # We don't speak HTTP to the backend; keep minimal transport settings
        }
    }
}

Docker‑Compose‑Ausschnitt, um Caddy neben dem rustdesk Server (im gleichen Projekt) zu betreiben:

cat >> docker-compose.yml <<'EOF'
  caddy:
    image: caddy:2.6.4
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
volumes:
  caddy_data:
  caddy_config:
EOF

docker compose up -d caddy

Wichtiger Hinweis: Caddys eingebaute reverse_proxy-Funktion ist HTTP‑orientiert; das Verhalten beim Proxying von nicht‑HTTP‑Raw‑TCP hängt von der Caddy‑Version und den Transportoptionen ab. In der Praxis nutzen viele Betreiber die in 2.6 eingeführten TCP‑Proxying‑Funktionen, um TLS für beliebige TCP‑Backends zu terminieren. Treten Protokollprobleme auf, verwenden Sie Option (2) oben: lassen Sie Caddy die Zertifikate verwalten und übergeben Sie die Cert‑Dateien an eine kleine TCP‑TLS‑Schicht (stunnel oder HAProxy stream), die dann Plain‑TCP an rustdesk weiterleitet.

Beispiel: Caddy als Zertifikatsmanager + stunnel für TLS‑Termination (Kurzüberblick).

# 1) Ensure Caddy is running and has issued certs for rustdesk.example.com
# 2) Copy cert/key from Caddy storage into a place stunnel can read, or mount the same volume.
# 3) Run stunnel with a config that points TLS 443 -> 127.0.0.1:21115

# stunnel.conf snippet
[rustdesk]
accept = 443
connect = 127.0.0.1:21115
cert = /etc/stunnel/fullchain.pem
key = /etc/stunnel/privkey.pem

# In Docker world, mount Caddy's certificate files into the stunnel container path above.

Beide Ansätze liefern Ihnen einen Hostnamen (rustdesk.example.com) und Port 443 für Clients. Testen Sie die Verbindung von einer anderen Maschine mit: nc -vz rustdesk.example.com 443 — Sie sollten einen TLS‑Handshake sehen, wenn Caddy/stunnel korrekt konfiguriert sind.

Schritt 3 — Clients auf Ihren Self‑Hosted Server zeigen lassen

RustDesk‑Clients erlauben benutzerdefinierte ID/Relay‑Server in den Einstellungen. Die genaue UI variiert je nach Plattform und Version, die essentiellen Werte sind:

• ID Server / Rendezvous: rustdesk.example.com:443 (oder Ihre Domain und Port)
• Relay Server: rustdesk.example.com:443

Unter Windows: RustDesk öffnen > Settings > ID/Server und Id server sowie Relay server auf rustdesk.example.com:443 setzen. Unter Linux und macOS finden Sie dieselben Optionen in den Preferences. Für Headless‑Installationen können Clients manchmal per Kommandozeilenparameter oder Konfigurationsdatei gesteuert werden — prüfen Sie das Client‑Repo für Details.

Stellen Sie sicher, dass Clients aktuell sind (1.2.x oder neuer zum Zeitpunkt des Schreibens). Neuere Clients enthalten Protokollfixes und bessere NAT‑Traversal. Bei stark veralteten Clients kann das Verhalten abweichen.

Fehlerbehebung und Härtung

Häufige Probleme und Debug‑Schritte:

• Firewall: Prüfen Sie, dass die VPS‑Firewall (ufw/iptables/Cloud‑Provider) 80/443 eingehend erlaubt. Für den lokalen RustDesk‑Server‑Container, der auf 21115 hört, stellen Sie sicher, dass der TCP‑Socket existiert (ss/netstat).
• Zertifikatsausstellung: Wenn Let's Encrypt nicht validieren kann, protokolliert Caddy einen Fehler. Prüfen Sie DNS A‑Record und ob Port 80 während der Initialausstellung erreichbar ist.
• Protokollmismatch: Wenn Sie einen erfolgreichen TLS‑Handshake sehen, aber Verbindungen von Clients fehlschlagen, proxien Sie möglicherweise versehentlich nur HTTP mit Caddy. Verwenden Sie in solchen Fällen die stunnel‑Variante.
• UDP‑Relay: RustDesk‑Performance verbessert sich mit UDP für Frame‑Übertragung; wenn UDP im Netzwerkpfad blockiert ist, fällt die Verbindung auf TCP‑Relay zurück. Exponieren/forwarden Sie UDP‑Ports nur, wenn Sie das Netzwerk kontrollieren und wissen, was Sie tun.

Sicherheitshärtung:

• Führen Sie den rustdesk Server unter einem dedizierten, unprivilegierten Benutzer und halten Sie Docker‑Images aktuell.
• Aktivieren Sie fail2ban oder ähnliches, um wiederholte fehlgeschlagene Verbindungen zu drosseln, und überwachen Sie Logs (docker compose logs -f rustdesk-server).
• Sichern Sie regelmäßig Ihr rustdesk Server‑Datenverzeichnis (im Beispiel ./data).
• Erwägen Sie, das Relay hinter einem privaten Netzwerk oder VPC zu betreiben, wenn Sie mehrere Relays betreiben.

Skalierungs‑Hinweise: Ein einzelnes Relay genügt für kleine Teams. Für größere Deployments betreiben Sie mehrere hbbr Prozesse auf separaten Maschinen und verwenden DNS‑Loadbalancing oder einen richtigen L4‑Loadbalancer. Wenn Sie zentrale Enterprise‑Funktionen wie Auditing benötigen, haben kommerzielle Lösungen ggf. Vorteile. Siehe unsere Artikel zu self-hosted-remote-desktop und rustdesk-vs-anydesk für Abwägungen.

Betrieb, Kosten und abschließende Empfehlungen

Betriebskosten sind hauptsächlich VPS‑Gebühren und Ihre Zeit. Ein typischer kleiner VPS (1–2 CPU, 2–4 GB) kostet etwa $5–10/Monat (DigitalOcean, Vultr, Hetzner). Caddy und RustDesk Server sind Open‑Source; die primären laufenden Kosten sind das Hosting. Für GUI‑basierte Abrechnung oder Enterprise‑Support verlangen kommerzielle Anbieter pro Seat oder Session — siehe unsere Preisvergleiche wie anydesk-pricing-explained und godeskflow-vs-teamviewer-pricing für Kontext.

Empfehlungen:

• Starten Sie mit einem einzelnen VPS und dem oben gezeigten Docker Compose Layout. Testen Sie Verbindungen aus genau den Netzwerken, in denen Ihre Nutzer sind (Home‑ISPs, Firmenfirewalls).
• Wenn Clients häufig hinter sehr restriktiven Firewalls sind, betreiben Sie Ihr Relay auf 443 und verifizieren Sie die TLS‑Termination; verwenden Sie Caddy+stunnel, wenn reines Caddy‑TCP‑Proxying Probleme verursacht.
• Automatisieren Sie Backups des Server‑Datenverzeichnisses und verfolgen Sie Image‑Upgrades. RustDesk Server‑Releases ändern sich; testen Sie Upgrades in einer Staging‑Umgebung, wenn Sie auf Produktionsverfügbarkeit angewiesen sind.

Wenn Sie eine kürzere Anleitung zu Remote‑Access‑Mustern oder Alternativen möchten, lesen Sie unsere verwandten Artikel: remote-access-setup-guide und remote-desktop-security.

Fertig gelesen? Wenn Sie eine vollständig Open‑Source Remote‑Desktop‑Lösung ausprobieren möchten, die sich gut selbst hosten lässt, laden Sie GoDesk herunter oder vergleichen Sie die Preise — siehe GoDesk download und GoDesk pricing. Wenn Sie dieses RustDesk‑Setup bereitstellen möchten, erstellen Sie die docker-compose.yml und Caddyfile oben und führen docker compose up -d aus. Für einen schnellen Start gehen Sie zu /download, um Clients zu laden und sich zu verbinden.