Selbstgehosteter Fernzugriff: Warum, Wie und Was Schiefgeht

„Selbstgehosteter Fernzugriff“ bedeutet in der Regel eines von zwei Dingen: Hosting Ihrer eigenen Relay-/Rendezvous-Infrastruktur für ein Tool wie RustDesk oder das Hosting einer kompletten webbasierten Fernzugriffsplattform wie Apache Guacamole oder MeshCentral. Beide Ansätze sind legitim; sie haben unterschiedliche Vor- und Nachteile. Dieser Artikel erläutert, warum Sie selbst hosten könnten, die drei ernsthaften Tools in diesem Bereich, wie der operative Aufwand tatsächlich aussieht und wann selbstgehostet besser ist als die Nutzung eines Managed-Dienstes.

Zusammenfassung: Selbsthosten, wenn Sie strenge Anforderungen an die Datenhoheit haben (GDPR, regulierte Branchen, interne Deployments), wenn Sie null laufende Lizenzkosten im größeren Maßstab wünschen oder wenn Sie es vorziehen, Ihre eigene Infrastruktur zu betreiben. Verzichten Sie auf das Selbsthosten, wenn Sie ein kleines Team ohne dedizierte DevOps sind, wenn Sie beschaffungsfertige Zertifizierungen benötigen oder wenn Sie lieber $7.99/Monat bezahlen, um das Problem zu lösen.

Warum selbst hosten?

Datenhoheit

Der wichtigste Grund, warum Organisationen selbst hosten. Wenn Sie der GDPR, HIPAA oder branchenspezifischen Vorschriften (deutsche Banken, französische Regierung, Verteidigungsauftragnehmer) unterliegen, könnte das Routing von Fernzugriffssitzungen über ein SaaS eines Dritten – selbst eines mit starker Verschlüsselung – Ihre Prüfer nicht zufriedenstellen. Das Selbsthosting auf Infrastruktur, die Sie besitzen (oder in einer Region mieten, die Sie kontrollieren), beseitigt die Abhängigkeit von Dritten vollständig. Auch wenn unser verwaltetes Relay nur Chiffretext sieht, ist die Aussage „das Relay sieht nichts, weil wir das Relay betreiben“ eine stärkere Compliance-Position.

Interne Deployments

Wenn Ihr Fernzugriffstraffic Ihr Netzwerk niemals verlassen sollte – sagen wir, ein industrielles Kontrollsystem, das vom Internet getrennt ist, oder ein Krankenhaus-LAN mit striktem Ausgangsfilter – ist ein verwalteter Cloud-Dienst strukturell die falsche Wahl. Sie möchten ein Relay, das in Ihrem LAN lebt und nur von Ihren autorisierten Geräten zugänglich ist.

Kosten im größeren Maßstab

Für sehr große Deployments (1000+ Endpunkte) summiert sich die Preisgestaltung pro Sitzplatz. Ein selbstgehostetes Relay, das auf einem VPS für $40/Monat läuft, kann Tausende von gleichzeitigen Sitzungen bedienen, wenn Ihre Bandbreite dies zulässt. Der Break-even-Punkt im Vergleich zur verwalteten Preisgestaltung hängt vom Tool ab, aber im MSP- und Unternehmensmaßstab gewinnt das Selbsthosting in Bezug auf die reinen Kosten.

Anpassung und Kontrolle

Das Selbsthosting ermöglicht es Ihnen, den Quellcode zu ändern (unter den Verpflichtungen der AGPL-3.0), das Branding anzupassen, ohne für die White-Label-Stufe zu bezahlen, und das Verhalten des Relays an Ihre spezifische Netzwerk-Topologie anzupassen.

Die akzeptierten Vor- und Nachteile

Selbsthosting ist nicht umsonst. Die Kosten entstehen durch den DevOps-Overhead, nicht in Dollar pro Monat. Konkret:

• Serverbereitstellung und -wartung: Sie benötigen einen Linux-Server mit einer öffentlichen IP (für die Erreichbarkeit des Relays), Monitoring, Protokollrotation, Betriebssystem-Patching und wahrscheinlich Backup-Infrastruktur. Planen Sie 2-4 Stunden/Monat für die Wartung im Normalbetrieb ein, mehr während Vorfällen.
• NAT- und Firewall-Konfiguration: Das Relay muss über das Internet auf bestimmten Ports (21115-21119 für RustDesk's Standardkonfiguration) erreichbar sein. Wenn Sie in einem NAT-Netzwerk arbeiten, benötigen Sie Portweiterleitung von Ihrem Edge- zu dem Relay-Host.
• Zertifikatsverwaltung: Wenn Sie TLS für die Verwaltungsoberfläche möchten (was Sie sollten), benötigen Sie Let's Encrypt certbot oder ähnliches. Erneuerungen alle 60-90 Tage, automatisiert über Cron.
• Kapazitätsplanung: Ein einzelnes Relay kann eine Menge Traffic bewältigen, aber irgendwann benötigen Sie ein zweites, dann Lastenausgleich. Sie sind jetzt ein Infrastrukturteam.
• Kein Support des Anbieters: Wenn um 2 Uhr morgens etwas kaputtgeht, gibt es keine Support-Hotline. Sie debuggen selbst oder warten darauf, dass die Community aufwacht.

Die drei ernsthaften Tools

RustDesk (und Forks wie GoDesk)

Architektonisch am einfachsten von den dreien. Zwei Binaries: hbbs (Rendezvous-Server, ~30 MB RAM) und hbbr (Relay, ~50 MB RAM). Beide sind statische Rust-Binaries ohne externe Abhängigkeiten. Die Einrichtung ist ungefähr wie folgt:

# Auf einem Linux-VPS mit einer öffentlichen IP
wget https://github.com/rustdesk/rustdesk-server/releases/latest/download/rustdesk-server-linux-amd64.zip
unzip rustdesk-server-linux-amd64.zip

# Starten Sie hbbs (Rendezvous) und hbbr (Relay) als Dienste
sudo ./hbbs -r your.public.ip
sudo ./hbbr

# Öffnen Sie die Ports 21115/tcp, 21116/tcp+udp, 21117/tcp, 21118/tcp, 21119/tcp
sudo ufw allow 21115:21119/tcp
sudo ufw allow 21116/udp

# Clients auf Ihren Server verweisen: in den Client-Einstellungen,
# ID-Server = your.public.ip, Relay-Server = your.public.ip,
# Öffentlicher Schlüssel = (von hbbs beim ersten Start gedruckt, oder prüfen Sie id_ed25519.pub)

Der Ressourcenbedarf ist gering – ein $5/Monat DigitalOcean-Droplet bewältigt Dutzende gleichzeitiger Sitzungen. Der offizielle RustDesk Pro-Server (kostenpflichtig) fügt eine Web-Admin-Konsole, Protokolle, LDAP/OIDC und brokerähnliche Funktionen für größere Deployments hinzu.

Apache Guacamole

Andere Architektur: Guacamole ist eine clientlose HTML5-Webanwendung. Benutzer verbinden sich über einen Browser; Guacamoles Backend (guacd) übersetzt RDP, VNC und SSH in HTML5-Canvas/WebSocket-Streams. Es gibt keinen nativen Client, der auf der Benutzerseite installiert werden muss, was für Support-Workflows nützlich ist, bei denen Sie keine Software auf dem steuernden Gerät installieren können.

Die betriebliche Komplexität ist höher als bei RustDesk: Guacamole läuft als Java + Tomcat mit einer Datenbank (MySQL oder Postgres) für die Benutzer-/Verbindungsverwaltung, plus dem Daemon guacd. Die Docker-Compose-Setup vereinfacht dies erheblich, aber Sie betreiben 3-4 Container anstelle von 2 Binaries.

Guacamole ist die richtige Wahl, wenn Sie speziell browserbasierten Zugriff ohne Client-Software wünschen. Es ist die falsche Wahl, wenn Sie ein Tool möchten, das NAT-Traversal zwischen zwei Endpunkten sofort unterstützt – Guacamole geht davon aus, dass Sie die Zielmaschine bereits über RDP/VNC/SSH vom Guacamole-Server aus erreichen können.

MeshCentral

MeshCentral ist eine auf Node.js basierende Remote-Management-Plattform von Ylian Saint-Hilaire (früher bei Intel). Sie unterstützt Fernzugriff, Dateiübertragung, Terminal, Webkonsole und ein UI für das Flottenmanagement. Architektonisch handelt es sich um eine einzelne Node-App + Datenbank (NeDB standardmäßig, Postgres optional), die über HTTPS erreichbar ist.

MeshCentral ist mehr ein Flottenmanagement-Tool als ein reines Fernzugriffsrelay – denken Sie an RustDesk + ein Geräteinventar + ein Web-Admin-UI. Die Einrichtung ist unkompliziert (ein einzelnes npm install + Konfigurationsdatei), und es wurde in der Produktion von einigen größeren Organisationen, einschließlich Intel, eingesetzt.

Wo MeshCentral Schwächen hat: die Benutzeroberfläche ist dicht und nicht besonders ausgereift, mobile Clients sind schwächer als die von RustDesk, und der Codec/Leistung für Desktop-Streaming ist nicht so optimiert wie bei RustDesk oder AnyDesk. Es ist am besten geeignet, wenn Sie ein einheitliches Web-Admin-UI für eine Flotte wünschen, weniger ideal als ein spezialisiertes Fernzugriffs-Tool.

Wie ein selbstgehostetes RustDesk-Relay tatsächlich aussieht

Schritt-für-Schritt auf einem Hetzner CX11 ($4/Monat) Ubuntu 24.04 VPS:

1. Provisionieren Sie den VPS mit einer öffentlichen IPv4. Stellen Sie ein sicheres Root-Passwort ein und aktivieren Sie die SSH-Schlüssel-Authentifizierung.
2. Öffnen Sie die Firewall:

   sudo ufw allow OpenSSH
   sudo ufw allow 21115:21119/tcp
   sudo ufw allow 21116/udp
   sudo ufw enable

3. Installieren Sie die RustDesk-Server-Binaries von der GitHub-Releases-Seite. Legen Sie sie unter /opt/rustdesk-server/ ab.
4. Erstellen Sie systemd-Einheiten für hbbs und hbbr, damit sie beim Neustart neu starten. Das RustDesk-Wiki hat Referenzeinheiten; wir behalten eine bekannte gute Kopie in unserem Hilfecenter.
5. Erhalten Sie den öffentlichen Schlüssel, der beim ersten Boot von hbbs ausgedruckt wird. Verteilen Sie ihn an Ihre Clients zusammen mit dem Server-Hostnamen.
6. Konfigurieren Sie die Clients: in den GoDesk-Client-Einstellungen die ID-Server, Relay-Server und den öffentlichen Schlüssel einstellen. Der Client verwendet jetzt Ihr Relay anstelle unseres.
7. Optional: TLS-Terminierung über Caddy, wenn Sie eine Web-Admin-Konsole (RustDesk Pro) auf 443 mit automatisch erneuerbaren Let's Encrypt-Zertifikaten bereitstellen möchten.

Gesamtzeit auf einem frischen VPS: etwa 30 Minuten beim ersten Mal, 10 Minuten, wenn Sie es schon einmal gemacht haben. Laufende Wartung: apt update && apt upgrade wöchentlich, Relay-Protokolle überwachen, neu starten, wenn Speicherlecks auftreten (selten). Für spezifische Linux-Deployments siehe unsere Linux-Plattformseite.

Die Position von GoDesk zum Selbsthosting

Wir ermöglichen Ihnen das Selbsthosting des Relays auch auf den kostenpflichtigen Ebenen – wenn Sie möchten. Der Client der Pro-Ebene ist standardmäßig so konfiguriert, dass er mit unserem verwalteten Relay kommuniziert, aber Sie können es jederzeit in den Einstellungen auf Ihr eigenes Relay umschalten. Es gibt kein „Enterprise On-Prem Add-On“-Tor. Dies ist absichtlich so: Die AGPL-3.0-Lizenz gibt Ihnen das Recht zu selbst hosten, und wir möchten das beibehalten.

Die meisten Benutzer machen sich nicht die Mühe. Unser verwaltetes Relay funktioniert einfach, hat globale PoPs und ist in dem Basisabonnement enthalten. Wenn Ihre Erzählung zur Datenhoheit „kein drittes Relay irgendwo im Verlauf“ erfordert, hosten Sie selbst. Andernfalls sparen Sie sich die DevOps-Zeit und nutzen das verwaltete Relay – dafür zahlen Sie mit dem Abonnement. Für die vollständige Sicherheitsarchitektur, die entweder Deployment zugrunde liegt, siehe unsere Sicherheitsseite.

Wann das Selbsthosting die falsche Entscheidung ist

• Sie sind ein kleines Team ohne DevOps-Kapazität. Der Wartungsaufwand ist real. Wenn Sie niemanden haben, dessen Stellenbeschreibung „Linux-Server-Patches“ umfasst, ist das Selbsthosting eine wiederkehrende Steuer.
• Sie benötigen beschaffungsbezogene Papiere des Anbieters. Prüfer, die SOC 2-Berichte anfordern, werden „wir betreiben unseren eigenen Server“ nicht als Antwort akzeptieren. Verwaltete Dienste mit formalen Zertifizierungen sind hier einfacher.
• Sie haben nur 5-20 Endpunkte. Der Break-even beim Selbsthosting im Vergleich zu einem verwalteten Plan für $7.99/Monat sind Hunderte von Dollar/Jahr an eingesparter DevOps-Zeit. Bei 20 Endpunkten ist das verwaltete eindeutig günstiger.
• Sie tun dies für die Kosteneinsparungen bei einem einzigen Platz. Ein $5/Monat VPS plus 2 Stunden/Monat an Verwaltungszeit zu jedem angemessenen Stundensatz kostet bereits mehr als ein einzelner Platz im verwalteten Service.

Fazit

Der selbstgehostete Fernzugriff ist eine echte Option, und für einige Organisationen ist es die richtige Wahl. RustDesk (und Forks wie GoDesk) ist die einfachste ernsthafte Selbsthosting-Geschichte; Guacamole ist die richtige Wahl für browserbasierten Zugriff; MeshCentral ist der Generalist für Flottenmanagement. Der Kompromiss ist immer DevOps-Zeit gegen Kosten. Wenn Sie Anforderungen an die Datenhoheit haben, hosten Sie selbst. Wenn Sie $7.99/Monat haben und lieber Produkte als Betrieb aufbauen möchten, verwenden Sie das verwaltete Relay. Preise ansehen oder GoDesk herunterladen und zuerst den verwalteten Flow ausprobieren – Sie können jederzeit später durch Ändern einer Konfigurationszeile auf selbstgehostet migrieren.

FAQ

Kann ich das Relay selbst hosten und dennoch die GoDesk-Client-UI / Konten nutzen?
Ja. Weisen Sie den Client in den Einstellungen auf Ihr Relay. Konto-Funktionen, die vom GoDesk-Steuerungssystem abhängen (Abrechnung, Teamverwaltung), funktionieren weiterhin; nur der Sitzungstraffic wird über Ihr Relay geleitet.

Welche Hardware benötige ich für ein selbstgehostetes RustDesk-Relay?
Ein kleines VPS: 1 vCPU, 1 GB RAM, 1 TB/Monat Bandbreite bewältigt Dutzende gleichzeitiger Sitzungen. Hetzner CX11, DigitalOcean Basic oder AWS t4g.nano funktionieren alle. Bandbreite ist im größeren Maßstab normalerweise die Einschränkung, nicht die CPU.

Unterstützt das selbstgehostete RustDesk 2FA / SSO?
Der kostenlose Open-Source-Server (hbbs/hbbr) tut dies nicht. Der RustDesk Pro-Server (kostenpflichtig, separate Lizenz) fügt Webkonsole, OIDC und Protokolle hinzu. Die Pro-Ebene von GoDesk im verwalteten Dienst beinhaltet 2FA standardmäßig.

Kann ich das Relay auf AWS Lightsail / Cloudflare / usw. hosten?
Jeder Anbieter mit einer öffentlichen IPv4 und der Fähigkeit, benutzerdefinierte UDP/TCP-Ports zu öffnen, funktioniert. Cloudflares Standardproxy terminiert TCP nur am Port 443; Sie bräuchten Cloudflare Spectrum (kostenpflichtig) oder einen dedizierten TCP-Listener für die RustDesk-Ports.

Wie interagiert das Selbsthosting mit der GDPR?
Wenn sich Ihr Relay in der EU befindet und Ihre Daten es niemals verlassen, gelten die Regeln für die grenzüberschreitende Übertragung gemäß der GDPR nicht. Dies ist der größte Grund, warum öffentliche Einrichtungen und Gesundheitsdienstleister in der EU das Selbsthosting wählen.