Azure Private Link mit Azure Virtual Desktop
Sie können Azure Private Link mit Azure Virtual Desktop verwenden, um eine private Verbindung mit Ihren Remoteressourcen herzustellen. Durch das Erstellen eines privaten Endpunkts verbleibt der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst im Microsoft-Netzwerk, sodass Sie Ihren Dienst nicht mehr für das öffentliche Internet verfügbar machen müssen. Sie verwenden auch ein VPN oder ExpressRoute für Ihre Benutzer mit dem Remotedesktopclient, um eine Verbindung mit dem virtuellen Netzwerk herzustellen. Die Beibehaltung des Datenverkehrs innerhalb des Microsoft-Netzwerks verbessert die Sicherheit und schützt Ihre Daten. In diesem Artikel wird beschrieben, wie Private Link Ihnen helfen kann, Ihre Azure Virtual Desktop-Umgebung zu schützen.
Wie funktioniert Private Link mit Azure Virtual Desktop?
Azure Virtual Desktop verfügt über drei Workflows mit drei entsprechenden Ressourcentypen zur Verwendung mit privaten Endpunkten. Dies sind die Workflows:
Anfängliche Feedermittlung: Der Client kann alle Arbeitsbereiche ermitteln, die einem Benutzer zugewiesen sind. Um diesen Prozess zu aktivieren, müssen Sie einen einzelnen privaten Endpunkt für die globale Unterressource eines beliebigen Arbeitsbereichs erstellen. Sie können jedoch nur einen privaten Endpunkt in Ihrer gesamten Azure Virtual Desktop-Bereitstellung erstellen. Dieser Endpunkt erstellt DNS-Einträge (Domain Name System) und private IP-Routen für den globalen vollqualifizierten Domänennamen (FQDN), der für anfängliche Feedermittlung benötigt wird. Diese Verbindung wird zu einer einzigen, gemeinsam genutzten Route für alle Clients.
Feeddownload: Der Client lädt alle Verbindungsdetails für einen bestimmten Benutzer für die Arbeitsbereiche herunter, die seine Anwendungsgruppen hosten. Sie erstellen einen privaten Endpunkt für die Feedunterressource für jeden Arbeitsbereich, den Sie mit Private Link verwenden möchten.
Verbindungen mit Hostpools: Jede Verbindung mit einem Hostpool hat zwei Seiten: Clients und Sitzungshosts. Sie müssen einen privaten Endpunkt für die Verbindungsunterressource für jeden Hostpool erstellen, den Sie mit Private Link verwenden möchten.
Die folgende Abbildung zeigt in einer Übersicht, wie Private Link einen lokalen Client sicher mit dem Azure Virtual Desktop-Dienst verbindet. Ausführlichere Informationen zu Clientverbindungen finden Sie unter Clientverbindungssequenz.
Unterstützte Szenarios
Wenn Sie Private Link mit Azure Virtual Desktop hinzufügen, stehen Ihnen die folgenden unterstützten Szenarien zur Verfügung, um eine Verbindung mit Azure Virtual Desktop herzustellen. Es hängt von Ihren Anforderungen ab, welches Szenario Sie auswählen. Sie können diese privaten Endpunkte entweder über Ihre Netzwerktopologie hinweg freigeben oder Ihre virtuellen Netzwerke isolieren, sodass jedes über einen eigenen privaten Endpunkt für den Hostpool oder Arbeitsbereich verfügt.
Für alle Teile der Verbindung werden private Routen verwendet (anfängliche Feedermittlung, Feeddownload und Remotesitzungsverbindungen für Clients und Sitzungshosts). Sie benötigen die folgenden privaten Endpunkte:
Zweck Ressourcentyp Zielunterressource Anzahl von Endpunkten Verbindungen mit Hostpools Microsoft.DesktopVirtualization/hostpools connection Einen pro Hostpool Feeddownload Microsoft.DesktopVirtualization/workspaces feed Einen pro Arbeitsbereich Anfängliche Feedermittlung Microsoft.DesktopVirtualization/workspaces Global Nur einer für alle Azure Virtual Desktop-Bereitstellungen Feeddownload- und Remotesitzungsverbindungen für Clients und Sitzungshosts verwenden private Routen, aber für die anfängliche Feedermittlung werden öffentliche Routen verwendet. Sie benötigen die folgenden privaten Endpunkte: Der Endpunkt für die anfängliche Feedermittlung ist nicht erforderlich.
Zweck Ressourcentyp Zielunterressource Anzahl von Endpunkten Verbindungen mit Hostpools Microsoft.DesktopVirtualization/hostpools connection Einen pro Hostpool Feeddownload Microsoft.DesktopVirtualization/workspaces feed Einen pro Arbeitsbereich Nur Remotesitzungsverbindungen für Clients und Sitzungshosts verwenden private Routen, aber für die anfängliche Feedermittlung und den Feeddownload werden öffentliche Routen verwendet. Sie benötigen die folgenden privaten Endpunkte. Endpunkte für Arbeitsbereiche sind nicht erforderlich.
Zweck Ressourcentyp Zielunterressource Anzahl von Endpunkten Verbindungen mit Hostpools Microsoft.DesktopVirtualization/hostpools connection Einen pro Hostpool Sowohl Clients als auch Sitzungshost-VMs verwenden öffentliche Routen. Private Link wird in diesem Szenario nicht verwendet.
Wichtig
Wenn Sie einen privaten Endpunkt für die anfängliche Feedermittlung erstellen, steuert der Arbeitsbereich, der für die globale Unterressource verwendet wird, den freigegebenen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN), wodurch die anfängliche Feedermittlung in allen Arbeitsbereichen erleichtert wird. Sie sollten einen separaten Arbeitsbereich erstellen, der nur für diesen Zweck verwendet wird und in dem keine Anwendungsgruppen registriert sind. Das Löschen dieses Arbeitsbereichs führt dazu, dass alle Feedermittlungsprozesse nicht mehr funktionieren.
Sie können den Zugriff auf den Arbeitsbereich, der für die anfängliche Feed-Ermittlung (globale Unterressource) verwendet wird, nicht steuern. Wenn Sie diesen Arbeitsbereich so konfigurieren, dass nur der private Zugriff zulässig ist, wird die Einstellung ignoriert. Auf diesen Arbeitsbereich kann immer über öffentliche Routen zugegriffen werden.
IP-Adresszuteilungen können sich ändern, wenn die Nachfrage nach IP-Adressen steigt. Bei Kapazitätserhöhungen werden zusätzliche Adressen für private Endpunkte benötigt. Es ist wichtig, dass Sie die Möglichkeit der Ausschöpfung des IP-Adressraums berücksichtigen und ausreichend Platz für Wachstum gewährleisten. Weitere Informationen zum Ermitteln der geeigneten Netzwerkkonfiguration für private Endpunkte in einer Hub- oder einer Spoke-Topologie finden Sie in der Entscheidungsstruktur für die Private Link-Bereitstellung.
Konfigurationsergebnisse
Sie konfigurieren Einstellungen für die relevanten Azure Virtual Desktop-Arbeitsbereiche und Hostpools, um den öffentlichen oder privaten Zugriff festzulegen. Für Verbindungen mit einem Arbeitsbereich, mit Ausnahme des Arbeitsbereichs, der für die anfängliche Feed-Ermittlung (globale Unterressource) verwendet wird, wird in der folgenden Tabelle das Ergebnis jedes Szenarios erläutert:
Konfiguration | Ergebnis |
---|---|
Öffentlicher Zugriff über alle Netzwerke aktiviert | Arbeitsbereichsfeedanforderungen sind von öffentlichen Routen zulässig. Arbeitsbereichsfeedanforderungen sind zulässig von privaten Routen aus. |
Öffentlicher Zugriff deaktiviert von allen Netzwerken | Arbeitsbereichsfeedanforderungen werden verweigert von öffentlichen Routen. Arbeitsbereichsfeedanforderungen sind zulässig von privaten Routen aus. |
Beim Reverse Connect-Transportgibt es zwei Netzwerkverbindungen für Verbindungen mit Hostpools: den Client mit dem Gateway und den Sitzungshost zum Gateway. Zusätzlich zum Aktivieren oder Deaktivieren des öffentlichen Zugriffs für beide Verbindungen können Sie auch den öffentlichen Zugriff für Clients aktivieren, die mit dem Gateway verbunden sind, und nur privaten Zugriff für Sitzungshosts zulassen, die eine Verbindung mit dem Gateway herstellen. In der folgenden Tabelle wird das Ergebnis der einzelnen Szenarien erläutert:
Konfiguration | Ergebnis |
---|---|
Öffentlicher Zugriff über alle Netzwerke aktiviert | Remotesitzungen sind zulässig, wenn der Client- oder Sitzungshost eine öffentliche Route verwendet. Remotesitzungen sind zulässig, wenn der Client- oder Sitzungshost eine private Route verwendet. |
Öffentlicher Zugriff deaktiviert von allen Netzwerken | Remotesitzungen werden verweigert, wenn der Client- oder Sitzungshost eine öffentliche Route verwendet. Remotesitzungen sind zulässig, wenn sowohl der Client als auch der Sitzungshost eine private Route verwenden. |
Öffentlicher Zugriff für Clientnetzwerke aktiviert, für Sitzungshostnetzwerke jedoch deaktiviert | Remotesitzungen werden verweigert, wenn der Sitzungshost eine öffentliche Route verwendet, unabhängig von der vom Client verwendeten Route. Remotesitzungen sind zulässig, solange der Sitzungshost eine private Route verwendet, unabhängig von der vom Client verwendeten Route. |
Clientverbindungssequenz
Wenn ein Benutzer eine Verbindung mit Azure Virtual Desktop über private Verknüpfung herstellt und Azure Virtual Desktop so konfiguriert ist, dass nur Clientverbindungen von privaten Routen zugelassen werden, lautet die Verbindungssequenz wie folgt:
Bei einem unterstützten Client abonniert ein Benutzer einen Arbeitsbereich. Das Gerät des Benutzers fragt DNS für die Adresse
rdweb.wvd.microsoft.com
(oder die entsprechende Adresse für andere Azure-Umgebungen) ab.Ihre private DNS-Zone für privatelink-global.wvd.microsoft.com gibt die private IP-Adresse für die anfängliche Feed-Ermittlung (globale Unterressource) zurück. Wenn Sie keinen privaten Endpunkt für die anfängliche Feedermittlung verwenden, wird eine öffentliche IP-Adresse zurückgegeben.
Für jeden Arbeitsbereich im Feed wird eine DNS-Abfrage für die Adresse
<workspaceId>.privatelink.wvd.microsoft.com
erstellt.Ihre private DNS-Zone für privatelink.wvd.microsoft.com gibt die private IP-Adresse für den Download des Arbeitsbereichsfeeds zurück und lädt den Feed mit TCP-Port 443 herunter.
Beim Herstellen einer Verbindung mit einer Remotesitzung enthält die
.rdp
-Datei aus dem Download des Arbeitsbereichsfeeds die Adresse für den Azure Virtual Desktop-Gatewaydienst mit der geringsten Wartezeit für das Gerät des Benutzers. Es wird eine DNS-Abfrage an eine Adresse im Format<hostpooId>.afdfp-rdgateway.wvd.microsoft.com
durchgeführt.Ihre private DNS-Zone für privatelink.wvd.microsoft.com gibt die private IP-Adresse für den Azure Virtual Desktop-Gatewaydienst zurück, die für den Hostpool verwendet werden soll, der die Remotesitzung bereitstellt. Für die Orchestrierung über das virtuelle Netzwerk und den privaten Endpunkt wird TCP-Port 443 verwendet.
Nach der Orchestrierung wird der Netzwerkdatenverkehr zwischen dem Client, dem Azure Virtual Desktop-Gatewaydienst und dem Sitzungshost an einen Port im dynamischen TCP-Portbereich von 1 bis 65535 übertragen.
Wichtig
Wenn Sie Netzwerkports von den Benutzerclientgeräten oder Ihren Sitzungshost-VMs auf die privaten Endpunkte beschränken möchten, müssen Sie Datenverkehr über den gesamten dynamischen TCP-Portbereich von 1 bis 65535 bis zum privaten Endpunkt für die Hostpoolressource mithilfe der Verbindungsunterressource zulassen. Der gesamte dynamische TCP-Portbereich ist erforderlich, da private Azure-Netzwerke diese Ports intern dem entsprechenden Gateway zuordnen, das während der Clientorchestrierung ausgewählt wurde. Wenn Sie Ports auf den privaten Endpunkt beschränken, können Ihre Benutzer möglicherweise keine Verbindung mit Azure Virtual Desktop herstellen.
Bekannte Probleme und Einschränkungen
Private Link mit Azure Virtual Desktop weist die folgenden Einschränkungen auf:
Bevor Sie Private Link für Azure Virtual Desktop verwenden, müssen Sie für jedes Azure-Abonnement, für das Sie Private Link mit Azure Virtual Desktop verwenden möchten, Private Link mit Azure Virtual Desktop aktivieren.
Alle Remotedesktopclients, die eine Verbindung mit Azure Virtual Desktop herstellen sollen, können mit Private Link verwendet werden. Wenn Sie den Remotedesktopclient für Windows in einem privaten Netzwerk ohne Internetzugang verwenden und öffentliche sowie private Feeds abonniert haben, können Sie nicht auf Ihren Feed zugreifen.
Nachdem Sie einen privaten Endpunkt in einen Hostpool geändert haben, müssen Sie den Dienst Remote Desktop Agent Loader (RDAgentBootLoader) auf jedem Sitzungshost im Hostpool neu starten. Außerdem müssen Sie diesen Dienst jedes Mal neu starten, wenn Sie die Netzwerkkonfiguration eines Hostpools ändern. Anstatt den Dienst neu zu starten, können Sie jeden einzelnen Sitzungshost neu starten.
Die Verwendung von Private Link und RDP Shortpath für verwaltete Netzwerke wird nicht unterstützt, sie können jedoch zusammen funktionieren. Sie können Private Link und RDP Shortpath für verwaltete Netzwerke auf eigene Gefahr verwenden. Alle anderen RDP Shortpath-Optionen mit STUN oder TURN werden mit Private Link nicht unterstützt.
Zu Beginn der Vorschauversion von Private Link mit Azure Virtual Desktop verwendete der private Endpunkt für die anfängliche Feedermittlung (für die globale Unterressource) denselben Namen für die private DNS-Zone wie andere private Endpunkte für Arbeitsbereiche und Hostpools:
privatelink.wvd.microsoft.com
. In dieser Konfiguration können Benutzer*innen keine privaten Endpunkte ausschließlich für Hostpools und Arbeitsbereiche einrichten. Ab 1. September 2023 wird die gemeinsame Nutzung der privaten DNS-Zone in dieser Konfiguration nicht mehr unterstützt. Sie müssen einen neuen privaten Endpunkt für die globale Unterressource erstellen, um den Namenprivatelink-global.wvd.microsoft.com
für die private DNS-Zone verwenden zu können. Die entsprechenden Schritte finden Sie unter Anfängliche Feedermittlung.
Nächste Schritte
- Erfahren Sie, wie Sie Private Link mit Azure Virtual Desktop einrichten.
- Erfahren Sie, wie Sie DNS für den privaten Azure-Endpunkt unter Private Link DNS-Integration konfigurieren.
- Allgemeine Anleitungen zur Problembehandlung für Private Link finden Sie unter Behandeln von Konnektivitätsproblemen mit privaten Azure-Endpunkten.
- Grundlegendes zur Netzwerkkonnektivität von Azure Virtual Desktop.
- In der Liste der erforderlichen URLs finden Sie die Liste der URLs, die Sie freigeben müssen, um Netzwerkzugriff auf den Azure Virtual Desktop-Dienst sicherzustellen.