RDP Shortpath richtet einen direkten UDP-basierten Datentransport zwischen einer Windows-App auf einem lokalen Gerät bzw. der Remotedesktop-App auf unterstützten Plattformen und den Sitzungshosts in Azure Virtual Desktop ein.
Standardmäßig versucht das Remotedesktopprotokoll (RDP), eine Remotesitzung mithilfe des UDP herzustellen. Zudem verwendet es den TCP-basierten Reverse-Connection-Transport als Fallbackverbindungsmechanismus. Der UDP-basierte Transport bietet bessere Verbindungszuverlässigkeit und konsistentere Latenz. Der TCP-basierte Reverse Connect-Transport bietet die beste Kompatibilität mit verschiedenen Netzwerkkonfigurationen und eine hohe Erfolgsrate für die Einrichtung von RDP-Verbindungen.
RDP-Shortpath kann auf zwei Arten verwendet werden:
Verwaltete Netzwerke, bei denen eine direkte Verbindung zwischen dem Client und dem Sitzungshost hergestellt wird, wenn eine private Verbindung verwendet wird, z. B. ein virtuelles privates Netzwerk (VPN). Eine Verbindung mithilfe eines verwalteten Netzwerks wird auf eine der folgenden Arten hergestellt:
Es wird eine direkte UDP-Verbindung zwischen dem Clientgerät und dem Sitzungshost hergestellt, wobei Sie den RDP Shortpath-Listener aktivieren und einen eingehenden Port auf jedem Sitzungshost zulassen müssen, um Verbindungen zu akzeptieren.
Es wird eine direkte UDP-Verbindung zwischen dem Clientgerät und dem Sitzungshost hergestellt, wobei das STUN-Protokoll (Simple Traversal Underneath NAT) zwischen einem Client und einem Sitzungshost verwendet wird. Eingehende Ports auf dem Sitzungshost müssen nicht zulässig sein.
Öffentliche Netzwerke, bei denen eine direkte Verbindung zwischen dem Client und dem Sitzungshost hergestellt wird, wenn eine öffentliche Verbindung verwendet wird. Bei Verwendung einer öffentlichen Verbindung gibt es zwei Verbindungstypen, die hier in der Reihenfolge ihrer Bevorzugung aufgeführt werden:
Eine direkte UDP-Verbindung mithilfe des STUN-Protokolls (Simple Traversal Underneath NAT) zwischen einem Client und einem Sitzungshost.
Eine indirekte UDP-Verbindung mithilfe des TURN-Protokolls (Traversal Using Relay NAT) mit einer Vermittlung zwischen einem Client und einem Sitzungshost.
Der für RDP Shortpath verwendete Transport basiert auf dem Universal Rate Control Protocol (URCP). URCP ergänzt UDP um die aktive Überwachung der Netzwerkbedingungen und gewährleistet eine angemessene und vollständige Verbindungsnutzung. URCP arbeitet bei Bedarf mit niedrigen Verzögerungs- und Verlustpegeln.
Wichtig
RDP-Shortpath für öffentliche Netzwerke mit TURN ist nur in der öffentlichen Azure-Cloud verfügbar.
Wichtige Vorteile
Die Verwendung von RDP Shortpath hat die folgenden Hauptvorteile:
Die Verwendung von URCP zur Verbesserung von UDP erzielt die beste Leistung durch dynamisches Lernen von Netzwerkparametern und Bereitstellen des Protokolls mit einem Ratensteuerungsmechanismus.
Das Entfernen zusätzlicher Relay-Punkte reduziert die Roundtrip-Zeit, was die Verbindungszuverlässigkeit und das Benutzererlebnis mit latenzempfindlichen Anwendungen und Eingabemethoden verbessert.
Zusätzlich für verwaltete Netzwerke:
RDP Shortpath unterstützt durch DCSP-Markierungen (Differentiated Services Code Point) die Konfiguration der Quality of Service-Priorität (QoS) für RDP-Verbindungen.
Der RDP-Shortpath-Transport ermöglicht die Begrenzung des ausgehenden Netzwerkverkehrs, indem für jede Sitzung eine Drosselungsrate angegeben wird.
Wie RDP-Shortpath funktioniert
Um zu erfahren, wie RDP Shortpath für verwaltete Netzwerke und öffentliche Netzwerke funktioniert, wählen Sie jede der folgenden Registerkarten aus.
Mit den folgenden Methoden können Sie die für die Verwendung von RDP Shortpath mit verwalteten Netzwerken erforderliche direkte Sichtverbindung erreichen.
Standort-zu-Standort- oder Point-to-Site-VPN (IPsec), z. B. Azure VPN Gateway
Eine direkte Sichtverbindung bedeutet, dass der Client eine direkte Verbindung zum Sitzungshost herstellen kann, ohne von Firewalls blockiert zu werden.
Hinweis
Wenn Sie andere VPN-Typen zum Herstellen einer Verbindung mit Azure verwenden, empfehlen wir die Verwendung eines UDP-basierten VPN. Während die meisten TCP-basierten VPN-Lösungen verschachteltes UDP unterstützen, fügen sie einen vererbten Overhead der TCP-Überlastungssteuerung hinzu, was die RDP-Leistung verlangsamt.
Um RDP Shortpath für verwaltete Netzwerke zu verwenden, müssen Sie einen UDP-Listener auf Ihren Sitzungshosts aktivieren. Standardmäßig wird Port 3390 verwendet, Sie können jedoch auch einen anderen Port verwenden.
Das folgende Diagramm bietet eine allgemeine Übersicht über die Netzwerkverbindungen bei Verwendung von RDP Shortpath für verwaltete Netzwerke und Sitzungshosts, die in eine Active Directory-Domäne eingebunden sind.
Verbindungssequenz
Alle Verbindungen beginnen mit dem Aufbau eines TCP-basierten Reverse Connect-Transport über das Azure Virtual Desktop Gateway. Dann richten der Client und der Sitzungshost den anfänglichen RDP-Transport ein und beginnen mit dem Austausch ihrer Fähigkeiten. Diese Fähigkeiten werden mithilfe des folgenden Prozesses ausgehandelt:
Der Sitzungshost sendet die Liste seiner IPv4- und IPv6-Adressen an den Client.
Der Client startet den Hintergrundthread, um einen parallelen UDP-basierten Transport direkt zu einer der IP-Adressen des Sitzungshosts einzurichten.
Während der Client die bereitgestellten IP-Adressen prüft, baut er weiterhin die anfängliche Verbindung über den Reverse-Connect-Transport auf, um sicherzustellen, dass es keine Verzögerung bei der Benutzerverbindung gibt.
Wenn der Client eine direkte Verbindung zum Sitzungshost hat, baut der Client eine sichere TLS-Verbindung über Reliable UDP auf.
Nach dem Einrichten des RDP-Shortpath-Transports werden alle Dynamic Virtual Channels (DVCs), einschließlich Remotegrafiken, Eingaben und Geräteumleitung, auf den neuen Transport verschoben. Wenn jedoch eine Firewall oder Netzwerktopologie den Client daran hindert, eine direkte UDP-Verbindung herzustellen, fährt RDP mit einem Reverse-Connect-Transport fort.
Wenn Ihren Benutzern sowohl RDP Shortpath für verwaltete Netzwerke als auch öffentliche Netzwerke zur Verfügung stehen, wird der erste gefundene Algorithmus verwendet. Die zuerst hergestellte Verbindung wird der Benutzer für diese Sitzung verwenden.
Um die besten Chancen für eine erfolgreiche UDP-Verbindung zu gewährleisten, wenn eine öffentliche Verbindung verwendet wird, gibt es die Verbindungstypen direkt und indirekt:
Direkte Verbindung: STUN wird verwendet, um eine direkte UDP-Verbindung zwischen einem Client und einem Sitzungshost herzustellen. Um diese Verbindung herzustellen, müssen Client und Sitzungshost über eine öffentliche IP-Adresse und einen ausgehandelten Port eine Verbindung miteinander herstellen können. Die meisten Clients kennen jedoch ihre eigene öffentliche IP-Adresse nicht, da sie sich hinter einem NAT-Gatewaygerät (Netzwerkadressenübersetzung) befinden. STUN ist ein Protokoll für die Selbstermittlung einer öffentlichen IP-Adresse eines Clients hinter einem NAT-Gatewaygerät, um seine eigene öffentlich zugängliche IP-Adresse zu bestimmen.
Damit ein Client STUN verwenden kann, muss sein Netzwerk UDP-Datenverkehr zulassen. Unter der Voraussetzung, dass sowohl der Client als auch der Sitzungshost die ermittelte IP-Adresse und den Port der anderen Seite direkt erreichen kann, wird die Kommunikation mit direktem UDP über das WebSocket-Protokoll hergestellt. Wenn Firewalls oder andere Netzwerkgeräte direkte Verbindungen blockieren, wird eine indirekte UDP-Verbindung versucht.
Indirekte Verbindung: TURN wird verwendet, um eine indirekte Verbindung herzustellen und Datenverkehr über einen Zwischenserver zwischen einem Client und Sitzungshost weiterzuleiten, wenn keine direkte Verbindung möglich ist. TURN ist eine Erweiterung von STUN. Die Verwendung von TURN bedeutet, dass die öffentliche IP-Adresse und der Port im Voraus bekannt sind, was über Firewalls und andere Netzwerkgeräte zugelassen werden kann.
TURN autorisiert in der Regel den Zugriff auf den Server über Benutzername/Kennwort, und die bevorzugte Betriebsart ist die Verwendung von UDP-Sockets. Wenn Firewalls oder andere Netzwerkgeräte UDP-Datenverkehr blockieren, wird die Verbindung auf einen TCP-basierten Reverse Connect-Transport zurückgesetzt.
Wenn eine Verbindung hergestellt wird, koordiniert ICE (Interactive Connectivity Establishment) die Verwaltung von STUN und TURN, um die Wahrscheinlichkeit einer Verbindungsherstellung zu optimieren und sicherzustellen, dass den bevorzugten Netzwerkkommunikationsprotokollen Vorrang eingeräumt wird.
Jede RDP-Sitzung verwendet einen dynamisch zugewiesenen UDP-Port aus einem kurzlebigen Portbereich (standardmäßig 49152–65535), der den RDP-Shortpath-Datenverkehr akzeptiert. Port 65330 wird in diesem Bereich ignoriert, da er für die interne Verwendung durch Azure reserviert ist. Sie können auch einen kleineren, vorhersehbaren Portbereich verwenden. Weitere Informationen finden Sie unter Einschränken des von Clients für öffentliche Netzwerke verwendeten Portbereichs.
Tipp
RDP Shortpath für öffentliche Netzwerke funktioniert automatisch ohne zusätzliche Konfiguration, sofern Netzwerke und Firewalls den Datenverkehr zulassen und die RDP-Transporteinstellungen im Windows-Betriebssystem für Sitzungshosts und Clients ihre Standardwerte verwenden.
Die folgende Abbildung bietet eine allgemeine Übersicht über die Netzwerkverbindungen bei Verwendung von RDP Shortpath für öffentliche Netzwerke, bei denen Sitzungshosts mit Microsoft Entra ID verknüpft sind.
Netzwerkadressenübersetzung (NAT, Network Address Translation) und Firewalls
Die meisten Azure Virtual Desktop-Clients werden auf Computern im privaten Netzwerk ausgeführt. Der Internetzugriff erfolgt über ein NAT-Gatewaygerät. Daher ändert das NAT-Gateway alle für das Internet bestimmten Netzwerkanforderungen aus dem privaten Netzwerk. Durch diese Änderung wird eine einzelne öffentliche IP-Adresse von allen Computern im privaten Netzwerk gemeinsam genutzt.
Aufgrund der IP-Paketänderung wird dem Empfänger des Datenverkehrs die öffentliche IP-Adresse des NAT-Gateways anstelle des tatsächlichen Absenders angezeigt. Wenn der Datenverkehr wieder zum NAT-Gateway zurückkehrt, wird sie dafür sorgen, dass er an den vorgesehenen Empfänger weitergeleitet wird, ohne dass der Absender dies weiß. In den meisten Szenarien wissen die hinter einem solchen NAT verborgenen Geräte nicht, dass eine Übersetzung stattfindet, und kennen die Netzwerkadresse des NAT-Gateways nicht.
NAT gilt für die virtuellen Azure-Netzwerke, in denen sich alle Sitzungshosts befinden. Wenn ein Sitzungshost versucht, die Netzwerkadresse im Internet zu erreichen, führt das NAT-Gateway (entweder Ihr eigenes oder standardmäßig von Azure bereitgestelltes) oder Azure Load Balancer die Adressübersetzung durch. Weitere Informationen zu verschiedenen Arten der Quellnetzwerkadressenübersetzung finden Sie unter Verwenden der Quellnetzwerkadressenübersetzung (SNAT) für ausgehende Verbindungen.
Die meisten Netzwerke haben in der Regel Firewalls, die den Datenverkehr überprüfen und gemäß Regeln blockieren. Die meisten Kunden konfigurieren ihre Firewalls, um eingehende Verbindungen zu verhindern (das heißt, nicht angeforderte Pakete aus dem Internet). Firewalls verwenden verschiedene Techniken zum Nachverfolgen des Datenflusses, um zwischen erwünschtem und unerwünschtem Datenverkehr zu unterscheiden. Im Fall von TCP verfolgt die Firewall einfach SYN- und ACK-Pakete nach. UDP-Firewalls verwenden in der Regel Heuristikmethoden auf Basis von Paketadressen, um Datenverkehr einzelnen UDP-Datenflüssen zuzuordnen und sie zuzulassen oder zu blockieren.
Es gibt viele verschiedene NAT-Implementierungen. In den meisten Fällen sind NAT-Gateway und Firewall die Funktionen desselben physischen oder virtuellen Geräts.
Verbindungssequenz
Alle Verbindungen beginnen mit dem Aufbau eines TCP-basierten Reverse Connect-Transport über das Azure Virtual Desktop Gateway. Dann richten der Client und der Sitzungshost den anfänglichen RDP-Transport ein und beginnen mit dem Austausch ihrer Fähigkeiten. Wenn RDP Shortpath für öffentliche Netzwerke auf dem Sitzungshost aktiviert ist, initiiert der Sitzungshost einen Prozess namens Kandidatensammlung:
Der Sitzungshost listet alle Netzwerkschnittstellen auf, die einem Sitzungshost zugewiesen sind, einschließlich virtueller Schnittstellen wie VPN und Teredo.
Der Windows-Dienst Remote Desktop Services (TermService) weist UDP-Sockets auf jeder Schnittstelle zu und speichert das IP:Port-Paar in der Kandidatentabelle als lokaler Kandidat.
Der Remotedesktopdienste-Dienst verwendet jeden im vorherigen Schritt zugewiesenen UDP-Socket, um zu versuchen, den STUN-Server von Azure Virtual Desktop im öffentlichen Internet zu erreichen. Die Kommunikation erfolgt durch Senden eines kleinen UDP-Pakets an Port 3478.
Wenn das Paket den STUN-Server erreicht, reagiert der STUN-Server mit der öffentlichen IP-Adresse und dem Port. Diese Informationen werden in der Kandidatentabelle als reflexive Kandidaten gespeichert.
Nachdem der Sitzungshost alle Kandidaten gesammelt hat, verwendet der Sitzungshost den eingerichteten Rückwärtsverbindungstransport, um die Kandidatenliste an den Client zu übergeben.
Wenn der Client die Kandidatenliste vom Sitzungshost erhält, führt der Client auch eine Kandidatensammlung auf seiner Seite durch. Anschließend sendet der Client seine Kandidatenliste an den Sitzungshost.
Nachdem der Sitzungshost und Client ihre Kandidatenlisten austauschen, versuchen beide Parteien, sich unter Verwendung aller gesammelter Kandidaten miteinander zu verbinden. Dieser Verbindungsversuch erfolgt auf beiden Seiten simultan. Viele NAT-Gateways sind so konfiguriert, dass der eingehende Datenverkehr zum Socket zugelassen wird, sobald die ausgehende Datenübertragung ihn initialisiert. Dieses Verhalten von NAT-Gateways ist der Grund, warum die simultane Verbindung wichtig ist. Wenn STUN fehlschlägt, weil das Protokoll blockiert ist, wird mithilfe von TURN ein indirekter Verbindungsversuch unternommen.
Nach dem anfänglichen Paketaustausch können der Client und Sitzungshost einen oder mehrere Datenflüsse herstellen. Aus diesen Datenströmen wählt RDP den schnellsten Netzwerkpfad aus. Der Client stellt dann eine sichere TLS-Verbindung über Reliable UDP mit dem Sitzungshost her und initiiert den RDP Shortpath-Transport.
Nachdem RDP den RDP-Shortpath-Transport eingerichtet hat, werden alle Dynamic Virtual Channels (DVCs), einschließlich Remotegrafiken, Eingaben und Geräteumleitung, auf den neuen Transport verschoben.
Wenn Ihren Benutzern sowohl RDP Shortpath für verwaltete Netzwerke als auch öffentliche Netzwerke zur Verfügung stehen, wird der „first found“-Algorithmus verwendet, was bedeutet, dass vom Benutzer die für diese Sitzung als erstes hergestellte Verbindung verwendet wird. Weitere Informationen finden im Beispielszenario 4.
Wichtig
Bei Verwendung eines TCP-basierten Transports erfolgt der ausgehende Datenverkehr vom Sitzungshost zum Client über Azure Virtual Desktop Gateway. Mit RDP-Shortpath für öffentliche Netzwerke mit STUN wird ausgehender Datenverkehr direkt zwischen Sitzungshost und Client über das Internet hergestellt. Dadurch wird ein Hop entfernt, was die Latenz und die Endbenutzererfahrung verbessert. Aufgrund der Änderungen im Datenfluss zwischen Sitzungshost und Client, bei denen das Gateway nicht mehr verwendet wird, werden jedoch standardmäßige Azure-Egress-Netzwerkgebühren zusätzlich pro Abonnement für die verbrauchte Internetbandbreite in Rechnung gestellt. Weitere Informationen zur Schätzen der von RDP verwendeten Bandbreite finden Sie unter RDP-Bandbreitenanforderungen.
Netzwerkkonfiguration
Um RDP Shortpath für öffentliche Netzwerke zu unterstützen, benötigen Sie in der Regel keine bestimmte Konfiguration. Der Sitzungshost und -client erkennen automatisch den direkten Datenfluss, wenn dies in Ihrer Netzwerkkonfiguration möglich ist. Allerdings sind alle Umgebungen verschieden, und einige Netzwerkkonfigurationen wirken sich negativ auf die Erfolgsrate der direkten Verbindung aus. Befolgen Sie die nachstehenden Empfehlungen, um die Wahrscheinlichkeit eines direkten Datenflusses zu verbessern.
Da RDP Shortpath UDP verwendet, um einen Datenfluss herzustellen, schlägt RDP Shortpath fehl, wenn eine Firewall in Ihrem Netzwerk UDP-Datenverkehr blockiert, und die Verbindung wird auf TCP-basierten Reverse-Connect-Transport zurückgegriffen. Azure Virtual Desktop verwendet STUN-Server, die von Azure Communication Services und Microsoft Teams bereitgestellt werden. Aufgrund der Art des Features ist die ausgehende Konnektivität von den Sitzungshosts an den Client erforderlich. Leider kann man meist nicht vorhersagen, wo sich die Benutzer befinden. Daher empfehlen wir, ausgehende UDP-Konnektivität von Ihren Sitzungshosts zum Internet zuzulassen. Um die Anzahl der erforderlichen Ports zu reduzieren, können Sie den von Clients verwendeten Portbereich für den UDP-Fluss einschränken. Verwenden Sie die folgenden Tabellen als Referenz, wenn Sie Firewalls für RDP Shortpath konfigurieren.
Wenn Ihre Umgebung symmetrische NAT verwendet, d. h. die Zuordnung einer einzelnen privaten Quell-IP:Port zu einer eindeutigen öffentlichen Ziel-IP:Port, können Sie eine indirekte Verbindung mit TURN verwenden. Dies ist der Fall, wenn Sie Azure Firewall und Azure NAT Gateway verwenden. Weitere Informationen zu NAT mit virtuellen Azure-Netzwerken finden Sie unter Quellnetzwerkadressübersetzung mit virtuellen Netzwerken.
Wenn Benutzern RDP Shortpath sowohl für verwaltete Netzwerke als auch für öffentliche Netzwerke zur Verfügung stehen, wird der erste gefundene Algorithmus verwendet. Die zuerst hergestellte Verbindung wird der Benutzer für diese Sitzung verwenden. Weitere Informationen finden im Beispielszenarien.
TURN-Verfügbarkeit
TURN ist in den folgenden Azure-Regionen verfügbar:
Australien, Südosten
Indien, Mitte
East US
USA (Ost) 2
Frankreich, Mitte
Japan, Westen
Nordeuropa
USA Süd Mitte
Asien, Südosten
UK, Süden
UK, Westen
Europa, Westen
USA (Westen)
USA, Westen 2
Virtuelles Netzwerk des Sitzungshosts
Name
`Source`
Quellport
Destination
Zielport
Protocol
Aktion
RDP Shortpath-Serverendpunkt
VM-Subnetz
Any
Any
1024-65535 (Standardwert: 49152-65535)
UDP
Allow
STUN-/TURN-UDP
VM-Subnetz
Any
20.202.0.0/16
3478
UDP
Allow
STUN-/TURN-TCP
VM-Subnetz
Any
20.202.0.0/16
443
TCP
Allow
Clientnetzwerk
Name
`Source`
Quellport
Destination
Zielport
Protocol
Aktion
RDP Shortpath-Serverendpunkt
Clientnetzwerk
Any
Öffentliche IP-Adressen, die NAT Gateway oder Azure Firewall zugewiesen sind (vom STUN-Endpunkt bereitgestellt)
1024-65535 (Standardwert: 49152-65535)
UDP
Allow
STUN-/TURN-UDP
Clientnetzwerk
Any
20.202.0.0/16
3478
UDP
Allow
STUN-/TURN-TCP
Clientnetzwerk
Any
20.202.0.0/16
443
TCP
Allow
Teredo-Unterstützung
Teredo ist zwar nicht für RDP Shortpath erforderlich, bietet jedoch zusätzliche NAT-Traversalkandidaten und erhöht die Wahrscheinlichkeit der erfolgreichen RDP Shortpath-Verbindung in IPv4-Netzwerken. Weitere Informationen zum Aktivieren von Teredo auf Sitzungshosts und Clients finden Sie unter Aktivieren der Teredo-Unterstützung.
UPnP-Unterstützung
Um die Chancen einer direkten Verbindung zu verbessern, kann RDP Shortpath auf der Seite des Remotedesktopclients UPnP verwenden, um eine Portzuordnung auf dem NAT-Router zu konfigurieren. UPnP ist eine Standardtechnologie, die von verschiedenen Anwendungen wie Xbox, Übermittlungsoptimierung und Teredo verwendet wird. UPnP ist allgemein auf Routern verfügbar, die normalerweise in einem Heimnetzwerk zu finden sind. UPnP ist standardmäßig auf den meisten Heimroutern und Zugangspunkten aktiviert, wird jedoch häufig in Unternehmensnetzwerken deaktiviert.
Allgemeine Empfehlungen
Hier sind einige allgemeine Empfehlungen für die Verwendung von RDP Shortpath für öffentliche Netzwerke:
Vermeiden Sie die Verwendung von Force-Tunneling-Konfigurationen, wenn Ihre Benutzer über das Internet auf Azure Virtual Desktop zugreifen.
Stellen Sie sicher, dass Sie keine doppelten NAT- oder Carrier-Grade-NAT(CGN)-Konfigurationen verwenden.
Empfehlen Sie Ihren Benutzern, UPnP auf ihren Heimroutern nicht zu deaktivieren.
Vermeiden Sie die Verwendung von Cloud-Paketinspektionsdiensten.
Vermeiden Sie die Verwendung von TCP-basierten VPN-Lösungen.
Aktivieren Sie IPv6-Konnektivität oder Teredo.
Verbindungssicherheit
RDP-Shortpath erweitert die Multi-Transport-Funktionen von RDP. Es soll den Reverse Connection-Transport nicht ersetzen, sondern ergänzen. Die Erstsitzungsvermittlung wird über den Azure Virtual Desktop-Dienst und den Reverse Connect-Transport verwaltet. Alle Verbindungsversuche werden ignoriert, es sei denn, sie stimmen zuerst mit der Reverse-Connect-Sitzung überein. RDP-Shortpath wird nach der Authentifizierung eingerichtet, und bei erfolgreicher Einrichtung wird der Reverse Connect-Transport verworfen und der gesamte Datenverkehr fließt über den RDP Shortpath.
RDP Shortpath verwendet eine sichere TLS-Verbindung über Reliable UDP zwischen Client und Sitzungshost und nutzt dafür die Zertifikate des Sitzungshosts. Standardmäßig wird das für die RDP-Verschlüsselung verwendete Zertifikat während der Bereitstellung vom Betriebssystem selbst generiert. Sie können auch zentral verwaltete Zertifikate bereitstellen, die von einer Unternehmenszertifizierungsstelle ausgestellt wurden. Weitere Informationen zu Zertifikatskonfigurationen finden Sie unter Remotedesktop-Listener-Zertifikatskonfigurationen.
Hinweis
Die Sicherheit, die RDP Shortpath bietet, ist die gleiche wie die, die der TCP Reverse Connect-Transport bietet.
Beispielszenarien
Im Folgenden finden Sie einige Beispielszenarien, die zeigen, wie Verbindungen ausgewertet werden, um zu entscheiden, ob RDP Shortpath verschiedene Netzwerktopologien übergreifend verwendet wird.
Szenario 1
Eine UDP-Verbindung zwischen dem Clientgerät und dem Sitzungshost kann nur über ein öffentliches Netzwerk (Internet) hergestellt werden. Eine direkte Verbindung, z. B. ein VPN, ist nicht verfügbar. UDP ist über eine Firewall oder ein NAT-Gerät zulässig.
Szenario 2
Eine Firewall oder ein NAT-Gerät blockiert eine direkte UDP-Verbindung, aber eine indirekte UDP-Verbindung kann mit TURN zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk (Internet) weitergeleitet werden. Eine weitere direkte Verbindung, z. B. ein VPN, ist nicht verfügbar.
Szenario 3
Eine UDP-Verbindung zwischen dem Clientgerät und dem Sitzungshost kann über ein öffentliches Netzwerk oder eine direkte VPN-Verbindung hergestellt werden, aber RDP Shortpath für verwaltete Netzwerke ist nicht aktiviert. Wenn der Client die Verbindung initiiert, kann das ICE/STUN-Protokoll mehrere Routen anzeigen, wertet jede Route aus und wählt die Route mit der geringsten Latenz aus.
In diesem Beispiel wird eine UDP-Verbindung mit RDP Shortpath für öffentliche Netzwerke über die direkte VPN-Verbindung hergestellt, da sie die niedrigste Latenz aufweist, wie die grüne Linie zeigt.
Szenario 4
Sowohl RDP Shortpath für öffentliche Netzwerke als auch verwaltete Netzwerke sind aktiviert. Eine UDP-Verbindung zwischen dem Clientgerät und dem Sitzungshost kann über ein öffentliches Netzwerk oder eine direkte VPN-Verbindung hergestellt werden. Wenn der Client die Verbindung initiiert, wird gleichzeitig versucht, eine Verbindung mit RDP Shortpath für verwaltete Netzwerke über Port 3390 (standardmäßig) und RDP Shortpath für öffentliche Netzwerke über das ICE/STUN-Protokoll herzustellen. Der zuerst gefundene Algorithmus wird verwendet, und der Benutzer verwendet die zuerst hergestellte Verbindung für diese Sitzung.
Da der Weg über ein öffentliches Netzwerk weitere Schritte umfasst, z. B. ein NAT-Gerät, einen Lastenausgleich oder einen STUN-Server, ist es wahrscheinlich, dass der zuerst gefundene Algorithmus die Verbindung mit RDP Shortpath für verwaltete Netzwerke auswählt und diese zuerst hergestellt wird.
Szenario 5
Eine UDP-Verbindung zwischen dem Clientgerät und dem Sitzungshost kann über ein öffentliches Netzwerk oder eine direkte VPN-Verbindung hergestellt werden, aber RDP Shortpath für verwaltete Netzwerke ist nicht aktiviert. Um zu verhindern, dass ICE/STUN eine bestimmte Route verwendet, kann ein Administrator eine der Routen für UDP-Datenverkehr blockieren. Das Blockieren einer Route würde sicherstellen, dass der verbleibende Pfad immer verwendet wird.
In diesem Beispiel wird UDP für die direkte VPN-Verbindung blockiert, und das ICE/STUN-Protokoll stellt eine Verbindung über das öffentliche Netzwerk her.
Szenario 6
RDP Shortpath ist sowohl für öffentliche Netzwerke als auch verwaltete Netzwerke konfiguriert, doch konnte keine UDP-Verbindung über eine direkte VPN-Verbindung hergestellt werden. Eine Firewall oder ein NAT-Gerät blockiert auch eine direkte UDP-Verbindung über das öffentliche Netzwerk (Internet), aber eine indirekte UDP-Verbindung kann mit TURN zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk (Internet) weitergeleitet werden.
Szenario 7
RDP Shortpath ist sowohl für öffentliche Netzwerke als auch verwaltete Netzwerke konfiguriert, doch konnte keine UDP-Verbindung hergestellt werden. In diesem Fall tritt bei RDP Shortpath ein Fehler auf, und die Verbindung wird auf den TCP-basierten Reverse Connect-Datentransport zurückgesetzt.
