Performanter Remote Desktop für Ubuntu und Co.
- Christian Süßenguth
- 24.04.2024, aktualisiert am
- Kurz notiert

Seit vielen Jahren nun nutze ich schon die tollen Möglichkeiten, die virtuelle Maschinen mir und meinen Mitarbeiter:innen im Arbeitsalltag bieten. So laufen die produktiven "Arbeitsdesktops" mit Ubuntu auf einem PROXMOX-Cluster, so dass ich als Administrator jederzeit Zugriff auf die Maschinen habe, um beispielsweise Updates einzuspielen. Gerade durch das Home Office ist das in meinen Augen die einzige Möglichkeit, dauerhaft Datenschutz und Sicherheit der Geräte zu gewährleisten.
Die Mitarbeiter verbinden sich dabei von Ihrem Arbeitsgerät (das kann auch Windows oder macOS sein) mittels Wireguard-VPN mit dem Rechenzentrum und dann über SPICE bzw. virt-viewer
mit der ihnen zugedachten virtuellen Maschine. Ein Firewall-Regelwerk beschränkt dabei sämtliche Zugriffe ausschließlich auf diesen Fernzugriff.

Das hat nun viele Jahre funktioniert, war aber leider nie sonderlich performant. Das liegt daran, dass SPICE als Protokoll nicht für Zwecke gedacht ist, bei denen die Daten auch über latenzbehaftete Leitungen gehen (siehe FAQ von SPICE). Und sobald man beginnt die Möglichkeiten von SPICE auszuschöpfen (wie beispielsweise zwei oder mehr virtuelle Bildschirme), steigt der Datenverkehr linear an und die Performance übers Internet leidet deutlich.
Bei meinem Praxistext wurden bei einer Auflösung von 1920x1080 (FullHD) in einem 30 Sekunden Testzeitraum und festgelegten Testszenario rund 18.369 KB übertragen. Da kann man sich vorstellen, wie schnell man da an Grenzen stößt.
Nun ist leider die Auswahl der Remote-Desktop-Alternativen nicht gerade üppig, wenn man – wie ich – ausschließlich auf Open Source-Software setzen möchte. Es bleiben VNC in verschiedensten Varianten und die freie Implementierung von RDP namens FreeRDP.
x11vnc
Also habe ich zuerst x11vnc
ausprobiert, was mit Hilfe dieser Anleitung und tigervnc-client
als Client recht zügig funktioniert hat. Aber irgendwie hat mir diese Lösung nicht wirklich zugesagt – es waren einfach zu viele Handgriffe nötig. Außerdem funktioniert x11vnc
nur mit dem Display-Manager X11 und nicht mit Wayland. Da Ubuntu standardmäßig Wayland verwendet, wäre auch hier wieder eine Anpassung nötig gewesen, auf die ich verzichten wollte.
gnome-remote-desktop
Also habe ich meine Fühler weiter ausgestreckt und bin über eine großartige Möglichkeit gestoßen, die seit Ubuntu 22.04 standardmäßig mitinstalliert ist: gnome-remote-desktop
Dabei genügt es, ein aktuelles Ubuntu 22.04 LTS oder neuer installiert zu haben und oben rechts unter Einstellungen
den Punkt Freigabe
anzuklicken. Dort kann man dann die Bildschirmfreigabe
aktivieren und hat im Handumdrehen einen lokalen RDP und auf Wunsch auch einen (veralteten) VNC-Server am Laufen.
Hinweis
Es funktioniert nicht nur mit Ubuntu, sondern kann auch Debian oder ein anderes Linux sein, solange GNOME als Benutzeroberfläche verwendet wird.
Auf Client-Seite braucht es dann nur noch ein Tool wie Remmina, was unter Ubuntu ebenfalls bereits mitinstalliert ist, um sich per RDP mit dem Gast zu verbinden.
Hinweis
Bitte beachte, dass bei jedem De- und erneuten Aktivieren von RDP die Zugangsdaten neu vergeben werden. Solange die Schalter aber aktiviert bleiben, bleibt auch das Kennwort gleich.
Für die Administration gibt es das Kommandozeilen-Tool grdctl
, mit welchem man alle Einstellungen auch über das Terminal oder per SSH ausführen kann. Ggf. ist es erforderlich, dass man vor dem Ausführen die Display-Variable mit übergibt:
export DISPLAY=:0 ; grdctl status
Einziger Nachteil dieser Lösung ist, dass bei einer Auflösungsänderung des Gast-PCs die RDP-Verbindung getrennt wird und weder die automatische Anpassung der Gast-Auflösung an die Fenstergröße, noch mehrere Bildschirme und andere SPICE-Funktionen unterstützt werden. Aber die massiv gestiegene Performance macht diese Nachteile definitiv wieder wett.
Um den Praxistest nochmal aufzugreifen:
Mit RDP waren es – bei gleichem Testszenario wie oben mit gleicher Auflösung und Bildqualität – nur 6.957 KB an Datenverkehr. Insgesamt also eine Ersparnis von ca. 66% bei Nutzung von RDP gegenüber SPICE.
Wireguard-Tunnel, RDP und die MTU
In der Praxis habe ich leider mehrfach die Erfahrung machen dürfen, dass Wireguard-Tunnel und RDP-Verbindungen in ganz seltsame Probleme münden können.
Das ging damit los, dass sich von einem Windows-PC, der mit Wireguard-Tunnel zu einem der Ubuntu-PCs verbunden war, einfach keinerlei RDP-Verbindung aufbauen lies. Der Prozess blieb jedes Mal mit der Anzeige Verbindung wird gesichert
(Englisch: Securing remote connection
) hängen und es waren keinerlei Fehlermeldungen auf beiden Seiten erkennbar.
Als es dann am selben Anschluss mit einem Linux-Gerät und Remmina ebenfalls nicht funktionierte, habe ich die Ursache mittels Paketanalyse finden können:
TCP Retransmissions bzw. TCP Dup ACKs
Beides deutet auf verworfene Pakete hin und die haben in den allermeisten Fällen mit einer falschen MTU zu tun.
Mit dem Linux-Befehl ping -s $((1500 - 28)) -D 9.9.9.9 -c 1
lassen sich die Paketgrößen sehr einfach durchprobieren (einfach die 28 entsprechend reduzieren / erhöhen bzw. den Ausgangswert 1500 anpassen).
Wenn das ping-Tool aktuell ist, wird direkt beim ersten Versuch, ein zu großes Paket zu versenden, sogar die maximale MTU angezeigt:
From 192.0.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1452)
Long story short:
Es stellte sich heraus, dass die Kund:in einen Dual-Stack-Lite-Anschluss von Vodafone nutzt, der keine nativen IPv4-Pakete versendet. Stattdessen werden die IPv4-Pakete in IPv6-Paketen verpackt (4in6 encapsulation, RFC6333), was zu einer maximal nutzbaren Payload von 1452 Bytes führt:
1500 - 8 (ICMP-Header) - 40 (IPv6-Header Minimum) = 1452
Bei einem nativen IPv4-Paket wäre es stattdessen:
1500 - 8 (ICMP-Header) - 20 (IPv4 Header Minimum) = 1472
Sobald man die MTU in Wireguard vom Standardwert 1420 auf den korrekten Wert (hier wäre es 1384) anpasst, funktioniert auch die RDP-Verbindung mit Remmina bzw. die Remotedesktopverbindung unter Windows einwandfrei:
Beispiel für die Wireguard-Konfiguration mit MTU:
[Interface]
PrivateKey = XXX
Address = 192.168.1.2/32
MTU = 1384
DNS = 192.168.1.1
[Peer]
PublicKey = YYY
Endpoint = domain.de:51820
AllowedIPs = 0.0.0.0/0
Sehr hilfreiche Tools sind für die Berechnung der MTU einer Verbindung der Visual packet size calculator und der SpeedGuide.net TCP/IP Analyzer.
Weiterführende Links
Ubuntu Hilfe: Ihre Arbeitsumgebung freigeben
Ubuntu 22.04 Finally Supports Remote Desktop Control via MS RDP Protocol
Reddit: Improve SPICE performance
Quelle für MTU bei Dual-Stack

Hi, ich bin Christian und Inhaber der Firma SWEETGOOD. Mit dem andersGOOD Blog möchte ich auch dich für datensichere IT-Lösungen begeistern. So bringst du dein Unternehmen voran, ohne großen Konzernen deine wertvollen Daten zu liefern. Probiers mal anders!
Kommentarbereich
Die Kommentare sind für dich noch deaktiviert, da du dem Setzen von Cookies bisher nicht zugestimmt hast.
Klicke oben rechts auf "Ja, klar!" und lade die Seite neu, um die Kommentare anzuzeigen.
Seite neu laden