Teilen über

Grundlegendes zur Netzwerkkonnektivität von Azure Virtual Desktop

Azure Virtual Desktop hostet Clientsitzungen auf Sitzungshosts, die in Azure ausgeführt werden. Microsoft verwaltet Teile der Dienste im Namen des Kunden und stellt sichere Endpunkte zum Verbinden von Clients und Sitzungshosts bereit. Das folgende Diagramm bietet eine allgemeine Übersicht über die von Azure Virtual Desktop verwendeten Netzwerkverbindungen.

Diagramm: Azure Virtual Desktop Network Connections

Sitzungskonnektivität

Azure Virtual Desktop stellt mittels RDP (Remote Desktop Protocol) Remoteanzeige- und Eingabefunktionen über Netzwerkverbindungen zur Verfügung. RDP wurde ursprünglich mit Windows NT 4.0 Terminal Server Edition veröffentlicht und wurde mit jedem Microsoft Windows- und Windows Server-Release kontinuierlich weiterentwickelt. Von Anfang an entwickelte sich RDP als unabhängig von seinem zugrunde liegenden Transportstapel und unterstützt heute mehrere Transporttypen.

Umgekehrter Verbindungstransport

Azure Virtual Desktop verwendet reverse connect-Transport zum Einrichten der Remotesitzung und zum Übertragen von RDP-Datenverkehr. Im Gegensatz zu den bereitstellungen der lokalen Remotedesktopdienste verwendet der Reverse Connect-Transport keinen TCP-Listener, um eingehende RDP-Verbindungen zu empfangen. Stattdessen wird die ausgehende Konnektivität mit der Azure Virtual Desktop-Infrastruktur über die HTTPS-Verbindung verwendet.

Kommunikationskanal des Sitzungshosts

Nach dem Start des Azure Virtual Desktop-Sitzungshosts richtet der Remotedesktop-Agent-Ladedienst den beständigen Kommunikationskanal des Azure Virtual Desktop-Brokers ein. Dieser Kommunikationskanal ist über eine sichere TLS-Verbindung (Transport Layer Security) aufgeteilt und dient als Bus für den Austausch von Dienstnachrichten zwischen dem Sitzungshost und der Azure Virtual Desktop-Infrastruktur.

Clientverbindungssequenz

Die Clientverbindungssequenz sieht wie folgt aus:

  1. Mithilfe der unterstützten Azure Virtual Desktop-Clientbenutzer abonniert den Azure Virtual Desktop-Arbeitsbereich.

  2. Microsoft Entra authentifiziert den Benutzer und gibt das Token zurück, das zum Aufzählen der für einen Benutzer verfügbaren Ressourcen verwendet wird.

  3. Der Client übergibt das Token an den Azure Virtual Desktop-Feedabonnementdienst.

  4. Der Azure Virtual Desktop-Feedabonnementdienst überprüft das Token.

  5. Der Azure Virtual Desktop-Feedabonnementdienst übergibt die Liste der verfügbaren Desktops und Anwendungen in Form einer digital signierten Verbindungskonfiguration an den Client zurück.

  6. Der Client speichert die Verbindungskonfiguration für jede verfügbare Ressource in einer Gruppe von .rdp Dateien.

  7. Wenn ein Benutzer die zu verbindende Ressource auswählt, verwendet der Client die zugeordnete .rdp Datei und stellt eine sichere TLS 1.2-Verbindung mit einem Azure Virtual Desktop-Gateway instance mithilfe von Azure Front Door her und übergibt die Verbindungsinformationen. Die Latenz aller Gateways wird ausgewertet, und die Gateways werden in Gruppen von 10 ms unterteilt. Das Gateway mit der niedrigsten Latenz und dann der niedrigsten Anzahl vorhandener Verbindungen wird ausgewählt.

  8. Das Azure Virtual Desktop-Gateway überprüft die Anforderung und fordert den Azure Virtual Desktop-Broker auf, die Verbindung zu orchestrieren.

  9. Der Azure Virtual Desktop-Broker identifiziert den Sitzungshost und verwendet den zuvor eingerichteten beständigen Kommunikationskanal, um die Verbindung zu initialisieren.

  10. Der Remotedesktopstapel initiiert eine TLS 1.2-Verbindung mit demselben Azure Virtual Desktop-Gateway instance, wie sie vom Client verwendet wird.

  11. Nachdem sowohl der Client als auch der Sitzungshost mit dem Gateway verbunden sind, beginnt das Gateway mit der Weiterleitung der Daten zwischen beiden Endpunkten. Mit dieser Verbindung wird der grundlegende Reverse Connect-Transport für die RDP-Verbindung über einen geschachtelten Tunnel unter Verwendung der gemeinsam vereinbarten TLS-Version bis TLS 1.3 hergestellt, die zwischen Client und Sitzungshost unterstützt und aktiviert wird.

  12. Nachdem der Basistransport festgelegt wurde, startet der Client den RDP-Handshake.

Verbindungssicherheit

TLS wird für alle Verbindungen verwendet. Die verwendete Version hängt davon ab, welche Verbindung hergestellt wird und welche Funktionen der Client und des Sitzungshosts verfügbar sind:

  • Für alle Verbindungen, die von den Clients und Sitzungshosts mit den Azure Virtual Desktop-Infrastrukturkomponenten initiiert werden, wird TLS 1.2 verwendet. Azure Virtual Desktop verwendet dieselben TLS 1.2-Verschlüsselungen wie Azure Front Door. Es ist wichtig, dass sowohl Clientcomputer als auch Sitzungshosts diese Verschlüsselungen verwenden können.

  • Für den Reverse Connect-Transport stellen sowohl der Client als auch der Sitzungshost eine Verbindung mit dem Azure Virtual Desktop-Gateway her. Nachdem die TCP-Verbindung für den Basistransport hergestellt wurde, überprüft der Client oder Sitzungshost das Zertifikat des Azure Virtual Desktop-Gateways. RDP stellt dann eine geschachtelte TLS-Verbindung zwischen Client und Sitzungshost unter Verwendung der Zertifikate des Sitzungshosts her. Die TLS-Version verwendet die gemeinsam vereinbarte TLS-Version, die zwischen Client und Sitzungshost unterstützt und aktiviert wird, bis tls 1.3. TLS 1.3 wird ab Windows 11 (21H2) und Windows Server 2022 unterstützt. Weitere Informationen finden Sie unter Windows 11 TLS-Unterstützung. Wenden Sie sich bei anderen Betriebssystemen an den Betriebssystemanbieter, um TLS 1.3-Unterstützung zu erhalten.

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 der Unternehmenszertifizierungsstelle ausgestellt wurden. Weitere Informationen zum Konfigurieren von Zertifikaten finden Sie unter Konfigurationen von Remotedesktoplistenerzertifikaten.

Nächste Schritte