Wenn es um die Leistung von Parallels RAS geht, denken wir oft an die Dimensionierung der RDSH, die Optimierung der FSLogix-Profile oder die Netzwerkbandbreite. Ein Parameter fliegt dabei häufig unter dem Radar, obwohl er das Benutzererlebnis grundlegend verändert: das Transportprotokoll der RDP-Sitzung. TCP oder UDP — diese Wahl wirkt sich direkt auf die Flüssigkeit der Sitzung aus, besonders in nicht perfekten Netzwerken.
Die gute Nachricht: Parallels RAS aktiviert UDP standardmäßig. Die weniger gute: Mehrere Elemente Ihrer Netzwerkumgebung können es unbemerkt aushebeln.
TCP vs. UDP: der Netflix-Vergleich
Um zu verstehen, warum UDP für eine RDP-Sitzung besser geeignet ist als TCP, denken Sie an Netflix. Netflix nutzt QUIC — ein UDP-basiertes Protokoll. Denn bei Paketverlust sendet QUIC die folgenden Daten weiter und korrigiert Fehler im laufenden Betrieb. Eine Mikrounterbrechung im Netzwerk führt zu einer leichten Bildverschlechterung für den Bruchteil einer Sekunde, die der Benutzer nicht wahrnimmt.
Würde Netflix TCP verwenden, würde jeder Paketverlust den Datenstrom komplett anhalten, bis die Daten erneut übertragen wurden. Das Video friert ein. Der Benutzer wartet. Genau das passiert mit RDP im TCP-Modus: Eine Mikrounterbrechung im Netzwerk lässt die Sitzung einfrieren, der Bildschirm hängt, und der Benutzer ruft den Support an. Im UDP-Modus wendet RAS einen Fehlerkorrekturmechanismus ähnlich wie beim Videostreaming an — die Sitzung läuft ohne Unterbrechung weiter.
Die 4 Verbindungsmodi des Parallels Client
- Gateway Mode (Standardport 80) — der Client läuft ohne SSL-Verschlüsselung über das Secure Gateway. Typischer Einsatz: vertrauenswürdiges internes Netzwerk. UDP wird unterstützt.
- Gateway SSL Mode (Standardport 443) — dasselbe, aber mit durchgängiger SSL/TLS-Verschlüsselung. UDP wird über DTLS unterstützt. Für die Produktion empfohlen.
- Direct Mode — der Client verbindet sich direkt mit dem RDSH, ohne über das Gateway zu gehen. Der Broker übernimmt nur die anfängliche Umleitung. Dem LAN mit direktem RDSH-Zugriff vorbehalten.
- Direct SSL Mode — wie Direct Mode, aber mit SSL-Verschlüsselung.
In der Produktion deckt der Gateway SSL Mode auf Port 443 alle Fälle ohne Kompromisse ab.
UDP ist in RAS standardmäßig aktiviert
Auf RAS-Seite müssen Sie nichts konfigurieren. UDP Data Tunneling ist sowohl auf dem Secure Gateway als auch auf dem HALB standardmäßig aktiviert.
Auf dem Secure Gateway (Registerkarte Network) ist Enable RDP UDP Data Tunneling standardmäßig aktiviert.
Auf dem HALB (Registerkarte Advanced) steht Enable RDP UDP tunneling standardmäßig auf Enable.
Wenn Sie diese Einstellungen nie angefasst haben, ist UDP aktiv. Punkt.
Warum bleiben manche Sitzungen dann bei TCP?
Die Antwort liegt immer in der Netzwerkumgebung rund um RAS, nie in RAS selbst. Hier die beiden Hauptverdächtigen.
DNS — die häufigste Falle
Ein Parallels Client, der im Gateway SSL Mode mit dem externen FQDN ras.client.com konfiguriert ist, löst diesen FQDN im LAN über den öffentlichen DNS zur öffentlichen IP auf. Der Client nimmt den externen Weg, und das Ergebnis ist TCP. Die Lösung: einen internen DNS-Eintrag anlegen, der ras.client.com auf die LAN-VIP verweist. Gleicher FQDN, gleiches Zertifikat — der DNS übernimmt die Aufteilung. UDP wird sofort ausgehandelt.
Eine Firewall, die UDP/443 filtert
UDP-Port 443 muss auf dem gesamten Weg zwischen Client und Secure Gateway offen sein — einschließlich zwischengeschalteter Firewalls und des HALB. Eine Firewall, die nur TCP/443 durchlässt, zwingt den Client stillschweigend, bei TCP zu bleiben.
Empfohlene Client-Konfiguration in der Produktion
- Primäre Verbindung:
ras.client.com— Gateway SSL Mode — Port 443. Im LAN löst der interne DNS zur LAN-VIP auf → UDP aktiv, minimale Latenz. - Sekundäre Verbindung:
ras.client.com— Gateway SSL Mode — Port 443. Von außen löst der öffentliche DNS zur öffentlichen IP auf → Gateway SSL, UDP, sofern die Firewall es zulässt.
Gleicher FQDN, gleiches Zertifikat, gleiche Client-Konfiguration. Der DNS erledigt die ganze Arbeit.
Gemessene Ergebnisse
Fall 1 — TCP: öffentlicher DNS, nicht optimaler Weg
Gateway Mode, öffentlicher DNS mit Auflösung zur externen IP. Transport: TCP, Latenz 35 ms, Qualität Good.
Fall 2 — UDP im LAN: direkte Verbindung
Windows-Client direkt im LAN im Gateway Mode verbunden. Transport: UDP, Latenz 1 ms, Qualität Excellent, 11 Mbit/s verfügbar.
Fall 3 — UDP im Gateway SSL Mode über VPN
Mac-Client über VPN, Gateway SSL Mode, interner DNS korrekt verteilt. Transport: UDP, Latenz 42 ms, Qualität Good, 8,4 Mbit/s.
Fall 4 — UDP aus dem Internet, UDP/443 offen
Mac-Client aus dem Internet ohne VPN, Gateway SSL Mode, UDP/443 am Router geöffnet. Transport: UDP, Latenz 36 ms, Qualität Good, 7,8 Mbit/s.
Zusammenfassung
| Kontext | Modus | Transport | Latenz | Qualität | Bandbreite |
|---|---|---|---|---|---|
| Öffentlicher DNS, nicht optimaler Weg | Gateway Mode | TCP | 35 ms | Good | 5 Mbit/s |
| LAN direkt | Gateway Mode | UDP | 1 ms | Excellent | 11 Mbit/s |
| Über VPN + interner DNS | Gateway SSL Mode | UDP | 42 ms | Good | 8,4 Mbit/s |
| Extern, UDP/443 offen | Gateway SSL Mode | UDP | 36 ms | Good | 7,8 Mbit/s |
Checkliste für garantiertes UDP
- UDP auf dem Secure Gateway aktiviert — standardmäßig aktiv ✅
- UDP auf dem HALB aktiviert — standardmäßig aktiv ✅
- UDP/443 auf den Firewalls zwischen Client und SG geöffnet
- Interner DNS, der den RAS-FQDN für interne Clients zur LAN-VIP auflöst
- Gateway SSL Mode im Parallels Client konfiguriert (Port 443)
- Gültiges Zertifikat für den verwendeten FQDN
Fazit
UDP ist in Parallels RAS keine Option, die man aktivieren muss — es ist das Standardverhalten. Ihre Aufgabe als Administrator ist es, sicherzustellen, dass nichts in Ihrer Netzwerkumgebung es unbemerkt blockiert. Ein korrekt konfigurierter interner DNS, eine Firewall, die UDP/443 durchlässt, und ein gültiges Zertifikat: Mehr braucht es nicht, damit Ihre Benutzer flüssige RDP-Sitzungen genießen — selbst in nicht perfekten Netzwerken.
