Freigeben über

Grundlegendes zur Netzwerkkonnektivität für Azure Virtual Desktop

  • Artikel

Azure Virtual Desktop hostet Clientsitzungen auf Sitzungshosts, die in Azure ausgeführt werden. Microsoft verwaltet Teile der Dienste im Auftrag 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: Netzwerkverbindungen von Azure Virtual Desktop

Sitzungskonnektivität

Azure Virtual Desktop verwendet Remotedesktopprotokoll (RDP), um Remotefunktionen für die Anzeige und Eingabe über Netzwerkverbindungen bereitzustellen. RDP wurde anfänglich mit Windows NT 4.0 Terminal Server Edition veröffentlicht und entwickelte sich mit jedem Release von Microsoft Windows und Windows Server kontinuierlich weiter. Von Anfang an wurde RDP so entwickelt, dass es vom zugrunde liegenden Transportstapel unabhängig ist, und heute unterstützt es mehrere Arten von Transporten.

Reverse Connection-Transport

Azure Virtual Desktop verwendet den Reverse Connection-Transport zum Einrichten der Remotesitzung und für den Transport des RDP-Datenverkehrs. Im Gegensatz zu Bereitstellungen der lokalen Remotedesktopdienste verwendet der Reverse Connection-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

Beim Start des Azure Virtual Desktop-Sitzungshosts richtet der Remote Desktop Agent Loader-Dienst den beständigen Kommunikationskanal des Azure Virtual Desktop-Brokers ein. Dieser Kommunikationskanal überlagert eine sichere TLS-Verbindung (Transport Layer Security) und fungiert als Bus für den Dienstnachrichtenaustausch zwischen Sitzungshost und Azure Virtual Desktop-Infrastruktur.

Clientverbindungssequenz

Die Clientverbindungssequenz lautet wie folgt:

  1. Benutzer*innen abonnieren über einen unterstützten Azure Virtual Desktop-Client einen Azure Virtual Desktop-Arbeitsbereich.

  2. Microsoft Entra authentifiziert den oder die Benutzer*in und gibt das Token für die Enumeration der für eine*n Benutzer*in verfügbaren Ressourcen zurück.

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

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

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

  6. Der Client speichert die Verbindungskonfiguration für jede verfügbare Ressource in einem Satz von .rdp-Dateien.

  7. Wenn ein Benutzer die Ressource zum Verbinden auswählt, verwendet der Client die zugehörige .rdp-Datei, stellt eine sichere TLS 1.2-Verbindung mit einer Azure Virtual Desktop-Gatewayinstanz mithilfe von Azure Front Door her und übergibt die Verbindungsinformationen. Die Wartezeit aller Gateways wird ausgewertet, und die Gateways werden in Gruppen von 10 ms unterteilt. Das Gateway mit der niedrigsten Latenz und 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 Remotedesktopstack initiiert eine TLS 1.2-Verbindung mit derselben Azure Virtual Desktop-Gatewayinstanz, die vom Client verwendet wird.

  11. Nachdem sowohl der Client als auch der Sitzungshost mit dem Gateway verbunden sind, beginnt das Gateway mit der Übermittlung der Daten zwischen beiden Endpunkten. Mit dieser Verbindung wird der grundlegende Reverse Connection-Transport für die RDP-Verbindung über einen geschachtelten Tunnel festgelegt. Dabei wird die einvernehmlich vereinbarte TLS-Version (bis zu TLS 1.3) verwendet, 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 von der hergestellten Verbindung und den Funktionen des Clients und Sitzungshosts ab:

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

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

Standardmäßig wird das Zertifikat, das für die RDP-Verschlüsselung verwendet wird, vom Betriebssystem bei der Bereitstellung selbst generiert. Sie können auch zentral verwaltete Zertifikate bereitstellen, die von einer Unternehmenszertifizierungsstelle ausgestellt wurden. Weitere Informationen zum Konfigurieren von Zertifikaten finden Sie unter Zertifikatskonfigurationen für Remotedesktop-Listener.

Nächste Schritte