RDP-Shortpath stellt einen UDP-basierten Transport zwischen einer lokalen Geräte-Windows-App oder der Remotedesktop-App auf unterstützten Plattformen und dem Sitzungshost in Azure Virtual Desktop her. Standardmäßig startet das Remotedesktopprotokoll (RDP) einen TCP-basierten Reverse-Connect-Transport und versucht dann, eine Remotesitzung über UDP aufzubauen. Wenn die UDP-Verbindung erfolgreich ist, wird die TCP-Verbindung getrennt, andernfalls wird die TCP-Verbindung als Fallbackverbindungsmechanismus verwendet.
Der UDP-basierte Transport bietet eine höhere Verbindungszuverlässigkeit und konsistentere Latenz. Der TCP-basierte Reverse-Connect-Transport bietet beste Kompatibilität mit verschiedenen Netzwerkkonfigurationen und weist eine hohe Erfolgsrate beim Herstellen von RDP-Verbindungen auf.
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. Eine Verbindung über ein verwaltetes Netzwerk wird auf eine der folgenden Arten hergestellt:
Eine direkte UDP-Verbindung zwischen Clientgerät und Sitzungshost, bei der Sie den RDP-Shortpath-Listener aktivieren und einen eingehenden Port auf jedem Sitzungshost zulassen müssen, um Verbindungen zu akzeptieren.
Eine direkte UDP-Verbindung zwischen Clientgerät und Sitzungshost unter Verwendung des STUN-Protokolls (Simple Traversal Underneath NAT) zwischen einem Client und dem Sitzungshost. Eingehende Ports auf dem Sitzungshost müssen nicht zugelassen werden.
Öffentliche Netzwerke, bei denen eine direkte Verbindung zwischen dem Client und dem Sitzungshost hergestellt wird, wenn eine öffentliche Verbindung verwendet wird. Es gibt zwei Verbindungstypen bei Verwendung einer öffentlichen Verbindung, die hier in der Reihenfolge ihrer Präferenz aufgeführt sind:
Eine direkte UDP-Verbindung zwischen einem Client und dem Sitzungshost über das STUN-Protokoll (Simple Traversal Underneath NAT).
Eine weitergeleitete UDP-Verbindung über das TURN-Protokoll (Traversal Using Relay NAT) zwischen einem Client und dem Sitzungshost.
Der für RDP-Shortpath verwendete Transport basiert auf dem Universal Rate Control Protocol (URCP). URCP verbessert UDP durch aktive Überwachung der Netzwerkbedingungen und bietet eine faire und vollständige Verbindungsauslastung. URCP arbeitet bei Bedarf mit geringer Verzögerung und Verlust.
Wichtig
-
Azure-Cloud: RDP-Shortpath für öffentliche Netzwerke über STUN und TURN ist allgemein verfügbar.
-
Azure Cloud for Government: RDP-Shortpath über STUN und TURN ist in der öffentlichen Vorschau mit **dedizierten Servern mit IP-Bereich **20.140.236.0/22 verfügbar. Kunden können das Feature für den Sitzungshost im Validierungsring testen.
Hauptvorteile
Die Verwendung von RDP-Shortpath hat die folgenden Hauptvorteile:
Die Verwendung von URCP zur Verbesserung von UDP erzielt die beste Leistung, indem Netzwerkparameter dynamisch gelernt und das Protokoll mit einem Ratenkontrollmechanismus ausgestattet wird.
Höherer Durchsatz.
Bei Verwendung von STUN reduziert das Entfernen zusätzlicher Relaispunkte die Roundtripzeit, verbessert die Verbindungszuverlässigkeit und die Benutzererfahrung mit latenzempfindlichen Anwendungen und Eingabemethoden.
Darüber hinaus gilt für verwaltete Netzwerke:
RDP-Shortpath bietet Unterstützung für das Konfigurieren der QoS-Priorität (Quality of Service) für RDP-Verbindungen durch DSCP-Markierungen (Differentiated Services Code Point).
Der RDP-Shortpath-Transport ermöglicht das Einschränken des ausgehenden Netzwerkdatenverkehrs, indem für jede Sitzung eine Drosselungsrate angegeben wird.
Funktionsweise von RDP-Shortpath
Um mehr zur Funktionsweise von RDP-Shortpath für verwaltete Netzwerke und öffentliche Netzwerke zu erhalten, wählen Sie jede der folgenden Registerkarten aus.
Die für die Verwendung von RDP-Shortpath mit verwalteten Netzwerken erforderliche direkte Sichtverbindung können Sie mit den folgenden Methoden herstellen.
Eine direkte Sichtverbindung bedeutet, dass der Client eine direkte Verbindung mit dem 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 VPNs. Die meisten TCP-basierten VPN-Lösungen unterstützen zwar verschachteltes UDP, fügen jedoch einen geerbten Overhead der TCP-Überlastungssteuerung hinzu, wodurch die RDP-Leistung verlangsamt wird.
Um RDP-Shortpath für verwaltete Netzwerke verwenden zu können, müssen Sie einen UDP-Listener auf Ihren Sitzungshosts aktivieren. Standardmäßig wird Port 3390 verwendet, Sie können aber auch einen anderen Port verwenden.
Das folgende Diagramm gibt einen Überblick über die Netzwerkverbindungen bei Verwendung von RDP-Shortpath für verwaltete Netzwerke und Sitzungshosts, die einer Active Directory-Domäne beigetreten sind.
Verbindungssequenz
Alle Verbindungen beginnen mit dem Aufbau eines TCP-basierten Reverse-Connect-Transports über das Azure Virtual Desktop Gateway. Anschließend richten Client und Sitzungshost den anfänglichen RDP-Transport ein und beginnen mit dem Austausch ihrer Funktionen. Diese Funktionen 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 herzustellen.
Während der Client die bereitgestellten IP-Adressen überprü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 mit dem Sitzungshost hat, stellt der Client eine sichere Verbindung mit TLS über zuverlässiges UDP her.
Nach dem Einrichten des RDP-Shortpath-Transports werden alle dynamischen virtuellen Kanäle (Dynamic Virtual Channels, DVCs), einschließlich Remotegrafik-, Eingabe- und Geräteumleitung, auf den neuen Transport verschoben. Wenn jedoch eine Firewall- oder Netzwerktopologie verhindert, dass der Client eine direkte UDP-Verbindung herstellen kann, wird RDP mit einem Reverse-Connect-Transport fortgesetzt.
Wenn Ihren Benutzern sowohl RDP-Shortpath für verwaltete Netzwerke als auch öffentliche Netzwerke zur Verfügung stehen, wird der zuerst gefundene Algorithmus verwendet. Der Benutzer verwendet die Verbindung, die zuerst für diese Sitzung hergestellt wird.
Um die besten Chancen für eine erfolgreiche UDP-Verbindung bei Verwendung einer öffentlichen Verbindung zu bieten, gibt es die direkten und weitergeleiteten Verbindungstypen:
Direkte Verbindung: STUN wird verwendet, um eine direkte UDP-Verbindung zwischen einem Client und einem Sitzungshost herzustellen. Um diese Verbindung herzustellen, müssen der Client und der Sitzungshost über eine öffentliche IP-Adresse und einen ausgehandelten Port eine Verbindung miteinander herstellen können. Die meisten Clients kennen ihre eigene öffentliche IP-Adresse jedoch nicht, da sie sich hinter einem NAT-Gatewaygerät (Network Address Translation) befinden. STUN ist ein Protokoll zur Selbsterkennung einer öffentlichen IP-Adresse hinter einem NAT-Gatewaygerät und dem Client, um seine eigene öffentliche IP-Adresse zu ermitteln.
Damit ein Client STUN verwenden kann, muss sein Netzwerk UDP-Datenverkehr zulassen. Unter der Annahme, dass sowohl der Client als auch der Sitzungshost direkt an die ermittelte IP-Adresse und den Port des anderen weitergeleitet werden können, wird die Kommunikation mit direktem UDP über das WebSocket-Protokoll hergestellt. Wenn Firewalls oder andere Netzwerkgeräte direkte Verbindungen blockieren, wird eine weitergeleitete UDP-Verbindung versucht.
Weitergeleitete Verbindung: TURN wird verwendet, um eine Verbindung herzustellen und den Datenverkehr über einen Zwischenserver zwischen einem Client und dem Sitzungshost weiterzuleiten, wenn eine direkte Verbindung nicht 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 durch 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ückgreifen.
Wenn eine Verbindung hergestellt wird, koordiniert Interactive Connectivity Establishment (ICE) die Verwaltung von STUN und TURN, um die Wahrscheinlichkeit des Verbindungsaufbaus zu optimieren und sicherzustellen, dass bevorzugten Netzwerkkommunikationsprotokollen Vorrang eingeräumt wird.
Jede RDP-Sitzung verwendet einen dynamisch zugewiesenen UDP-Port aus einem kurzlebigen Portbereich (standardmäßig 49152 bis 65535), der den RDP-Shortpath-Datenverkehr akzeptiert. Port 65330 wird in diesem Bereich ignoriert, da er für die interne Verwendung in Azure reserviert ist. Sie können auch einen kleineren, vorhersehbaren Portbereich verwenden. Weitere Informationen finden Sie unter Begrenzen des von Clients für öffentliche Netzwerke verwendeten Portbereichs.
Tipp
RDP-Shortpath für öffentliche Netzwerke funktioniert automatisch ohne zusätzliche Konfiguration, vorausgesetzt, Netzwerke und Firewalls lassen den Datenverkehr zu und die RDP-Transporteinstellungen im Windows-Betriebssystem für Sitzungshosts und Clients verwenden ihre Standardwerte.
Das folgende Diagramm gibt einen Überblick über die Netzwerkverbindungen bei Verwendung von RDP-Shortpath für öffentliche Netzwerke, in denen Sitzungshosts mit Microsoft Entra ID verbunden sind.
Verfügbarkeit des TURN-Relais
TURN Relay ist in den folgenden Azure-Regionen mit ACS TURN Relay (51.5.0.0/16) verfügbar:
- Australien Zentral
- Australien (Osten)
- Australien (Südosten)
- Brasilien Süd
- Kanada, Mitte
- Kanada, Osten
- Indien, Mitte
- USA (Mitte)
- USA (Osten)
- USA (Osten) 2
- Frankreich, Mitte
- Deutschland, Westen-Mitte
- Israel, Mitte
- Japan Osten
- Japan Westen
- Korea zentral
- Südkorea, Süden
- Mexiko, Mitte
- USA (Norden, Mitte)
- Nordeuropa
- Norwegen, Westen
- Süd-Afrika Nord
- Süd-Afrika, Westen
- USA (Süden, Mitte)
- Südostasien
- Indien, Süden
- Spanien, Mitte
- Schweiz Nord
- Tawain, Norden
- Tawain, Nordosten
- VAE Zentral
- VAE Nord
- Vereinigtes Königreich (Süden)
- Vereinigtes Königreich (Westen)
- USA (Westen, Mitte)
- Westeuropa
- USA (Westen)
- USA (Westen) 2
- USA, Westen 3
Ein TURN-Relais wird basierend auf dem physischen Standort des Client-Geräts ausgewählt. Wenn sich ein Clientgerät beispielsweise 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-Relais entfernt ist, kann die UDP-Verbindung auf TCP zurückgreifen.
Netzwerkadressübersetzung und Firewalls
Die meisten Azure Virtual Desktop-Clients werden auf Computern im privaten Netzwerk ausgeführt. Der Internetzugriff wird über ein NAT-Gatewaygerät (Network Address Translation) bereitgestellt. Daher modifiziert das NAT-Gateway alle Netzwerkanforderungen aus dem privaten Netzwerk und für das Internet. Bei dieser Änderung soll eine einzelne öffentliche IP-Adresse auf allen Computern im privaten Netzwerk gemeinsam genutzt werden.
Aufgrund der Änderung von IP-Paketen wird dem Empfänger des Datenverkehrs die öffentliche IP-Adresse des NAT-Gateways anstelle des tatsächlichen Absenders angezeigt. Wenn Datenverkehr zum NAT-Gateway zurückkehrt, wird er ohne Wissen des Absenders an den vorgesehenen Empfänger weitergeleitet. In den meisten Szenarien wissen die hinter einer 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 das standardmäßig von Azure bereitgestellte Gateway) oder Azure Load Balancer die Adressübersetzung durch. Weitere Informationen zu den verschiedenen Arten der Übersetzung von Quellnetzwerkadressen finden Sie unter Verwenden von Quellnetzwerkadressübersetzung (SNAT) für ausgehende Verbindungen.
Die meisten Netzwerke enthalten in der Regel Firewalls, die den Datenverkehr überprüfen und basierend auf Regeln blockieren. Die meisten Kunden konfigurieren ihre Firewalls so, dass eingehende Verbindungen (d. h. unerwünschte Pakete aus dem Internet, die ohne Anforderung gesendet werden) verhindert werden. Firewalls verwenden verschiedene Techniken zur Verfolgung des Datenflusses, um zwischen angefragtem und nicht angefordertem Datenverkehr zu unterscheiden. Im Zusammenhang mit TCP verfolgt die Firewall SYN- und ACK-Pakete nach, und der Vorgang ist unkompliziert. UDP-Firewalls verwenden in der Regel Heuristiken basierend auf Paketadressen, um Datenverkehr mit UDP-Flüssen zu verknüpfen und zuzulassen oder zu blockieren. Es stehen viele verschiedene NAT-Implementierungen zur Verfügung.
Verbindungssequenz
Alle Verbindungen beginnen mit dem Aufbau eines TCP-basierten Reverse-Connect-Transports über das Azure Virtual Desktop Gateway. Anschließend richten Client und Sitzungshost den anfänglichen RDP-Transport ein und beginnen mit dem Austausch ihrer Funktionen. Wenn RDP-Shortpath für öffentliche Netzwerke auf dem Sitzungshost aktiviert ist, initiiert der Sitzungshost einen Prozess namens "Candidate Gathering":
Der Sitzungshost zählt alle Netzwerkschnittstellen auf, die einem Sitzungshost zugewiesen sind, einschließlich virtueller Schnittstellen wie VPN und Teredo.
Der Windows-Dienst Remotedesktopdienste (TermService) weist jeder Schnittstelle UDP-Sockets zu und speichert das IP:Port-Paar in der Kandidatentabelle als lokalen Kandidaten.
Der Remotedesktopdienst verwendet jeden im vorherigen Schritt zugewiesenen UDP-Socket, um zu versuchen, den Azure Virtual Desktop STUN-Server im öffentlichen Internet zu erreichen. Die Kommunikation erfolgt durch Senden eines kleinen UDP-Pakets an Port 3478.
Wenn das Paket den STUN-Server erreicht, antwortet der STUN-Server mit der öffentlichen IP und dem Port. Diese Information wird in der Kandidatentabelle als reflexiver Kandidat gespeichert.
Nachdem der Sitzungshost alle Kandidaten gesammelt hat, verwendet der Sitzungshost den eingerichteten Reverse-Connect-Transport, um die Kandidatenliste an den Client zu übergeben.
Wenn der Client die Kandidatenliste vom Sitzungshost erhält, führt der Client auch die Kandidatensammlung auf seiner Seite durch. Anschließend sendet der Client seine Kandidatenliste an den Sitzungshost.
Nachdem der Sitzungshost und der Client ihre Kandidatenlisten ausgetauscht haben, versuchen beide Parteien, sich über alle gesammelten Kandidaten miteinander zu verbinden. Dieser Verbindungsversuch erfolgt auf beiden Seiten gleichzeitig. 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 gleichzeitige Verbindung unerlässlich ist. Wenn STUN fehlschlägt, weil es blockiert ist, wird ein Verbindungsversuch mit Weiterleitung mithilfe von TURN unternommen.
Nach dem ersten Paketaustausch können der Client und der Sitzungshost einen oder mehrere Datenflüsse einrichten. Aus diesen Datenflüssen wählt RDP den schnellsten Netzwerkpfad aus. Der Client stellt dann eine sichere Verbindung mit dem Sitzungshost über TLS über zuverlässiges UDP her und initiiert den RDP-Shortpath-Transport.
Nachdem RDP den RDP-Shortpath-Transport eingerichtet hat, werden alle dynamischen virtuellen Kanäle (Dynamic Virtual Channels, DVCs), einschließlich Remotegrafik, Eingabe und Geräteumleitung, auf den neuen Transport verschoben.
Wenn Ihren Benutzern sowohl RDP-Shortpath für verwaltete als auch öffentliche Netzwerke zur Verfügung stehen, wird der zuerst gefundene Algorithmus verwendet, d. h., der Benutzer verwendet die Verbindung, die zuerst für diese Sitzung hergestellt wird. Weitere Informationen finden Sie im Beispielszenario 4.
Netzwerkkonfiguration
Zur Unterstützung von RDP-Shortpath für öffentliche Netzwerke benötigen Sie in der Regel keine bestimmte Konfiguration. Der Sitzungshost und der Client ermitteln automatisch den direkten Datenfluss, wenn dies in Ihrer Netzwerkkonfiguration möglich ist. Jede Umgebung ist jedoch einzigartig und einige Netzwerkkonfigurationen können sich negativ auf die Erfolgsrate der direkten Verbindung auswirken. Befolgen Sie die Empfehlungen , um die Wahrscheinlichkeit eines direkten Datenflusses zu erhöhen.
Da RDP-Shortpath UDP zum Einrichten eines Datenflusses verwendet, tritt RDP-Shortpath fehl, wenn eine Firewall in Ihrem Netzwerk UDP-Datenverkehr blockiert, und die Verbindung wird auf TCP-basierten Reverse-Connect-Transport zurückgreifen. Azure Virtual Desktop verwendet STUN-Server, die von Azure Communication Services und Microsoft Teams bereitgestellt werden. Es liegt in der Natur des Features, dass eine ausgehende Verbindung von den Sitzungshosts zum Client erforderlich ist. Leider können Sie in den meisten Fällen nicht vorhersagen, wo sich Ihre Benutzer befinden. Daher wird empfohlen, ausgehende UDP-Verbindungen von Ihren Sitzungshosts zum Internet zuzulassen. Um die Anzahl der erforderlichen Ports zu reduzieren, können Sie den Portbereich begrenzen, den Clients für den UDP-Fluss verwenden. Verwenden Sie die folgenden Tabellen als Referenz, wenn Sie Firewalls für RDP-Shortpath konfigurieren.
Wenn in Ihrer Umgebung symmetrische NAT verwendet wird, d. h. die Zuordnung einer einzelnen privaten Quell-IP:Port zu einer eindeutigen öffentlichen Ziel-IP:Port, können Sie eine weitergeleitete 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 Übersetzung der Quellnetzwerkadresse mit virtuellen Netzwerken.
Wir haben einige allgemeine Empfehlungen für erfolgreiche Verbindungen mit 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 steht, wird der erste gefundene Algorithmus verwendet. Der Benutzer verwendet die Verbindung, die zuerst für diese Sitzung hergestellt wird. Weitere Informationen finden Sie unter Beispielszenarien.
Die folgenden Abschnitte enthalten die Quell-, Ziel- und Protokollanforderungen für Ihre Sitzungshosts und Clientgeräte, die zulässig sein müssen, damit RDP-Shortpath funktioniert.
Hinweis
Microsoft hat den Übergang vom zuvor freigegebenen Subnetz 20.202.0.0/16 zum neuen 51.5.0.0/16 TURN-Relay-IP-Bereich in 39 Azure-Regionen abgeschlossen. Dieses neue Sortiment ist ausschließlich für Azure Virtual Desktop und Windows 365 vorgesehen und trennt es von der Infrastruktur der Azure Communication Services. Das Upgrade wurde entwickelt, um RDP-Shortpath für öffentliche Netzwerke (über TURN/Relay) zu verbessern und eine schnellere, zuverlässigere Konnektivität und eine verbesserte Benutzererfahrung zu ermöglichen.
Hinweis
TURN-basierte Verbindungen sind anfällig für Verbindungsabbrüche bei TURN-Relais-Updates. Diese Updates erfolgen in der Regel während geplanter Wartungsfenster, können aber aufgrund dringender Korrekturen der Azure-Infrastruktur gelegentlich auch außerhalb des geplanten Zeitfensters erfolgen.
In allen oben genannten Szenarien stellt der Client innerhalb weniger Sekunden automatisch die Verbindung wieder her.
Virtuelles Netzwerk des Sitzungshosts
In der folgenden Tabelle sind die Quell-, Ziel- und Protokollanforderungen für RDP-Shortpath für Ihr virtuelles Sitzungshostnetzwerk aufgeführt.
| Name |
Quelle |
Quellport |
Ziel |
Zielport |
Protokoll |
Aktion |
| STUN Direktverbindung |
Subnetz der VM |
Any |
Any |
1024 – 65535
(Standard 49152-65535) |
UDP |
Zulassen |
| STUN/TURN-Relais |
Subnetz der VM |
Any |
51.5.0.0/16 |
3478 |
UDP |
Zulassen |
Clientnetzwerk
In der folgenden Tabelle sind die Anforderungen an Quelle, Ziel und Protokoll für Ihre Clientgeräte aufgeführt.
| Name |
Quelle |
Quellport |
Ziel |
Zielport |
Protokoll |
Aktion |
| STUN Direktverbindung |
Clientnetzwerk |
Any |
Öffentliche IP-Adressen, die dem NAT-Gateway oder der Azure Firewall zugewiesen sind (bereitgestellt vom STUN-Endpunkt) |
1024 – 65535
(Standard 49152-65535) |
UDP |
Zulassen |
| STUN/TURN-Relais |
Clientnetzwerk |
Any |
51.5.0.0/16 |
3478 |
UDP |
Zulassen |
Wichtig
Der dedizierte TURN-Relay-IP-Bereich für Azure Government ist 20.140.236.0/22. RDP-Shortpath über TURN befindet sich derzeit in der öffentlichen Vorschau in Azure Government. Kunden können das Feature mithilfe des Validierungsrings ausprobieren.
Virtuelles Netzwerk des Sitzungshosts
In der folgenden Tabelle sind die Quell-, Ziel- und Protokollanforderungen für RDP-Shortpath für Ihr virtuelles Sitzungshostnetzwerk aufgeführt.
| Name |
Quelle |
Quellport |
Ziel |
Zielport |
Protokoll |
Aktion |
| STUN Direktverbindung |
Subnetz der VM |
Any |
Any |
1024 – 65535
(Standard: 49152-65535) |
UDP |
Zulassen |
| STUN/TURN-Relais |
Subnetz der VM |
Any |
20.140.236.0/22 |
3478 |
UDP |
Zulassen |
Clientnetzwerk
In der folgenden Tabelle sind die Anforderungen an Quelle, Ziel und Protokoll für Ihre Clientgeräte aufgeführt.
| Name |
Quelle |
Quellport |
Ziel |
Zielport |
Protokoll |
Aktion |
| STUN Direktverbindung |
Clientnetzwerk |
Any |
Öffentliche IP-Adressen, die dem NAT-Gateway oder der Azure Firewall zugewiesen sind (bereitgestellt vom STUN-Endpunkt) |
1024 – 65535
(Standard: 49152-65535) |
UDP |
Zulassen |
| STUN/TURN-Relais |
Clientnetzwerk |
Any |
20.140.236.0/22 |
3478 |
UDP |
Zulassen |
Teredo-Support
Obwohl Teredo für RDP-Shortpath nicht erforderlich ist, fügt er zusätzliche NAT-Traversal-Kandidaten hinzu und erhöht die Wahrscheinlichkeit einer erfolgreichen RDP-Shortpath-Verbindung in reinen IPv4-Netzwerken. Informationen zum Aktivieren von Teredo auf Sitzungshosts und Clients finden Sie unter Aktivieren der Teredo-Unterstützung.
UPnP-Unterstützung
Um die Chancen auf eine direkte 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 in der Regel auf Routern verfügbar, die sich in der Regel in einem Heimnetzwerk befinden. UPnP ist auf den meisten Heimroutern und Access Points standardmäßig aktiviert, aber häufig ist es 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 Konfigurationen mit Tunnelerzwingung, wenn Ihre Benutzer über das Internet auf Azure Virtual Desktop zugreifen.
Stellen Sie sicher, dass Sie keine doppelten NAT- oder CGN-Konfigurationen (Carrier-Grade-NAT) verwenden.
Empfehlen Sie Ihren Benutzern, UPnP auf ihren Heimroutern nicht zu deaktivieren.
Vermeiden Sie die Verwendung von Cloudpaketprüfungsdiensten.
Vermeiden Sie die Verwendung von TCP-basierten VPN-Lösungen.
IPv6-Konnektivität oder Teredo aktivieren.
Verbindungssicherheit
RDP-Shortpath erweitert die RDP-Multitransportfunktionen. Es ersetzt nicht den umgekehrten Transport, sondern ergänzt ihn. Das Brokering der ersten Sitzung 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 wenn erfolgreich eingerichtet, wird der Reverse-Connect-Transport verworfen, und der gesamte Datenverkehr fließt über den RDP-Shortpath.
RDP-Shortpath verwendet eine sichere Verbindung mit TLS über zuverlässiges UDP zwischen dem Client und dem Sitzungshost unter Verwendung der Zertifikate des Sitzungshosts. Das für die RDP-Verschlüsselung verwendete Zertifikat wird standardmäßig während der Bereitstellung vom Betriebssystem selbst generiert. Azure Virtual Desktop unterstützt derzeit nicht die Verwendung eines Zertifikats, das von einer Zertifizierungsstelle ausgestellt wurde.
Beispielszenarien
Hier sind einige Beispielszenarien, die zeigen, wie Verbindungen ausgewertet werden, um zu entscheiden, ob RDP-Shortpath in verschiedenen Netzwerktopologien verwendet wird.
Szenario 1
Eine UDP-Verbindung kann nur zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk (Internet) hergestellt werden. Eine direkte Verbindung, z. B. ein VPN, ist nicht verfügbar. UDP wird über eine Firewall oder ein NAT-Gerät zugelassen.
Szenario 2
Eine Firewall oder ein NAT-Gerät blockiert eine direkte UDP-Verbindung, aber eine weitergeleitete UDP-Verbindung kann mithilfe von TURN zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk (Internet) weitergeleitet werden. Eine andere direkte Verbindung, z. B. ein VPN, ist nicht verfügbar.
Szenario 3
Eine UDP-Verbindung kann zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk oder über 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 sehen und jede Route auswerten und die Route mit der niedrigsten Latenz auswählen.
In diesem Beispiel wird eine UDP-Verbindung über RDP-Shortpath für öffentliche Netzwerke über die direkte VPN-Verbindung hergestellt, da diese die niedrigste Latenz aufweist, wie durch die grüne Linie dargestellt.
Szenario 4
Sowohl RDP-Shortpath für öffentliche als auch verwaltete Netzwerke sind aktiviert. Eine UDP-Verbindung kann zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk oder über eine direkte VPN-Verbindung hergestellt werden. Wenn der Client die Verbindung initiiert, wird gleichzeitig versucht, eine Verbindung über 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 Verbindung, die zuerst für diese Sitzung hergestellt wird.
Da das Durchlaufen eines öffentlichen Netzwerks mehr Schritte erfordert, z. B. ein NAT-Gerät, einen Lastenausgleich oder einen STUN-Server, ist es wahrscheinlich, dass der zuerst gefundene Algorithmus die Verbindung über RDP-Shortpath für verwaltete Netzwerke auswählt und zuerst eingerichtet wird.
Szenario 5
Eine UDP-Verbindung kann zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk oder über 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-Verkehr blockieren. Das Blockieren einer Route würde sicherstellen, dass immer der verbleibende Pfad 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
Sowohl RDP-Shortpath für öffentliche Netzwerke als auch für verwaltete Netzwerke sind konfiguriert, aber eine UDP-Verbindung konnte nicht ü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 weitergeleitete UDP-Verbindung kann mithilfe von TURN zwischen dem Clientgerät und dem Sitzungshost über ein öffentliches Netzwerk (Internet) weitergeleitet werden.
Szenario 7
Sowohl RDP-Shortpath für öffentliche als auch verwaltete Netzwerke sind konfiguriert, aber eine UDP-Verbindung konnte nicht hergestellt werden. In diesem instance schlägt RDP-Shortpath fehl, und die Verbindung wird auf TCP-basierten Reverse-Connect-Transport zurückgreifen.
Nächste Schritte
