Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
RDP Shortpath richtet einen UDP-basierten Transport 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 beginnt das Remotedesktopprotokoll (RDP) mit einem TCP-basierten Reverse Connect-Transport und versucht dann, eine Remotesitzung mithilfe des UDP herzustellen. Wenn die UDP-Verbindung erfolgreich ist, wird die TCP-Verbindung getrennt, andernfalls wird die TCP-Verbindung als Fallbackverbindungsmechanismus verwendet.
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. Azure ExpressRoute oder ein Site-to-Site-VPN (virtuelles privates Netzwerk). 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 UDP-Verbindung mittels Relay mithilfe des TURN-Protokolls (Traversal Using Relay NAT) 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
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.
Höherer Durchsatz.
Bei Verwendung von STUN reduziert das Entfernen zusätzlicher Relay-Punkte die Roundtrip-Zeit (Round-Trip Time, RTT), 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.
Um zu erfahren, wie RDP Shortpath für verwaltete Netzwerke und öffentliche Netzwerke funktioniert, wählen Sie jede der folgenden Registerkarten aus.
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 mittels Relay:
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 UDP-Verbindung mittels Relay versucht.
Verbindung mittels Relay: TURN wird verwendet, um eine 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.
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.
Das TURN-Relay ist in den folgenden Azure-Regionen verfügbar:
Ein TURN-Relay wird basierend auf dem physischen Standort des Clientgeräts ausgewählt. Wenn sich z. B. ein Clientgerät im Vereinigten Königreich befindet, wird das TURN-Relay in der Region „Vereinigtes Königreich, Süden“ oder „Vereinigtes Königreich, Westen“ ausgewählt. Wenn ein Clientgerät weit von einem TURN-Relay entfernt ist, kann die UDP-Verbindung auf TCP zurückgreifen.
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.
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 Verbindungsversuch mittels Relay 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.
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 Verbindung mittels Relay 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.
Wir haben einige allgemeine Empfehlungen für erfolgreiche Verbindungen mithilfe von RDP Shortpath für öffentliche Netzwerke. Weitere Informationen finden Sie unter Allgemeine Empfehlungen.
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.
Die folgenden Abschnitte enthalten die Quell-, Ziel- und Protokollanforderungen für Ihre Sitzungshosts und Clientgeräte, die für die Arbeit von RDP Shortpath zulässig sein müssen.
Hinweis
Für eine Verbindung mittels Relay mit TURN wird das IP-Subnetz 20.202.0.0/16 für Azure Communication Services freigegeben. Azure Virtual Desktop und Windows 365 werden jedoch auf den Bereich 51.5.0.0/16umgestellt, der ausschließlich für diese Dienste vorgesehen ist. Es wird empfohlen, beide Bereiche in Ihrer Netzwerkumgebung jetzt zu konfigurieren, um einen nahtlosen Übergang sicherzustellen.
Wenn Sie mit der Verwendung des dedizierten Subnetzes warten möchten, führen Sie die Schritte unter Konfigurieren von Hostpool-Netzwerkeinstellungen aus, und legen Sie RDP Shortpath für öffentliche Netzwerke (über TURN/Relay) auf Deaktiviert fest. Alternativ können Sie UDP auf dem lokalen Gerät deaktivieren, aber dadurch wird UDP für alle Verbindungen deaktiviert. Um UDP auf dem lokalen Gerät zu deaktivieren, führen Sie die Schritte unter Überprüfen, ob das UDP auf Windows-Clientgeräten aktiviert ist aus, legen Sie jedoch UDP auf Client deaktivieren auf Aktiviert fest. Wenn Sie den IP-Bereich 20.202.0.0/16 in Ihrem Netzwerk blockieren und VPN-Anwendungen verwenden, kann dies zu Verbindungsunterbrechungsproblemen führen.
In der folgenden Tabelle werden die Quell-, Ziel- und Protokollanforderungen für RDP Shortpath für Ihr virtuelles Sitzungshostnetzwerk beschrieben.
| Name | `Source` | Quellport | Destination | Zielport | Protocol | Aktion |
|---|---|---|---|---|---|---|
| Direkte STUN-Verbindung | VM-Subnetz | Any | Any | 1024-65535 (Standardwert: 49152-65535) |
UDP | Allow |
| STUN-Infrastruktur/TURN | VM-Subnetz | Any | 20.202.0.0/16 |
3478 | UDP | Allow |
| TURN-Relay | VM-Subnetz | Any | 51.5.0.0/16 |
3478 | UDP | Allow |
In der folgenden Tabelle werden die Quell-, Ziel- und Protokollanforderungen für Ihre Clientgeräte beschrieben.
| Name | `Source` | Quellport | Destination | Zielport | Protocol | Aktion |
|---|---|---|---|---|---|---|
| Direkte STUN-Verbindung | 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-Infrastruktur/TURN-Relay | Clientnetzwerk | Any | 20.202.0.0/16 |
3478 | UDP | Allow |
| TURN-Relay | Clientnetzwerk | Any | 51.5.0.0/16 |
3478 | UDP | Allow |
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.
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.
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.
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.
Im Folgenden finden Sie einige Beispielszenarien, die zeigen, wie Verbindungen ausgewertet werden, um zu entscheiden, ob RDP Shortpath verschiedene Netzwerktopologien übergreifend verwendet wird.
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.
Eine Firewall oder ein NAT-Gerät blockiert eine direkte UDP-Verbindung, aber eine UDP-Verbindung mittels Relay 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.
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.
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.
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.
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 UDP-Verbindung mittels Relay kann mit TURN zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk (Internet) weitergeleitet werden.
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.
Training
Modul
Implementieren und Verwalten des Netzwerks für Azure Virtual Desktop - Training
Implementieren und Verwalten des Netzwerks für Azure Virtual Desktop
Zertifizierung
Microsoft Certified: Azure Virtual Desktop Specialty - Certifications
Planen, Bereitstellen, Verwalten und Überwachen virtueller Desktopumgebungen und von Remote-Apps in Microsoft Azure für beliebige Geräte
Dokumentation
Konfigurieren Sie RDP-Shortpath für Azure Virtual Desktop
Hier erfahren Sie, wie Sie RDP Shortpath für Azure Virtual Desktop konfigurieren, wodurch ein UDP-basierter Datentransport für eine Remotesitzung eingerichtet wird.
Aktivieren von RDP Shortpath für öffentliche Netzwerke - Azure Virtual Desktop
Hilft bei der Problembehandlung bei RDP Shortpath für öffentliche Netzwerke für Azure Virtual Desktop, die einen UDP-basierten Transport zwischen einem Remotedesktopclient und Sitzungshost herstellt.
Grundlegendes zur Netzwerkkonnektivität für Azure Virtual Desktop - Azure
Hier erhalten Sie Informationen zur Netzwerkkonnektivität für Azure Virtual Desktop.
