Netzwerktopologie und -konnektivität für Azure Virtual Desktop

Das Entwerfen und Implementieren von Azure Virtual Desktop-Netzwerkfunktionen ist für Ihre Azure Virtual Desktop-Zielzone entscheidend. Dieser Artikel basiert auf den architektonischen Gestaltungsprinzipien und Richtlinien des Cloud Adoption Framework für Azure für Zielzonen auf Unternehmensniveau sowie auf Empfehlungen für die Verwaltung von Netzwerktopologie und Konnektivität im großen Maßstab.

Zu den Designgrundlagen gehören:

• Hybridintegration für Konnektivität zwischen lokalen, Multi-Cloud-, Edge-Umgebungs- und globalen Benutzern. Weitere Informationen finden Sie unter Hybrid- und Multi-Cloud-Unterstützung auf Unternehmensniveau.
• Bedarfsgerechte Leistung und Zuverlässigkeit für konsistente und skalierbare Workloads mit niedriger Latenz.
• Zero Trust-basierte Netzwerksicherheit zur Unterstützung des Schutzes der Netzwerkgrenzen und des Datenverkehrsflusses. Weitere Informationen finden Sie unter Strategien bezüglich der Netzwerksicherheit in Azure.
• Erweiterungsfähigkeit für eine problemlose Ausweitung des Netzwerks ohne Umgestaltung des Designs.

Netzwerkkomponenten und -konzepte

• Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. Mithilfe von Virtual Network können viele Arten von Azure-Ressourcen, wie z. B. virtuelle Azure-Computer, miteinander, mit dem Internet und mit lokalen Rechenzentren kommunizieren. Virtuelle Netzwerke ähneln den herkömmlichen Netzwerken, die Sie in Ihrem eigenen Rechenzentrum betreiben. Aber ein virtuelles Netzwerk bietet die Vorteile der Azure-Infrastruktur von Skalierung, Verfügbarkeit und Isolation.
• Eine Hub-Spoke-Netzwerktopologie ist eine Art Netzwerkarchitektur, in der ein virtuelles Hub-Netzwerk als zentraler Punkt der Konnektivität mit mehreren virtuellen Spoke-Netzwerken fungiert. Der Hub kann auch als Verbindungspunkt mit Ihren lokalen Netzwerken genutzt werden. Die virtuellen Spoke-Netzwerke stellen eine Peeringverbindung mit dem Hub her und helfen bei der Isolierung von Workloads.
• Azure Virtual WAN ist ein Netzwerkdienst, der Netzwerk-, Sicherheits- und Routingfunktionen in einer einzigen Bedienoberfläche vereint.
• Ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) ist ein Netzwerkgerät, das Funktionen wie Konnektivität, Anwendungsbereitstellung, WAN-Optimierung (Wide Area Network) und Sicherheit unterstützt. Zu den NVAs gehören Azure Firewall und Azure Load Balancer.
• In einem erzwungenem Tunnelingszenario wird der gesamte internetgebundene Datenverkehr, der von Azure-VMs stammt, weitergeleitet oder „gezwungen“, eine Inspektions- und Überwachungsanwendung zu durchlaufen. Nicht autorisierter Zugriff auf das Internet kann ohne Datenverkehrsüberwachung oder -überprüfung potenziell zur Offenlegung von Informationen oder anderen Arten von Sicherheitsverletzungen führen.
• Netzwerksicherheitsgruppen werden verwendet, um Netzwerkdatenverkehr von und zu Azure-Ressourcen in einem Azure Virtual Network zu filtern. Eine Netzwerksicherheitsgruppe enthält Sicherheitsregeln, die eingehenden Netzwerkdatenverkehr an verschiedene Typen von Azure-Ressourcen oder ausgehenden Netzwerkdatenverkehr von diesen zulassen oder verweigern.
• Anwendungssicherheitsgruppen bieten die Möglichkeit, dass Sie die Netzwerksicherheit als natürliche Erweiterung einer Anwendungsstruktur konfigurieren. Sie können Anwendungssicherheitsgruppen zum Gruppieren von VMs verwenden und basierend auf diesen Gruppen Netzwerksicherheitsrichtlinien definieren. Sie können Ihre Sicherheitsrichtlinie nach Bedarf wiederverwenden, ohne dass Sie explizite IP-Adressen manuell pflegen müssen.
• Benutzerdefinierte Routen (User-Defined Routes, UDRs) können zum Überschreiben von Azure-Standardsystemrouten verwendet werden. Sie können UDRs auch verwenden, um einer Subnetzroutentabelle zusätzliche Routen hinzuzufügen.
• Remote Desktop Protocol Shortpath (RDP Shortpath) ist ein Feature von Azure Virtual Desktop, das auf dem Universal Rate Control Protocol (URCP) basiert. RDP Shortpath richtet einen direkten Transport ein, der auf dem User Datagram Protocol (UDP) zwischen einem unterstützten Windows Remote Desktop-Client und Azure Virtual Desktop-Sitzungshosts basiert. URCP verbessert UDP-Verbindungen, indem aktive Überwachung von Netzwerkbedingungen und QoS-Funktionen (Quality-of-Service) bereitgestellt wird.
• Azure Private Link mit Azure Virtual Desktop (Vorschau) bietet ihnen die Möglichkeit, einen privaten Endpunkt in Azure zu verwenden, um Sitzungshosts mit dem Azure Virtual Desktop-Dienst zu verbinden. Mit Private Link wird der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Azure Virtual Desktop-Dienst über das Microsoft Backbone-Netzwerk weitergeleitet. Daher müssen Sie keine Verbindung mit dem öffentlichen Internet herstellen, um auf Azure Virtual Desktop-Dienste zuzugreifen.

Szenarien für den Netzwerkbetrieb

Um die Azure Virtual Desktop-Zielzone einzurichten, sind das Design und die Implementierung von Netzwerkfunktionen von wesentlicher Bedeutung. Die Azure-Netzwerkprodukte und -Dienste unterstützen eine Vielzahl von Funktionen. Die von Ihnen gewählte Architektur und die Art und Weise, wie Sie Dienste strukturieren, hängen von den Arbeitslasten, der Governance und den Anforderungen Ihrer Organisation ab.

Die folgenden Hauptanforderungen und -überlegungen wirken sich auf Ihre Entscheidung zur Bereitstellung von Azure Virtual Desktop aus:

• Anforderungen für Interneteingang und -ausgang.
• NVA-Verwendung in der aktuellen Architektur.
• Azure Virtual Desktop-Konnektivität mit einem standardmäßigen Hub-VNet oder Virtual WAN-Hub.
• Das Verbindungsmodell des Sitzungshosts. Sie können ein systemeigenes Modell oder RDP Shortpath verwenden.
• Anforderungen an die Datenverkehrsuntersuchung für:
  • Internetausgang aus Azure Virtual Desktop.
  • Interneteingang in Azure Virtual Desktop.
  • Azure Virtual Desktop-Datenverkehr zu lokalen Rechenzentren.
  • Azure Virtual Desktop-Datenverkehr zu anderen virtuellen Netzwerkinstanzen.
  • Datenverkehr innerhalb des virtuellen Azure Virtual Desktop-Netzwerks.

Das häufigste Netzwerkszenario für Azure Virtual Desktop ist die Hub-and-Spoke-Topologie mit Hybridkonnektivität.

Szenario 1: Hub-and-Spoke mit Hybridkonnektivität

In diesem Szenario wird das standardmäßige Sitzungshost verbindungs modell verwendet.

Kundenprofil

Dieses Szenario ist ideal geeignet, wenn folgende Voraussetzungen erfüllt sind:

• Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure Virtual Desktop-Netzwerken und anderen virtuellen Azure-Netzwerken.
• Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure Virtual Desktop-Netzwerken und lokalen Rechenzentren.
• Sie benötigen keine Datenverkehrsüberprüfung des ausgehenden Internetdatenverkehrs aus Azure Virtual Desktop-Netzwerken.
• Sie müssen die öffentlichen IP-Adressen, die während der Quellnetzwerkadressübersetzung (SNAT) für ausgehende Internetverbindungen von Azure Virtual Desktop verwendet werden, nicht steuern.
• Sie erzwingen keinen internen Azure Virtual Desktops-Netzwerkdatenverkehr.
• Sie verfügen über bereits vorhandene Hybridkonnektivität mit lokalen Umgebungen, entweder über Azure ExpressRoute oder über eine virtuelle private S2S (Site-to-Site)-VPN.
• Sie verfügen über bereits vorhandene Active Directory Domain Services (AD DS) und benutzerdefinierte DNS Server (Domain Name System).
• Sie nutzen Azure Virtual Desktop mit Standardverbindungsmodell, nicht RDP Shortpath.

Komponenten der Architektur

Sie können dieses Szenario mit folgenden Komponenten implementieren:

• AD DS-Server und benutzerdefinierte DNS-Server.
• Netzwerksicherheitsgruppen:
• Azure Network Watcher.
• Ausgehende Internetverbindungen über einen Azure Virtual Network-Standardpfad.
• Expressroute oder virtuelle Netzwerkgateway-VPN für Hybridkonnektivität zu lokalen Netzwerken.
• Eine Zone mit privatem Azure-DNS.
• Private Azure-Endpunkte.
• Azure Files-Speicherkonten.
• Azure Key Vault:

Überlegungen

• In diesem Szenario ist keine direkte Netzwerkkonnektivität zwischen einem Client und einem öffentlichen oder privaten Sitzungshost möglich. In diesem Szenario können Sie RDP Shortpath nicht verwenden.
• Das Azure Virtual Desktop-Steuerungsebenen gateway, das einen öffentlichen Endpunkt verwendet, verwaltet Clientverbindungen. Daher können Azure Virtual Desktop-Clients ausgehende Verbindungen mit erforderlichen Azure Virtual Desktop-URLs erstellen. Weitere Informationen zu erforderlichen URLs finden Sie im Abschnitt Internet dieses Artikels und in Erforderliche URLs für Azure Virtual Desktop.
• Es sind keine öffentlichen IP-Adressen oder andere öffentliche eingehende Pfade zu Sitzungshosts erforderlich. Datenverkehr von Clients zu Sitzungshosts fließt über das Azure Virtual Desktop-Steuerebenengateway.
• Es gibt kein virtuelles Netzwerk-Peering zwischen Azure Virtual Desktop-Spokes. Der gesamte Datenverkehr durchläuft den Konnektivitätshub.
• Die ausgehenden Internetverbindungen von Azure Virtual Desktop-Sitzungshosts durchlaufen den standardmäßigen NAT-Prozess (Azure Outbound Network Address Translation). Dynamische öffentliche Azure-IP-Adressen werden verwendet. Kunden haben keine Kontrolle über die ausgehenden öffentlichen IP-Adressen, die verwendet werden.
• Verbindungen von Sitzungshosts mit Azure Files-Speicherkonten werden mithilfe privater Endpunkte hergestellt.
• Private Azure DNS-Zonen werden verwendet, um private Endpunktnamespaces für die folgenden Dienste aufzulösen:
  • Azure Files-Speicherkonten, die den Namen privatelink.file.core.windows.net verwenden
  • Schlüsseltresore, die den Namen privatelink.vaultcore.azure.net verwenden
• Die Netzwerkfilterung wird für dieses Szenario nicht erzwungen. In allen Subnetzen werden jedoch Netzwerksicherheitsgruppen platziert, sodass Sie den Datenverkehr überwachen und Einblicke ableiten können. In der Netzwerküberwachung werden Datenverkehrsanalysen und das Feature für die Ablaufprotokollierung der Netzwerksicherheitsgruppe zu diesen Zwecken verwendet.

Szenario 2: Hub-und-Spoke mit hybrider Konnektivität über verwaltete Netzwerke mithilfe von RDP Shortpath

Ausführliche Anleitungen zur Bereitstellung finden Sie unter RDP Shortpath-Konnektivität für verwaltete Netzwerke.

Kundenprofil

Dieses Szenario ist ideal geeignet, wenn folgende Voraussetzungen erfüllt sind:

• Sie möchten die Anzahl der Verbindungen über das Internet mit Azure Virtual Desktop-Sitzungshosts einschränken.
• Sie verfügen über bereits vorhandene Hybridkonnektivität von einer lokalen Umgebung zu Azure, entweder über ExpressRoute oder über ein S2S- oder P2S-VPN (Point-to-Site).
• Sie verfügen über eine direkte Netzwerkverbindung zwischen RDP-Clients und Azure Virtual Desktop-Hosts. In der Regel wird eines der folgenden Setups in diesem Szenario verwendet:
  • Lokale Netzwerke, die an Azure Virtual Desktop Azure-Netzwerke weitergeleitet werden
  • Client-VPN-Verbindungen, die an virtuelle Azure-Desktop-Azure-Netzwerke weitergeleitet werden
• Sie müssen die Bandbreitennutzung von VM-Hosts über private Netzwerke, wie z. B. VPNs oder ExpressRoute, einschränken.
• Sie möchten Azure Virtual Desktop-Datenverkehr in Ihrem Netzwerk priorisieren.
• Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure Virtual Desktop-Netzwerken und anderen virtuellen Azure-Netzwerken.
• Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure Virtual Desktop-Netzwerken und lokalen Rechenzentren.
• Sie verfügen bereits über benutzerdefinierte AD DS- und DNS-Server.

Komponenten der Architektur

Sie können dieses Szenario mit folgenden Komponenten implementieren:

• Expressroute oder virtuelle Netzwerkgateway-VPN für Hybridkonnektivität zu lokalen Umgebungen mit ausreichend Bandbreite.
• AD DS-Server und benutzerdefinierte DNS-Server.
• Netzwerksicherheitsgruppen:
• Ausgehende Internetverbindungen über einen Azure Virtual Network-Standardpfad.
• Domain-Gruppenrichtlinienobjekte (Domain Group Policy Objects, GPOs) oder lokale GPOs.
• Azure Files-Speicherkonten.
• Private Azure-Endpunkte.
• Eine Zone mit privatem Azure-DNS.

Überlegungen

• Hybridkonnektivität muss über eine VPN oder ExpressRoute mit RDP-Client-Direct-Netzwerkkonnektivität mit privaten VM-Hosts am Port 3390 verfügbar sein.

Hinweis

Für verwaltete Netzwerke kann der standardmäßige UDP-Port geändert werden.

• Ein Domänen-GPO oder ein lokales Gruppenrichtlinienobjekt muss verwendet werden, um UDP über verwaltete Netzwerke zu aktivieren.
• Hybridkonnektivität muss über ausreichende Bandbreite verfügen, um direkte UDP-Verbindungen mit VM-Hosts zu ermöglichen.
• Hybridkonnektivität muss über direktes Routing verfügen, um Verbindungen mit VM-Hosts zuzulassen.
• Das Azure Virtual Desktop-Steuerungsebenen gateway, das einen öffentlichen Endpunkt verwendet, verwaltet Clientverbindungen. Daher können Azure Virtual Desktop-Clients ausgehende Verbindungen mit erforderlichen Azure Virtual Desktop-URLs erstellen. Weitere Informationen zu erforderlichen URLs finden Sie im Abschnitt Internet dieses Artikels und in Erforderliche URLs für Azure Virtual Desktop.
• Es sind keine öffentlichen IP-Adressen oder andere öffentliche eingehende Pfade zu Sitzungshosts erforderlich. Datenverkehr von Clients zu Sitzungshosts fließt über das Azure Virtual Desktop-Steuerebenengateway.
• Die ausgehende Internetverbindung von Azure Virtual Desktop-Sitzungshosts durchläuft den standardmäßigen ausgehenden Azure-NAT-Prozess. Dynamische öffentliche Azure-IP-Adressen werden verwendet. Kunden haben keine Kontrolle über die ausgehenden öffentlichen IP-Adressen, die verwendet werden.
• Verbindungen von Sitzungshosts mit Azure Files-Speicherkonten werden mithilfe privater Endpunkte hergestellt.
• Private Azure-DNS-Zonen werden verwendet, um private Endpunktnamespaces aufzulösen.
• Die Netzwerkfilterung wird für dieses Szenario nicht erzwungen. In allen Subnetzen werden jedoch Netzwerksicherheitsgruppen platziert, sodass Sie den Datenverkehr überwachen und Einblicke ableiten können. In der Netzwerküberwachung werden Datenverkehrsanalysen und das Feature für die Ablaufprotokollierung der Netzwerksicherheitsgruppe zu diesen Zwecken verwendet.

Hinweis

Derzeit unterstützt Azure Virtual Desktop nicht gleichzeitig die Verwendung von Private Link und RDP Shortpath.

Szenario 3: Hub-und-Spoke mit öffentlichen Netzwerken mit von RDP Shortpath

Ausführliche Anleitungen zur Bereitstellung finden Sie unter RDP Shortpath-Konnektivität für öffentliche Netzwerke.

Kundenprofil

Dieses Szenario ist ideal geeignet, wenn folgende Voraussetzungen erfüllt sind:

• Ihre Azure Virtual Desktop-Clientverbindungen durchlaufen das öffentliche Internet. Typische Szenarien umfassen geschäftliche Benutzer, Remote-Zweigstellenbenutzer, die nicht mit Unternehmensnetzwerken verbunden sind, und Remoteunternehmerbenutzer.
• Sie verfügen über Verbindungen mit hoher Latenz oder geringer Bandbreite zu Azure Virtual Desktops-Sitzungshosts.
• Sie müssen die Bandbreitennutzung von Azure Virtual Desktop-Sitzungshosts über QoS-Netzwerkrichtlinien einschränken.
• Sie möchten Azure Virtual Desktop-Datenverkehr in Ihrem Netzwerk über QoS-Richtlinien priorisieren.
• RDP-Clientverbindungen beginnen von Netzwerken mit inkonsistenter Bandbreite und Geschwindigkeit.
• Sie verfügen über direkte ausgehende Verbindungen von Azure Virtual Desktop-Sitzungshosts. Sie verwenden kein erzwungenes Tunnelrouting über lokale Netzwerke.
• Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure Virtual Desktop-Netzwerken und anderen virtuellen Azure-Netzwerken.
• Sie benötigen keine Datenverkehrsüberprüfung zwischen Azure Virtual Desktop-Netzwerken und lokalen Rechenzentren.
• Sie verfügen bereits über benutzerdefinierte AD DS- und DNS-Server.

Komponenten der Architektur

Sie können dieses Szenario mit folgenden Komponenten implementieren:

• ExpressRoute oder ein virtuelles VPN-Netzwerkgateway für hybride Konnektivität mit lokalen Umgebungen. Dieses Setup ist geeignet, wenn genügend Bandbreite vorhanden ist, um Verbindungen mit lokalen Anwendungen, Daten oder AD DS-Verbindungen zu unterstützen. Es wird nicht empfohlen, erzwungenes Tunneling zu verwenden, um Azure Virtual Desktop-Datenverkehr über lokale Router zu senden.
• AD DS-Server und benutzerdefinierte DNS-Server.
• Netzwerksicherheitsgruppen:
• Network Watcher.
• Ausgehende Internetverbindungen über einen Azure Virtual Network-Standardpfad.
• Domänen-GPOs oder lokale GPOs.
• Azure Files-Speicherkonten.
• Private Azure-Endpunkte.
• Eine Zone mit privatem Azure-DNS.

Überlegungen

• Zulassen der folgenden Arten von Verbindungen:

  • Ausgehende UDP-Verbindungen von Azure Virtual Desktop-Sitzungshosts mit den Azure Virtual Desktop Session Traversal Utilities for NAT (STUN) und Traversal Using Relay NAT (TURN)-Diensten am Port 3478
  • UDP-Verbindungen von RDP-Clients im Portbereich 49152–65535

  Die Einstellung, die diese Verbindungen konfiguriert, ist standardmäßig aktiviert und verwaltet die gleiche Verschlüsselungsebene wie TCP (Transmission Control Protocol). Informationen zum Einschränken von RDP-Clientportbereichen finden Sie unter Einschränken des Portbereichs bei Verwendung von RDP Shortpath für öffentliche Netzwerke.

• Das Azure Virtual Desktop-Steuerungsebenen gateway, das einen öffentlichen Endpunkt verwendet, verwaltet Clientverbindungen. Daher können Azure Virtual Desktop-Clients ausgehende Verbindungen mit erforderlichen Azure Virtual Desktop-URLs erstellen. Weitere Informationen zu erforderlichen URLs finden Sie im Abschnitt Internet dieses Artikels und in Erforderliche URLs für Azure Virtual Desktop.

• Für Consumerrouter, die in der Regel in Heimbenutzernetzwerken zu finden sind, sollte Universal Plug and Play (UPnP) aktiviert sein.

• Es sind keine öffentlichen IP-Adressen oder andere öffentliche eingehende Pfade zu Sitzungshosts erforderlich. Datenverkehr von Clients zu Sitzungshosts fließt über das Azure Virtual Desktop-Steuerebenengateway.

• Die ausgehende Internetverbindung von Azure Virtual Desktop-Sitzungshosts durchläuft den standardmäßigen ausgehenden Azure-NAT-Prozess. Dynamische öffentliche Azure-IP-Adressen werden verwendet. Kunden haben keine Kontrolle über die ausgehenden öffentlichen IP-Adressen, die verwendet werden.

• Sie müssen die DSCP-Markierung (Differenzierter Dienstcodepunkt) auf den Sitzungshosts konfigurieren. Verwenden Sie lokale GPOs oder Domänen-GPOs für diese Konfiguration. Wenn Sie DSCP-Marker verwenden, können Netzwerkgeräte QoS-Richtlinien für Azure Virtual Desktop-Datenverkehr anwenden. Weitere Informationen finden Sie unter Implementieren von Quality of Service (QoS) für Azure Virtual Desktop.

• Verbindungen von Sitzungshosts mit Azure Files (Speicherkonten) werden mithilfe privater Endpunkte hergestellt.

• Private Azure-DNS-Zonen werden verwendet, um private Endpunktnamespaces aufzulösen.

• Die Netzwerkfilterung wird für dieses Szenario nicht erzwungen. In allen Subnetzen werden jedoch Netzwerksicherheitsgruppen platziert, sodass Sie den Datenverkehr überwachen und Einblicke ableiten können. In der Netzwerküberwachung werden Datenverkehrsanalysen und das Feature für die Ablaufprotokollierung der Netzwerksicherheitsgruppe zu diesen Zwecken verwendet.

Allgemeine Designüberlegungen und -empfehlungen

In den folgenden Abschnitten finden Sie einige allgemeine Designüberlegungen und -empfehlungen für die Netzwerktopologie und -konnektivität von Azure Virtual Desktop:

Hub-and-Spoke im Vergleich mit Virtual WAN-Netzwerktopologie

Virtual WAN unterstützt Transitkonnektivität zwischen VPN und ExpressRoute, aber keine Hub-and-Spoke-Topologie.

Identitätsdienste

Die Anforderungen der Identitätsdienstekonnektivität von Azure Virtual Desktop-Sitzungshosts hängen vom Identitätsmodell ab.

• Für Microsoft Entra Domain Services in VMs eingebunden: Azure Virtual Desktop-Netzwerke müssen über eine Verbindung mit dem Netzwerk verfügen, in dem der Identitätsdienst gehostet wird.
• Für in Microsoft Entra ID eingebundene VMs: Azure Virtual Desktop-Sitzungshosts erstellen ausgehende Verbindungen mit öffentlichen Microsoft Entra ID-Endpunkten. Daher sind keine Konfigurationen für private Konnektivität erforderlich.

Domain Name System

Azure Virtual Desktop-Sitzungshosts weisen die gleichen Namensauflösungsanforderungen wie jede andere Infrastruktur wie eine IaaS-Workload (Service) auf. Daher ist eine Verbindung mit benutzerdefinierten DNS-Servern oder Zugriff über eine virtuelle Netzwerkverbindung zu privaten Azure DNS-Zonen erforderlich. Zusätzliche private Azure-DNS-Zonen sind erforderlich, um die privaten Endpunktnamespaces bestimmter Plattform-as-a-Service-Dienste (PaaS) zu hosten, z. B. Speicherkonten und Schlüsselverwaltungsdienste.

Weitere Informationen finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.

Um die Azure Virtual Desktop-Clientkonfiguration des Endbenutzers zu erleichtern, einschließlich des Abonnements für den RDS-Feed (Remote Desktop Services), ist es am besten, die E-Mail-Ermittlung einzurichten. Sie müssen die E-Mail-Ermittlung in der öffentlichen DNS-Domäne einrichten und dann Ihren RDS-Feed abonnieren. Weitere Informationen finden Sie unter Einrichten der E-Mail-Ermittlung, um Ihren RDS-Feed zu abonnieren.

Bandbreite und Wartezeit

Azure Virtual Desktop verwendet RDP. Weitere Informationen zu RDP finden Sie unter Bandbreitenanforderungen für Remotedesktop-Protokoll (RDP).

Die Verbindungswartezeit hängt vom Standort der Benutzer und der virtuellen Computer ab. Azure Virtual Desktop-Dienste werden fortlaufend in neuen geografischen Regionen eingeführt, um die Wartezeit zu verbessern. Um die Latenz zu minimieren, die Azure Virtual Desktop-Clients erleben, können Sie den Azure Virtual Desktop Experience Estimator verwenden. Dieses Tool liefert RTT-Beispiele (Roundtrip Time) von Clients. Sie können diese Informationen verwenden, um Sitzungshosts in der Region zu platzieren, die Endbenutzern am nächsten liegt und die niedrigste RTT hat. Informationen zum Interpretieren von Ergebnissen aus dem Schätzungstool finden Sie unter Analysieren der Verbindungsqualität in Azure Virtual Desktop.

QoS mit RDP Shortpath

RDP Shortpath für verwaltete Netzwerke stellt einen direkten UDP-basierten Transport zwischen Remotedesktopclient und dem Sitzungshost bereit. RDP Shortpath für verwaltete Netzwerke bietet eine Möglichkeit zum Konfigurieren von QoS-Richtlinien für die RDP-Daten. QoS in Azure Virtual Desktop ermöglicht Echtzeit-RDP-Datenverkehr, der Netzwerkverzögerungen erkennt und sich so vor anderen Datenverkehr „vordrängeln“ kann, der weniger wichtig ist.

Sie können RDP Shortpath auf zwei Arten verwenden:

• In verwalteten Netzwerken, bei denen direkte Konnektivität zwischen dem Client und dem Sitzungshost hergestellt wird, wenn Sie eine private Verbindung verwenden, z. B. eine ExpressRoute-Verbindung oder eine VPN.
• In öffentlichen Netzwerken, bei denen eine direkte Verbindung zwischen dem Client und dem Sitzungshost hergestellt wird, wenn eine öffentliche Verbindung verwendet wird. Beispiele für öffentliche Verbindungen sind Heimnetzwerke, Cafés und Hotelnetzwerke. Es gibt zwei mögliche Verbindungstypen, wenn Sie eine öffentliche Verbindung verwenden:

  • Eine direkte UDP-Verbindung zwischen einem Client und einem Sitzungshost, der das STUN-Protokoll verwendet.

  • Eine indirekte UDP-Verbindung, die das TURN-Protokoll mit einem Relay zwischen einem RDP-Client und einem Sitzungshost verwendet. Diese Option wird verwendet, wenn das Gateway oder der Router keine direkten UDP-Verbindungen zulassen.

    Hinweis

    Verwenden von RDP Shortpath für öffentliche Netzwerke mit TURN für Azure Virtual Desktop befindet sich derzeit in der Vorschau. Weitere Informationen finden Sie unter RDP Shortpath für Azure Virtual Desktop.

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, der auf TCP basiert. Alle Verbindungsversuche werden ignoriert, es sei denn, sie stimmen zuerst mit der Reverse-Connect-Sitzung überein.

RDP Shortpath, der auf UDP basiert, wird nach der Authentifizierung eingerichtet. Wenn RDP Shortpath erfolgreich hergestellt wurde, wird der Reverse Connect-Transport getrennt. Anschließend fließen alle Datenverkehrsflüsse über eine der zuvor aufgeführten RDP Shortpath-Methoden.

Weitere Informationen finden Sie unter Implementieren von Quality of Service (QoS) für Azure Virtual Desktop.

Internet

Azure Virtual Desktop-Computeressourcen und -Clients erfordern Zugriff auf bestimmte öffentliche Endpunkte, sodass sie Verbindungen in Richtung Internet benötigen. Netzwerkszenarien wie erzwungenes Tunneling zur Verbesserung der Sicherheit und Filterung werden unterstützt, wenn Azure Virtual Desktop-Anforderungen erfüllt sind.

Informationen zu den Anforderungen für Azure Virtual Desktop-Sitzungshosts und -Clientgeräte finden Sie unter Erforderliche URLs für Azure Virtual Desktop.

Anforderungen an Ports und Protokolle

Die Azure Virtual Desktop-Verbindungsmodelle verwenden die folgenden Ports und Protokolle:

• Standardmodell: 443/TCP
• RDP Shortpath-Modell: 443/TCP und 3390/UDP oder 3478/UDP für das STUN- oder TURN-Protokoll

Business Continuity & Disaster Recovery

Für Geschäftskontinuität und Notfallwiederherstellung ist eine bestimmte Netzwerkeinrichtung erforderlich. Verwenden Sie zum Bereitstellen und Wiederherstellen von Ressourcen in einer Zielumgebung eine der folgenden Konfigurationen:

• Ein Netzwerksetup mit den gleichen Funktionen wie die in der Quellumgebung
• Ein Netzwerksetup mit Konnektivität zu Identitäts- und DNS-Diensten

Nächste Schritte

Erfahren Sie mehr über die Ressourcenorganisation für ein unternehmensweites Azure Virtual Desktop-Szenario.

Ressourcenorganisation