rustdesk
12 KiB
publishDate, lang, translationKey, draft, title, excerpt, image, category, tags, author, slug, faq, metadata
| publishDate | lang | translationKey | draft | title | excerpt | image | category | tags | author | slug | faq | metadata | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-07-09T18:44:00Z | de | rustdesk-vs-vnc | false | RustDesk vs. VNC: NAT-Traversal, Codecs, Verschlüsselung | RustDesk vs. VNC im Praxisvergleich: NAT-Traversal ohne Portweiterleitung, moderne Codecs, integrierte Verschlüsselung und warum Teams von VNC zu RustDesk wechseln. | ~/assets/images/blog/rustdesk-vs-vnc-og.png | Vergleiche |
|
RustDesk Team | rustdesk-vs-vnc-nat-traversal-codecs-verschlusselung |
|
|
VNC ist eine der ältesten und am weitesten verbreiteten Methoden, um einen anderen Computer fernzusteuern. Es handelt sich um einen echten offenen Standard, der nahezu überall läuft, und im LAN ist er in puncto Einfachheit kaum zu schlagen. RustDesk verfolgt dieselbe Kernaufgabe, wurde jedoch für eine Welt aus NAT, Firewalls und gemischten Betriebssystemen entwickelt. Die Unterschiede liegen letztlich darin, wie sich beide über ein Netzwerk hinweg bewegen – und wie viel man nachrüsten muss, um sie sicher zu machen.
Dieser Vergleich stützt sich auf dauerhafte, überprüfbare Fakten statt auf Benchmarks, die von Ihrer Hardware und Verbindung abhängen.
Was VNC eigentlich ist
„VNC“ ist nicht ein einzelnes Programm, sondern eine ganze Familie von Implementierungen – RealVNC, TightVNC, TigerVNC, UltraVNC und weitere –, die das RFB-Protokoll (Remote Framebuffer) sprechen (Wikipedia). RFB ist im Kern pixelbasiert: Der Server sendet Framebuffer-Updates an den Viewer. Dieses Design ist wunderbar einfach und portabel, und genau deshalb läuft VNC auf so ziemlich allem, vom Enterprise-Server bis zum Raspberry Pi.
Die Lizenzierung ist uneinheitlich. TigerVNC wird unter der GNU GPL vertrieben und TightVNC ist ein community-getriebener offener Fork, während der Viewer von RealVNC ein proprietäres, kommerziell gepflegtes Produkt ist. „VNC ist Open Source“ trifft also nur auf manche Implementierungen zu, nicht auf alle.
Was RustDesk ist
RustDesk ist eine einzige Open-Source-Anwendung (AGPL) mit einer eigenen Architektur. Clients bauen ausgehende Verbindungen zu einem ID-/Rendezvous-Server auf, der eine Peer-to-Peer- oder relaisvermittelte Sitzung vermittelt. Laut der RustDesk-Dokumentation ist der Datenverkehr Ende-zu-Ende-verschlüsselt (auf Basis von NaCl), und für Video kommen moderne Codecs zum Einsatz – VP8, VP9 und AV1 in Software sowie H.264/H.265 über Hardware-Pfade – statt roher Pixel-Rechtecke. Jeder Client lässt sich gegen die öffentliche Infrastruktur, einen eigenen selbstgehosteten Server oder ein selbst geschriebenes Rendezvous-/Relay-System betreiben.
Das Internetproblem: NAT-Traversal
Hier liegt die größte Kluft. Das Basis-VNC-Protokoll verfügt über kein NAT-Traversal. Wie die VNC-Dokumentation anmerkt, muss ein Nutzer, um einen Rechner über das Internet zu erreichen, „diesen Port in der lokalen Firewall öffnen und eine Portweiterleitung konfigurieren, um TCP-Port 5900 weiterzuleiten … sofern er sich hinter einem Router mit Network Address Translation (NAT) befindet“. Der gängige Workaround besteht darin, „VNC durch Secure Shell (SSH) zu tunneln“, was zugleich die Verschlüsselung nachrüstet, die reinem VNC fehlt. Manche kommerziellen VNC-Produkte (wie der Cloud-Dienst von RealVNC) bringen dafür eine eigene Vermittlung mit, doch das ist eine vom Anbieter aufgesetzte Funktion und kein Bestandteil des Protokolls.
RustDesk wurde genau andersherum konzipiert. Da die Endpunkt-Clients ausgehende Verbindungen zu einem Rendezvous-Server aufbauen und bei fehlgeschlagenem direktem Pfad auf ein Relay ausweichen, überwindet RustDesk NAT und Firewalls, ohne pro Endpunkt eine Portweiterleitung, ein VPN oder einen SSH-Tunnel zu benötigen. Die Endpunkte brauchen keine eingehenden Listening-Ports, aber ein selbstgehosteter ID-/Rendezvous- und Relay-Server muss eingehenden Datenverkehr auf seinen dokumentierten Diensteports akzeptieren. Genau dieselbe NAT-Traversal-Geschichte macht RustDesk zu einer praktischen Alternative zu Chrome Remote Desktop oder anderen kostenlosen Tools für Fernzugriff und plattformübergreifenden Einsatz.
Verschlüsselung: Standard vs. „kommt darauf an“
Bei VNC ist Verschlüsselung ein Implementierungsdetail. RealVNC bietet in seinem kommerziellen Paket AES-Verschlüsselung; im Gegensatz dazu ist TightVNC laut VNC-Dokumentation „nicht sicher, da Bilddaten unverschlüsselt übertragen werden“, und „sollte durch eine SSH-Verbindung getunnelt werden“. Die Sicherheit einer VNC-Sitzung hängt also vollständig davon ab, welchen Server man gewählt und wie man ihn konfiguriert hat.
RustDesk wendet bei jeder Verbindung standardmäßig Ende-zu-Ende-Verschlüsselung an, ob selbstgehostet oder nicht – ohne dass man daran denken müsste, einen SSH-Tunnel einzurichten.
RustDesk vs. VNC auf einen Blick
| RustDesk | VNC (RFB) | |
|---|---|---|
| Was es ist | Eine AGPL-App + Rendezvous/Relay | RFB-Protokoll, viele Implementierungen |
| Quellcode | Open Source (AGPL) | Gemischt: GPL/offen (TigerVNC, TightVNC), proprietär (RealVNC) |
| Plattformübergreifend | Windows, macOS, Linux, Android; iOS (nur als Controller) | Sehr breit, einschließlich Raspberry Pi |
| NAT-Traversal | Integriert (Rendezvous + Relay) | Keine im Basisprotokoll – benötigt Portweiterleitung/VPN/SSH |
| Verschlüsselung | Ende-zu-Ende (NaCl) standardmäßig (Dokumentation) | Unterschiedlich: AES (RealVNC) bis keine (TightVNC) |
| Videoübertragung | Moderne Codecs (VP8/VP9/AV1, H.264/H.265) | Pixelbasierte RFB-Kodierungen |
| Self-Hosting | Ja – eigener ID-/Relay-Server | Ja bei offenen Implementierungen (kein integrierter Vermittler) |
| Einrichtung im LAN | Einfach | Sehr einfach |
| Standardisiertes Protokoll | RustDesk-spezifisch | Offener, langjähriger RFB-Standard |
Aktuelle Details zu den RustDesk-Plänen finden Sie unter rustdesk.com/pricing.
Wo RustDesk die Nase vorn hat
Die konstruktiven Vorteile von RustDesk zeigen sich, sobald man das LAN verlässt oder Konsistenz über Teams und Plattformen hinweg benötigt:
- Internetreichweite ohne Verkabelungsaufwand. NAT-Traversal und Relay-Fallback bedeuten: keine Portweiterleitung, kein VPN und kein SSH-Tunnel pro Endpunkt.
- Verschlüsselung, die Sie nicht konfigurieren müssen. Standardmäßig Ende-zu-Ende – keine Implementierung, die Sie erst prüfen müssen.
- Moderne Codecs. VP8/VP9/AV1 sowie hardwarebeschleunigtes H.264/H.265 halten sich über eingeschränkte oder latenzreiche Verbindungen tendenziell besser als rohe Pixelkodierungen.
- Eine überprüfbare App und ein selbstgehosteter Server. Open-Source-Software (AGPL) plus ein selbstgehostetes ID-/Relay-System halten sowohl den Code als auch Ihre Sitzungsdaten auf einer Infrastruktur, die Sie selbst kontrollieren.
Der Preis dafür: Self-Hosting von RustDesk bedeutet, dass jemand den Server betreiben muss – Provisionierung, TLS, Ports und laufendes Patchen. Ein reines LAN-VNC-Setup umgeht das vollständig. Das ist der eigentliche Kompromiss.
Was sollten Sie also verwenden?
Für ein vertrauenswürdiges LAN, ein abgeschottetes Segment oder einen Raspberry Pi sind die Einfachheit und Standardisierung von VNC wirklich kaum zu schlagen. Sobald Sie das Internet sicher überbrücken müssen, Verschlüsselung standardmäßig wünschen oder eine Mischung aus Windows, macOS, Linux, Android und iOS mit einem einzigen Tool abdecken müssen, nimmt Ihnen die Architektur von RustDesk mehr Arbeit ab. Und falls Sie ohnehin native Windows-Tools in Betracht ziehen, deckt unser Vergleich RustDesk vs. RDP diesen Zweig ebenfalls ab.
Jetzt ausprobieren
Wenn dieser Vergleich der Anstoß ist, Ihren SSH-Tunnel endlich in Rente zu schicken: Starten Sie mit dem kostenlosen Community-Server – Open Source, ohne Ablaufdatum, NAT-Traversal inklusive. Schreiben Sie an sales@rustdesk.com, wenn Sie Konditionen für eine Pro-Evaluierung wünschen; die aktuellen Plan-Preise finden Sie unter rustdesk.com/pricing.