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

TeamViewer und AnyDesk werden pro Techniker lizenziert, routen Verbindungen über Fremdserver und lassen sich kaum an eigene Sicherheitsanforderungen anpassen. RustDesk Server OSS ist die Open-Source-Alternative: eine Relay-Infrastruktur auf Ihrem eigenen Synology NAS. Verbindungen laufen direkt Peer-to-Peer oder über Ihren Relay-Server, der private Schlüssel verlässt Ihr Netz nicht, Lizenzkosten fallen für die OSS-Version nicht an. Diese Anleitung führt von der Ordnerstruktur über das Container-Manager-Projekt bis zum ersten Client-Connect.

Voraussetzungen

1. Synology NAS mit DSM 7.2 oder neuer und Container Manager (Package Center); Intel/AMD (amd64) oder ARM (arm64/armv7). 2 CPU-Kerne und 1 GB RAM reichen; die Last hängt vor allem von der Upload-Bandbreite ab, wenn viele Sitzungen über das Relay laufen.
2. Statische LAN-IP oder DHCP-Reservierung für das NAS im Router
3. DDNS-Adresse (z. B. ihrname.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

RustDesk Server OSS besteht aus zwei Diensten aus demselben Image, unterschieden nur durch den Container-Command:

Wichtig: Port 21116 muss als TCP und UDP freigegeben werden. Fehlt UDP, schlägt NAT-Traversal lautlos fehl: hohe Latenz durch erzwungenes Relay oder gar keine Verbindung.

Verifizieren: nslookup IHR-HOSTNAME.synology.me liefert Ihre aktuelle öffentliche IP, und im Router stehen die Weiterleitungen TCP 21115 bis 21119 und UDP 21116 auf die LAN-IP des NAS.

Schritt 2: Datenordner in der File Station anlegen

hbbs und hbbr müssen dasselbe Hostverzeichnis mounten, um das beim ersten Start erzeugte Ed25519-Schlüsselpaar zu teilen. Bei getrennten Verzeichnissen erzeugt hbbr ein eigenes Paar und die Authentifizierung schlägt fehl.

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

Legen Sie den Ordner über die File Station an, nicht per SSH: Nur so erhält der Docker-Benutzer ohne chmod die Schreibrechte.

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 hat eine eigene Firewall: Auch weitergeleitete Router-Ports müssen dort explizit freigegeben werden.

1. DSM → Systemsteuerung → Sicherheit → Firewall
2. Wählen Sie das aktive Profil und klicken Sie auf Regeln bearbeiten
3. Fügen Sie folgende eingehende Regeln hinzu:

TCP 21115–21119 können Sie als Bereich in einer Regel eintragen; UDP 21116 braucht eine separate Regel.

Speichern Sie und wenden Sie die Änderungen an.

Verifizieren: Im Firewall-Regelwerk stehen beide Regeln (TCP-Bereich und UDP 21116) als „Erlauben“, und keine blockierende Regel steht davor.

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

Empfohlen ist unter DSM 7.2 ein Container-Manager-Projekt mit compose.yaml; es lässt sich versionieren und auf einem anderen NAS reproduzieren.

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

services:
  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:1.1.16
    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:1.1.16
    command: hbbs -r IHR-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

Ersetzen Sie IHR-HOSTNAME.synology.me durch Ihre DDNS-Adresse oder öffentliche IP. Dieser Wert im hbbs-Command teilt den Clients die Relay-Adresse mit; mit localhost oder ohne Parameter ist sie nicht erreichbar.

Hinweis zum Image-Tag: Der feste Tag 1.1.16 (Stand Juli 2026, behebt u. a. eine Missbrauchsmöglichkeit per UDP-Punch-Hole für Reflection-Angriffe) sorgt dafür, dass Updates nur bewusst laufen. Prüfen Sie regelmäßig die Releases auf GitHub, tragen Sie die neue Version ein und erstellen Sie das Projekt neu.

Optional: Um in einer MSP-Umgebung alle Verbindungen über das Relay zu erzwingen (kein direktes P2P), ergänzen Sie beim hbbs-Dienst:

    environment:
      - ALWAYS_USE_RELAY=Y

Klicken Sie auf Weiter und starten Sie 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, starten Sie 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 erzeugt hbbs ein Ed25519-Schlüsselpaar im Datenverzeichnis. Der private Schlüssel (id_ed25519) bleibt auf dem Server und wird nie weitergegeben. Den öffentlichen Schlüssel (id_ed25519.pub) tragen Sie in jeden RustDesk-Client ein.

1. Öffnen Sie in DSM die File Station
2. Navigieren Sie zu docker/rustdesk/data
3. Dort sollten folgende Dateien liegen:

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

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

Der Inhalt sieht beispielsweise so aus:

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=

Diese base64-Zeichenkette ist der Key für die Clients. Mit Leerzeichen oder Zeilenumbruch kopiert, meldet der Client „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 – legen Sie den Ordner über die File Station neu an und starten Sie die Container neu.

Schritt 6: RustDesk-Client konfigurieren und erste Verbindung testen

Richten Sie den RustDesk-Client auf mindestens zwei Geräten ein, dem Zielgerät und dem Techniker-Gerät; beide zeigen auf Ihren Server.

1. Öffnen Sie den RustDesk-Client auf dem ersten Gerät
2. Klicken Sie auf das Drei-Punkte-Menü oder Einstellungen → Netzwerk
3. Tragen Sie ein:

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

Beim ersten Verbindungsaufbau fragt das Zielgerät nach Zustimmung oder Passwort (je nach Client-Einstellung). Danach sehen Sie den Bildschirm des Zielgeräts.

Zeigt der Client dauerhaft „Nicht bereit“ oder „Server nicht erreichbar“, prüfen Sie Firewall-Regeln und Portweiterleitung. Den Relay-Port testen Sie vom Client aus:

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

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

Verifizieren: Im RustDesk-Client erscheint oben links eine numerische ID (z. B. 123 456 789) und der Status „Bereit“. Der Porttest liefert 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 (siehe Schritt 1). Lösung: In DSM-Firewall und Router eine separate UDP-Regel für 21116 anlegen.
2. Getrennte Volume-Verzeichnisse für hbbs und hbbr: Jeder Container erzeugt ein eigenes Schlüsselpaar, der Client meldet Authentifizierungsfehler. Lösung: Beide auf /volume1/docker/rustdesk/data:/root zeigen lassen.
3. Falscher oder fehlender -r-Parameter in hbbs: Ohne -r HOSTNAME:21117 oder mit localhost erhalten Clients eine unerreichbare Relay-Adresse. Lösung: compose.yaml korrigieren, Container neu starten.
4. „Wrong public key“ im Client: Key mit Leerzeichen oder Zeilenumbruch kopiert. Lösung: einzeiligen Inhalt von id_ed25519.pub ohne Whitespace erneut kopieren.
5. DSM-Firewall vergessen: Die Router-Portweiterleitung allein genügt nicht; Ports in Systemsteuerung → Sicherheit → Firewall freigeben.
6. hbbs startet vor hbbr: Ohne depends_on: hbbr kann hbbs die Relay-Registrierung verpassen. Bei manuell angepasster Konfiguration prüfen, ob der Eintrag vorhanden ist.
7. Ordner per SSH angelegt – keine Schreibrechte: Der Ordner gehört dem SSH-Benutzer, nicht dem Docker-Benutzer. Über die File Station anlegen oder Rechte anpassen.
8. Veraltete Server-Version: Container Manager aktualisiert Images nicht selbst, auch :latest nicht beim NAS-Neustart. Nach neuen RustDesk-Releases den Tag in der compose.yaml anheben (aktuell 1.1.16) und das Projekt neu erstellen.

Häufige Fragen

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

Ja, ein hbbs/hbbr-Server bedient beliebig viele Clients. Die OSS-Version hat keine Benutzerverwaltung oder Mandantentrennung; für strikt getrennte Kunden empfiehlt sich je Mandant eine eigene Instanz (Image nur ca. 5,6 MB). Für ein Team mit einem Kundenstamm reicht eine Instanz.

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

OSS (kostenlos, Open Source) bietet volle Fernwartung ohne Benutzerverwaltung, geeignet für Teams bis ca. 50 Geräte. Pro ergänzt Web-Konsole, zentrale Benutzerverwaltung, Lizenzmanagement und erweitertes Logging. Für den typischen KMU-/MSP-Bedarf genügt OSS.

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?

Über Relay laufende Sessions brechen ab. Direkte P2P-Verbindungen (ohne ALWAYS_USE_RELAY=Y) bleiben bestehen, solange beide Peers online sind; neue Verbindungen scheitern bis zur Rückkehr des Servers. Dank restart: unless-stopped starten die Container nach einem NAS-Neustart automatisch.

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, etwa der kostenlose Dienst synology.me (DSM → Systemsteuerung → Externer Zugriff → DDNS). Die Adresse sollte vor dem ersten Container-Start auflösen, sonst erhalten Clients die korrekte Relay-Adresse erst nach einem Neustart.

Fazit

Zwei Container, ein gemeinsames Datenverzeichnis, ein Public Key: Die Einrichtung dauert unter 30 Minuten, laufende Kosten beschränken sich auf den Strom des NAS. Pflege heißt: Image-Tag bewusst aktualisieren und Portfreigaben im Blick behalten. Mehr Sicherheit bringt ein eigenes Mesh-VPN, dann müssen keine Ports nach außen offen sein.

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.