RustDesk-Server auf dem Synology NAS installieren: Fernwartung als TeamViewer-Alternative

Wer als IT-Dienstleister oder KMU-Admin Fernwartung betreibt, kennt das Problem: TeamViewer und AnyDesk kosten pro Techniker mehrere hundert Euro im Jahr, routen alle Verbindungen über Fremdserver und lassen sich kaum an eigene Sicherheitsanforderungen anpassen. RustDesk Server OSS ist die Open-Source-Antwort darauf – eine vollständige Relay-Infrastruktur, die du auf deinem eigenen Synology NAS betreibst. Verbindungen laufen entweder direkt Peer-to-Peer oder über deinen eigenen Relay-Server, der private Schlüssel verlässt niemals dein Netz, und Lizenzkosten fallen für die OSS-Version vollständig weg. Diese Anleitung zeigt dir den gesamten Weg: von der Ordnerstruktur über das Container-Manager-Projekt bis zum ersten Client-Connect, mit Verifikation nach jedem Schritt.

Voraussetzungen

1. Synology NAS mit DSM 7.2 oder neuer und installiertem Container Manager (Package Center)
2. Statische LAN-IP oder DHCP-Reservierung für das NAS im Router
3. DDNS-Adresse (z. B. deinname.synology.me via DSM → Systemsteuerung → Externer Zugriff → DDNS) oder statische öffentliche IP
4. Portweiterleitung am Router: TCP 21115, 21116, 21117, 21118, 21119 und UDP 21116 auf die NAS-LAN-IP
5. RustDesk-Client (kostenlos, Windows/macOS/Linux/Android/iOS) auf den Endgeräten
6. Zugriff auf die Synology File Station zum Anlegen des Datenordners

Schritt 1: Eckdaten und Architekturüberblick

Bevor du mit der Einrichtung beginnst, hilft ein kurzer Überblick über die Komponenten. RustDesk Server OSS besteht aus genau zwei Diensten, die beide aus demselben Image starten – unterschieden nur durch den Container-Command-Parameter:

Wichtig: Port 21116 muss zwingend doppelt freigegeben werden – einmal als TCP, einmal als UDP. Fehlt das UDP-Mapping, schlägt NAT-Traversal lautlos fehl und Clients erhalten hohe Latenz durch erzwungenes Relay oder gar keine Verbindung.

Verifizieren: Du kannst diese Tabellen jederzeit als Referenz nutzen. Fahre fort, wenn du DDNS-Adresse und Router-Portweiterleitung bereits vorbereitet hast.

Schritt 2: Datenordner in der File Station anlegen

Beide Container – hbbs und hbbr – müssen dasselbe Hostverzeichnis mounten, damit sie das beim ersten Start automatisch generierte Ed25519-Schlüsselpaar teilen. Legst du getrennte Verzeichnisse an, generiert hbbr ein eigenes Schlüsselpaar und die Authentifizierung schlägt fehl.

1. Öffne in DSM die File Station
2. Navigiere zu docker (Synology-Konvention: Kleinbuchstaben)
3. Erstelle den Ordner rustdesk, darin den Unterordner data
4. Vollständiger Pfad: /volume1/docker/rustdesk/data

Lege den Ordner unbedingt über die File Station an – nicht per SSH. Nur so erhält der Docker-Benutzer automatisch die korrekten Schreibrechte, ohne dass du manuelle chmod-Anpassungen vornehmen musst.

Verifizieren: In der File Station sollte der Pfad docker/rustdesk/data sichtbar sein (zunächst leer). Erst nach dem ersten Container-Start erscheinen dort die Schlüsseldateien.

Schritt 3: DSM-Firewall für die RustDesk-Ports öffnen

DSM verfügt über eine eigene Firewall, die unabhängig von der Router-Konfiguration greift. Auch wenn du die Ports am Router bereits weitergeleitet hast, müssen sie in DSM explizit freigegeben werden.

1. DSM → Systemsteuerung → Sicherheit → Firewall
2. Wähle das aktive Profil und klicke auf Regeln bearbeiten
3. Füge folgende eingehende Regeln hinzu:

Du kannst die TCP-Ports 21115–21119 als Bereich in einer Regel eintragen. Die UDP-Regel für 21116 muss als separate Regel angelegt werden, da DSM TCP und UDP getrennt behandelt.

Verifizieren: Überprüfe im Firewall-Regelwerk, dass beide Regeln (TCP-Bereich und UDP-21116) als „Erlauben“ aufgelistet sind und keine blockierende Regel dahinter steht. Speichere und wende die Änderungen an.

Schritt 4: Container-Manager-Projekt anlegen und compose.yaml einfügen

Der empfohlene Weg auf DSM 7.2 ist das Container-Manager-Projekt mit einer compose.yaml. Das ist nachvollziehbarer als einzelne Container via GUI und lässt sich später einfach versionieren oder auf einem anderen NAS reproduzieren.

1. Öffne den Container Manager in DSM
2. Klicke auf Projekt → Erstellen
3. Projektname: rustdesk
4. Pfad: /volume1/docker/rustdesk (bereits vorhanden)
5. Wähle „compose.yaml erstellen“ und füge folgenden Inhalt ein:

services:
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    ports:
      - "21117:21117"
      - "21119:21119"
    volumes:
      - /volume1/docker/rustdesk/data:/root
    networks:
      - rustdesk-net
    restart: unless-stopped

  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs -r DEIN-HOSTNAME.synology.me:21117
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21116:21116/udp"
      - "21118:21118"
    volumes:
      - /volume1/docker/rustdesk/data:/root
    networks:
      - rustdesk-net
    depends_on:
      - hbbr
    restart: unless-stopped

networks:
  rustdesk-net:
    driver: bridge

Ersetze DEIN-HOSTNAME.synology.me durch deine tatsächliche DDNS-Adresse oder öffentliche IP. Dieser Wert im hbbs-Command ist entscheidend: Er teilt den Clients mit, wo der Relay-Server erreichbar ist. Verwendest du localhost oder lässt den Parameter weg, erhalten Clients eine nicht erreichbare Relay-Adresse.

Hinweis zum Image-Tag: :latest entspricht aktuell Tag 1.1.15 (Stand Januar 2026). Der Container Manager aktualisiert :latest nicht automatisch – prüfe regelmäßig auf neue Releases und aktualisiere das Image manuell über „Image aktualisieren“ im Container Manager. Für maximale Stabilität kannst du alternativ den expliziten Tag :1.1.15 verwenden.

Optional: Wenn du in einer MSP-Umgebung alle Verbindungen über den Relay-Server erzwingen möchtest (kein direktes P2P), füge beim hbbs-Dienst die Umgebungsvariable hinzu:

    environment:
      - ALWAYS_USE_RELAY=Y

Klicke auf Weiter und starte das Projekt. Container Manager lädt das Image (ca. 5,6 MB) und startet beide Container.

Verifizieren: Im Container Manager → Projekt → rustdesk sollten beide Container (hbbs und hbbr) den Status „Laufen“ anzeigen. Falls hbbs mit einem Fehler stoppt, starte es erneut – es wartet auf hbbr (depends_on), aber Container Manager löst das beim manuellen Neustart korrekt auf.

Schritt 5: Schlüsselpaar prüfen und Public Key auslesen

Beim ersten Start generiert hbbs automatisch ein Ed25519-Schlüsselpaar im gemounteten Datenverzeichnis. Der private Schlüssel (id_ed25519) verbleibt ausschließlich auf deinem Server und darf niemals weitergegeben werden. Den öffentlichen Schlüssel (id_ed25519.pub) trägst du in jeden RustDesk-Client ein.

1. Öffne in DSM die File Station
2. Navigiere zu docker/rustdesk/data
3. Du solltest folgende Dateien sehen:

id_ed25519         ← privater Schlüssel (NIEMALS weitergeben)
id_ed25519.pub     ← öffentlicher Schlüssel (für Client-Konfiguration)
db_v2.sqlite3      ← Verbindungsdatenbank

1. Öffne id_ed25519.pub mit einem Texteditor (z. B. per Rechtsklick → „Mit Text-Editor öffnen“ in der File Station oder per SSH)
2. Kopiere den einzeiligen Inhalt exakt – ohne Leerzeichen oder Zeilenumbrüche am Anfang oder Ende

Der Inhalt sieht beispielsweise so aus:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=

Diese base64-kodierte Zeichenkette ist dein Key für die Client-Konfiguration. Ein falsch kopierter Key (mit Leerzeichen oder Zeilenumbruch) führt im Client zur Fehlermeldung „Wrong public key“.

Verifizieren: Alle drei Dateien (id_ed25519, id_ed25519.pub, db_v2.sqlite3) müssen im Verzeichnis vorhanden sein. Falls nur id_ed25519.pub fehlt oder das Verzeichnis leer ist, hat der Container keine Schreibrechte – lege den Ordner über die File Station neu an und starte die Container neu.

Schritt 6: RustDesk-Client konfigurieren und erste Verbindung testen

Jetzt richtest du den RustDesk-Client auf mindestens zwei Geräten ein – einem, das du fernwarten willst (Zielgerät), und einem, von dem du fernwartest (Techniker-Gerät). Beide müssen auf deinen Server zeigen.

1. Öffne den RustDesk-Client auf dem ersten Gerät
2. Klicke auf das Drei-Punkte-Menü oder Einstellungen → Netzwerk
3. Trage ein:

1. Bestätige mit OK – der Client verbindet sich zum hbbs-Server und erhält eine ID
2. Wiederhole die Konfiguration auf dem zweiten Gerät
3. Gib auf dem Techniker-Gerät die RustDesk-ID des Zielgeräts ein und klicke auf Verbinden

Beim ersten Verbindungsaufbau fragt das Zielgerät nach Zustimmung oder einem Passwort (je nach Client-Einstellung). Nach Bestätigung siehst du den Bildschirm des Zielgeräts – die Verbindung läuft über deinen eigenen Server.

Verifizieren: Prüfe im RustDesk-Client oben links – erscheint eine numerische ID (z. B. 123 456 789), ist der Client erfolgreich mit deinem hbbs-Server verbunden. Zeigt der Client dauerhaft „Nicht bereit“ oder „Server nicht erreichbar“, prüfe die Firewall-Regeln und die Router-Portweiterleitung. Zum Testen der Relay-Erreichbarkeit kannst du vom Client-Rechner aus den TCP-Port prüfen:

# Windows PowerShell
Test-NetConnection -ComputerName DEIN-HOSTNAME.synology.me -Port 21117

# Linux / macOS
nc -zv DEIN-HOSTNAME.synology.me 21117

Erwartete Ausgabe: TcpTestSucceeded : True (PowerShell) bzw. Connection to … succeeded! (nc). Schlägt der Test fehl, ist Port 21117 entweder am Router nicht weitergeleitet oder von der DSM-Firewall blockiert.

Troubleshooting / Typische Fehler

1. Port 21116 UDP fehlt: Der häufigste Fehler. NAT-Traversal schlägt lautlos fehl – Clients melden „Verbindung nicht möglich“ oder haben hohe Latenz. Lösung: In DSM-Firewall und Router eine separate UDP-Regel für Port 21116 anlegen. Nur TCP reicht nicht.
2. Getrennte Volume-Verzeichnisse für hbbs und hbbr: Wenn beide Container unterschiedliche Host-Pfade mounten, generiert jeder ein eigenes Schlüsselpaar. hbbr kennt den Schlüssel von hbbs nicht – der Client meldet Authentifizierungsfehler. Lösung: Beide Container müssen auf /volume1/docker/rustdesk/data:/root zeigen.
3. Falscher oder fehlender -r-Parameter in hbbs: Fehlt -r HOSTNAME:21117 im hbbs-Command oder wird localhost verwendet, teilt hbbs den Clients eine nicht erreichbare Relay-Adresse mit. Verbindungen über Relay schlagen fehl. Lösung: compose.yaml korrigieren, Container neu starten.
4. „Wrong public key“ im Client: Der Inhalt von id_ed25519.pub wurde mit Leerzeichen oder Zeilenumbruch kopiert. Lösung: Datei erneut im Texteditor öffnen, den einzeiligen Inhalt ohne umgebende Whitespace-Zeichen kopieren.
5. DSM-Firewall vergessen: Router-Portweiterleitung allein genügt nicht. DSM hat eine eigene Firewall (Systemsteuerung → Sicherheit → Firewall), die alle Ports separat freigeben muss.
6. hbbs startet vor hbbr: Ohne depends_on: hbbr kann hbbs die Relay-Registrierung beim Start verpassen. Das Compose-File enthält den Eintrag bereits; prüfe, ob er vorhanden ist, falls du die Konfiguration manuell angepasst hast.
7. Ordner per SSH angelegt – keine Schreibrechte: Per SSH angelegte Ordner gehören dem SSH-Benutzer, nicht dem Docker-Benutzer. Immer über die File Station anlegen oder Rechte manuell anpassen.
8. Image-Tag :latest wird nicht aktualisiert: Container Manager lädt :latest beim NAS-Neustart nicht neu. Nach neuen RustDesk-Releases manuell „Image aktualisieren“ im Container Manager ausführen oder expliziten Tag :1.1.15 verwenden.

Häufige Fragen

Kann ein einziger RustDesk-Server mehrere Kunden oder Techniker bedienen?

Ja. Ein hbbs/hbbr-Server kann beliebig viele Clients gleichzeitig bedienen. Die OSS-Version hat keine eingebaute Benutzerverwaltung oder Mandantentrennung. Für IT-Dienstleister, die verschiedene Kunden strikt trennen wollen, empfiehlt sich eine separate RustDesk-Instanz pro Mandant – das geht mit minimalem Aufwand, da das Image nur ca. 5,6 MB groß ist. Für einfache Szenarien (ein Team, ein Kundenstamm) reicht eine Instanz vollkommen.

Was ist der Unterschied zwischen RustDesk Server OSS und der Pro-Version?

Die OSS-Version (kostenlos, Open Source) bietet vollständige Fernwartungsfunktionalität ohne Benutzerverwaltung – ideal für Teams bis ca. 50 Geräte. Die kostenpflichtige Pro-Version ergänzt eine Web-Konsole, zentrale Benutzerverwaltung, Lizenzmanagement und erweitertes Logging. Für den typischen KMU-/MSP-Grundbedarf genügt OSS vollständig.

Kann ich RustDesk mit WireGuard oder Headscale kombinieren?

Ja, und das ist besonders empfehlenswert für MSP-Umgebungen. Wenn alle Endgeräte im selben VPN-Tunnel erreichbar sind, kann der RustDesk-Server intern adressiert werden – Ports müssen dann nicht nach außen geöffnet werden. Das erhöht die Sicherheit erheblich. Passende Anleitungen: WireGuard-VPN für Homeoffice und Standortvernetzung einrichten und Headscale selbst hosten: Tailscale-Mesh-VPN ohne Cloud-Abhängigkeit für KMU.

Was passiert, wenn der RustDesk-Server offline geht?

Bereits über Relay laufende Sessions brechen ab. Direkte P2P-Verbindungen (ohne ALWAYS_USE_RELAY=Y) bleiben bestehen, solange beide Peers online sind. Neue Verbindungsversuche schlagen fehl, bis der Server wieder erreichbar ist. Dank restart: unless-stopped in der compose.yaml startet der Container nach einem NAS-Neustart automatisch neu.

Wie verifiziere ich, dass der Server korrekt läuft?

Vier Checks: (1) Container Manager zeigt beide Container als „Laufen“. (2) Im Verzeichnis /volume1/docker/rustdesk/data existieren id_ed25519, id_ed25519.pub und db_v2.sqlite3. (3) Ein korrekt konfigurierter RustDesk-Client erhält eine numerische ID. (4) TCP-Port 21117 ist von extern erreichbar (Test mit nc oder Test-NetConnection).

Brauche ich eine feste öffentliche IP?

Nein. Eine DDNS-Adresse reicht vollkommen aus. Synology bietet über DSM → Systemsteuerung → Externer Zugriff → DDNS den kostenlosen Dienst synology.me an. Stelle sicher, dass die DDNS-Adresse bereits aufgelöst wird, bevor du die Container das erste Mal startest – sonst bekommen Clients beim späteren Start eine korrekte Relay-Adresse erst nach einem Container-Neustart.

Fazit

RustDesk Server OSS auf dem Synology NAS ist eine der saubersten Self-Hosting-Lösungen für Fernwartung: Zwei Container, ein gemeinsames Datenverzeichnis, ein Public Key – fertig. Die Einrichtung dauert keine 30 Minuten, die laufenden Kosten beschränken sich auf den Strom für das NAS. Für IT-Dienstleister und KMU-Admins, die TeamViewer oder AnyDesk ablösen wollen, ohne auf Komfort zu verzichten, ist das der pragmatischste Weg. Der einzige Pflege-Aufwand: gelegentlich das Image manuell aktualisieren und die Portfreigaben im Blick behalten. Wer die Sicherheit noch weiter erhöhen will, kombiniert RustDesk mit einem eigenen Mesh-VPN – dann müssen keine Ports nach außen geöffnet werden.

Für browserbasierte Fernzugriffslösungen ohne Client-Installation (RDP, SSH, VNC direkt im Browser) lohnt sich ein Blick auf Apache Guacamole auf dem Synology NAS installieren: RDP, SSH und VNC im Browser.

Weiterführende Anleitungen und Quellen

1. WireGuard-VPN für Homeoffice und Standortvernetzung einrichten – VPN-Tunnel als sicheres Fundament für interne RustDesk-Verbindungen ohne offene Ports
2. Headscale selbst hosten: Tailscale-Mesh-VPN ohne Cloud-Abhängigkeit für KMU – Mesh-VPN für MSP-Umgebungen ohne öffentliche Portfreigaben
3. Apache Guacamole auf dem Synology NAS: RDP, SSH und VNC im Browser – browserbasierte Fernzugriffs-Alternative ohne Client-Installation
4. Nginx Proxy Manager auf der Synology mit Container Manager einrichten – Reverse Proxy und SSL für weitere Container-Dienste

Quellen: Diese Anleitung basiert auf der offiziellen RustDesk-Server-Dokumentation (GitHub-Repository, docker-compose.yml), der Docker-Hub-Image-Seite und der DeepWiki-Dokumentationsspiegelung. Die Mariushosting-Referenz diente als Praxis-Orientierung für den Synology-spezifischen Ablauf; alle technischen Details wurden gegen die offizielle Dokumentation verifiziert – insbesondere das gemeinsame Volume für beide Container (statt getrennter Verzeichnisse) und das zwingend erforderliche doppelte UDP-Mapping für Port 21116.