IronRDP: Das Remote Desktop Protocol in modularer Rust-Form

Sans-I/O-Kern statt Monolith: Die Architektur hinter IronRDP

IronRDP von Devolutions ist keine einzelne Client-Anwendung, sondern eine Suite von Rust-Crates rund um das Microsoft Remote Desktop Protocol. Der Kern ist nach dem sans-I/O-Prinzip gebaut: Die Zustandsmaschinen für Verbindung und Sitzung führen selbst keinerlei Ein- und Ausgabe durch. Die Anwendung liefert den Transport, sei es blockierende I/O, tokio, futures oder eine eigene Ereignisschleife, und treibt die Maschinen von außen an. Der Core ist no_std-kompatibel und wird fortlaufend gefuzzt.

Diese Trennung hat eine praktische Folge: Derselbe Protokollkern treibt native Binaries, WebAssembly-Module und C#/.NET-Bindungen. Das Repository ist mit rund 3.100 Sternen in Rust geschrieben, steht unter Apache-2.0 und zeigt mit 129 offenen Issues und aktuellen Pushes im Juli 2026 eine lebendige Entwicklung. Die Crates decken PDU-Codecs, Verbindungs- und Sitzungszustandsmaschinen, virtuelle Kanäle und Bildcodecs ab, sodass native Clients, Server und Proxies aus demselben Bestand gebaut werden können.

Verbindungssequenz und Absicherung mit CredSSP, NTLM und Kerberos

Auf der Protokollseite implementiert IronRDP die vollständige RDP-Verbindungssequenz: X.224-Aushandlung, MCS, Capability-Austausch, Lizenzierung und Reaktivierung. Die Sicherheitsseite umfasst Enhanced RDP Security mit TLS 1.2 und 1.3 sowie Network Level Authentication über CredSSP mit NTLM und Kerberos. Für gatewayvermittelte Just-in-time-Verbindungen gibt es KDC-Proxy- und RDCleanPath-Unterstützung, dazu einen Transport über den Terminal Services Gateway (MS-TSGU).

Zusätzlich liest und schreibt die Suite .rdp-Dateien und bietet einen typisierten Konfigurationsspeicher für Eigenschaften. Für Teams, die RDP-Zugriffe hinter Gateways absichern wollen, sind diese Bausteine der eigentliche Wert: Statt CredSSP selbst zu implementieren, kann ein Proxy oder ein eigener Client die fertigen Zustandsmaschinen verwenden und nur die Netzwerkschicht beisteuern.

Bildcodecs von RLE bis RemoteFX und Bulk-Kompression mit NCRUSH

Die Grafikseite ist auf beide Rollen ausgelegt. Als Client dekodiert IronRDP unkomprimierte Roh-Bitmaps, Interleaved RLE, RDP-6.0-Bitmap-Kompression und RemoteFX (RFX). Als Server encodiert es mit RDP-6.0-Kompression, RemoteFX, optional NSCodec sowie optional QOI und QOI+zstd. Darüber hinaus stehen Codec-Primitive als eigene Bibliotheken bereit: ClearCodec, RemoteFX Progressive, ZGFX und die PDUs der Grafikpipeline (EGFX).

Für die Übertragung selbst stehen Bulk-Kompressionsverfahren MPPC, NCRUSH und XCRUSH zur Verfügung. Das README beschreibt zudem, wie RemoteFX auf einem Windows-Server aktiviert wird: Zwei Registry-Werte unter HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services, nämlich ColorDepth mit Wert 5 und fEnableVirtualizedGraphics mit Wert 1, werden per PowerShell gesetzt, alternativ über gpedit.msc unter den Remote Session Environment-Richtlinien, gefolgt von einem Neustart.

Virtuelle Kanäle: CLIPRDR, RDPSND und der DVC-Named-Pipe-Proxy

RDP lebt von mehr als dem Bildschirmbild, und genau dafür stellt IronRDP die Infrastruktur für statische (SVC) und dynamische Kanäle (DVC über DRDYNVC) bereit. Enthalten sind Zwischenablage-Umleitung über CLIPRDR, Audioausgabe über RDPSND sowie Geräte- und Smartcard-Umleitung über RDPDR. Die Anzeigesteuerung deckt dynamisches Resizing, Echo-Messungen über RTT-Probes, alternative Eingaben und USB-Umleitung ab.

Für Integrationsfälle jenseits der Standardkanäle gibt es einen Windows-DVC-COM-Plugin-Loader und einen DVC-Named-Pipe-Proxy, mit dem externe Prozesse an die Kanalkommunikation angebunden werden. Ein Proxy-Builder kann auf dieser Basis etwa eigene Protokolle in bestehende RDP-Sitzungen einbetten, ohne den Kern verändern zu müssen.

ironrdp-viewer und ironrdp-agent: Zwei fertige Binaries

Neben den Bibliotheks-Crates liefert das Projekt zwei Kommandozeilen-Werkzeuge, die als checksummenbasierte .tar.gz-Archive an jedem GitHub-Release hängen und sich auch per cargo install ironrdp-viewer beziehungsweise cargo install ironrdp-agent installieren lassen. ironrdp-viewer ist ein fensterbasierter Client mit asynchroner I/O und Software-Rendering. Ein Aufruf sieht etwa so aus: ironrdp-viewer <HOSTNAME> --username <USERNAME> --password <PASSWORD>, wobei fehlende Zugangsdaten interaktiv erfragt werden; alternativ lädt --rdp-file ./my-server.rdp eine bestehende Sitzungsdatei. Die Protokollierung regelt die Umgebungsvariable IRONRDP_LOG, etwa IRONRDP_LOG="info,ironrdp_connector=trace".

ironrdp-agent richtet sich an Skripte und LLM-gesteuerte Automatisierung: Ein langlebiger Daemon wird mit daemon-start --overlay ./credentials.rdp gestartet, danach senden kurzlebige CLI-Aufrufe wie connect --server <HOSTNAME> --username <USER> und screenshot ./desktop.png Befehle über IPC. Ohne verfügbare Zugangsdaten schlägt connect mit der Meldung missing required fields fehl. Mit --overlay bleibt das Geheimnis beim Daemon und gelangt nicht an den IPC-Aufrufer; ironrdp-agent --help-agent liefert eine maschinenlesbare Beschreibung aller Operationen. Beide Binaries binden natives Audio ein, weshalb Linux-Builds die ALSA-Header (libasound2-dev auf Debian/Ubuntu) und Windows-Builds NASM benötigen.

Als Crate-Suite nutzen: Features, Beispiele und MSRV-Richtlinie

Für die Bibliotheksnutzung genügt das Meta-Crate ironrdp, bei dem jedes Feature einem eigenständigen Crate entspricht: features = ["connector", "session", "graphics"] zieht die Verbindungsmaschine, die Sitzungsverwaltung und die Grafik decodierung; alternativ kann man direkt auf ironrdp-pdu, ironrdp-connector oder ironrdp-session abhängen. Zwei Beispiele liegen dem Meta-Crate bei: cargo run --example=screenshot -- --host <HOSTNAME> -u <USERNAME> -p <PASSWORD> -o out.png verbindet mit blockierender, synchroner I/O, dekodiert den Desktop und schreibt ein PNG, während cargo run --example=server -- --bind-addr 127.0.0.1:3389 einen minimalen RDP-Server auf Basis von ironrdp-server startet. Die API-Dokumentation liegt auf docs.rs.

Bei der Rust-Version folgt das Projekt einer konservativen MSRV-Richtlinie, die sich an den in Debian stable-backports und Fedora stable verfügbaren Versionen orientiert; die Toolchain in rust-toolchain.toml dient zugleich als von CI validierte Untergrenze. Beiträge richten sich nach ARCHITECTURE.md und STYLE.md, Automatisierung läuft über cargo xtask, dessen Befehle bootstrap und ci dieselben Prüfungen wie die CI-Pipeline abdecken. Wer den Web-Client baut, benötigt zusätzlich Node.js ab Version 24 LTS, die FFI-Bindungen verlangen das .NET SDK.

Einsatzerfahrung von Devolutions Gateway bis qemu-rdp

Die Nutzerliste im README zeigt, wo die Suite bereits im Produktionsmaßstab läuft: Devolutions Gateway nutzt IronRDP für browserbasierten und nativen RDP-Clientzugriff, Cloudflare Access für browserbasiertes RDP, Teleport für Remote-Desktop-Webzugriff. Auf der Serverseite stehen Lamco RDP Server als Wayland-nativer Server für Linux-Desktop-Sharing, MacRDP als nativer Server für macOS und qemu-rdp als RDP-Server für QEMU-Displays; dazu kommt eine wachsende Zahl von Community-Projekten.

Diese Liste belegt die Doppelrolle des Projekts als Client- und Server-Grundlage. Für die Sicherheit selbst macht das README keine Zusagen über die Beschreibung der Praktiken hinaus: Die Core-Crates werden gefuzzt, unsafe wird intensiv gelintet und der Workspace erzwingt strenge Korrektheits-Lints, aber Bewertungen des Angriffs surfaces sollten Teams anhand eigener Prüfungen treffen. Diskussionen finden in einem Matrix-Raum statt, Fehlerberichte über den Issue-Tracker.

Fazit: IronRDP als Bausteinkasten für eigene RDP-Zugänge

IronRDP zerlegt das Remote Desktop Protocol in einzeln einsetzbare Rust-Bausteine und überlässt Transport und Laufzeit der Anwendung. Das macht die Suite für drei Szenarien interessant: eigene native oder webbasierte Clients, eigene RDP-Server für Linux- und macOS-Desktops und Proxy-Gateways, die Verbindungen vermitteln und absichern wollen. Die beiden fertigen Binaries ironrdp-viewer und ironrdp-agent decken dabei die direkten Anwendungsfälle ab, ohne dass man selbst code schreiben muss.

Weniger passend ist die Suite für reine Endanwender, die nur einen Client zum Verbinden suchen; dafür genügt ironrdp-viewer als Test, aber der eigentliche Wert liegt in den Crates. Vor der Übernahme sollte man konkret drei Punkte prüfen: ob die benötigten Features im Meta-Crate ironrdp in Version 0.17 abgedeckt sind, ob die MSRV-Richtlinie zur eigenen Rust-Toolchain passt und ob ein Probelauf mit ironrdp-agent daemon-start --overlay gegen den eigenen Windows-Host Bildcodecs und Anmeldung fehlerfrei durchläuft. Wer diese Schritte absolviert, bekommt einen Protokollstapel, der von Cloudflare und Teleport bis zu qemu-rdp in unterschiedlichen Umgebungen bewiesen ist.

Redaktionelles Fazit

IronRDP richtet sich an Rust-Teams, die RDP-Funktion in eigene Produkte einbauen wollen, sei es als Client, Server oder Proxy, und dabei die Transportwahl selbst behalten möchten. Wer nur gelegentlich auf Windows-Hosts zugreift, fährt mit einem fertigen RDP-Client oft bequemer. Vor dem Einsatz lohnt ein Blick auf die Release-Archive mit Checksummen und ein Probelauf von ironrdp-viewer gegen einen erreichbaren Testhost, um Bildcodecs und Anmeldung im eigenen Umfeld zu verifizieren.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes