Delen via

Azure Private Link met Azure Virtual Desktop

  • Artikel

U kunt Azure Private Link gebruiken met Azure Virtual Desktop om privé verbinding te maken met uw externe resources. Door een privé-eindpunt te maken, blijft verkeer tussen uw virtuele netwerk en de service op het Microsoft-netwerk staan, zodat u uw service niet meer beschikbaar hoeft te maken voor het openbare internet. U gebruikt ook een VPN of ExpressRoute voor uw gebruikers met de Extern bureaublad-client om verbinding te maken met het virtuele netwerk. Het verkeer binnen het Microsoft-netwerk verbetert de beveiliging en houdt uw gegevens veilig. In dit artikel wordt beschreven hoe Private Link u kan helpen uw Azure Virtual Desktop-omgeving te beveiligen.

Azure Virtual Desktop heeft drie werkstromen met drie bijbehorende resourcetypen privé-eindpunten:

  1. Initiële feeddetectie: hiermee kan de client alle werkruimten detecteren die aan een gebruiker zijn toegewezen. Als u dit proces wilt inschakelen, moet u één privé-eindpunt maken voor de globale subresource naar elke werkruimte. U kunt echter slechts één privé-eindpunt maken in uw hele Azure Virtual Desktop-implementatie. Met dit eindpunt worden DNS-vermeldingen (Domain Name System) en privé-IP-routes gemaakt voor de algemene FQDN (Fully Qualified Domain Name Name) die nodig zijn voor initiële feeddetectie. Deze verbinding wordt één gedeelde route voor alle clients die moeten worden gebruikt.

  2. Feeddownload: de client downloadt alle verbindingsgegevens voor een specifieke gebruiker voor de werkruimten die hun toepassingsgroepen hosten. U maakt een privé-eindpunt voor de subresource van de feed voor elke werkruimte die u wilt gebruiken met Private Link.

  3. Verbinding maken ionen voor hostgroepen: elke verbinding met een hostgroep heeft twee zijden: clients en sessiehost-VM's (virtuele machines). Als u verbindingen wilt inschakelen, moet u een privé-eindpunt maken voor de subresource van de verbinding voor elke hostgroep die u wilt gebruiken met Private Link.

In het volgende diagram op hoog niveau ziet u hoe Private Link een lokale client veilig verbindt met de Azure Virtual Desktop-service. Zie De clientverbindingsreeks voor meer informatie over clientverbindingen.

Een diagram op hoog niveau waarin Private Link een lokale client verbindt met de Azure Virtual Desktop-service.

Ondersteunde scenario's

Wanneer u Private Link toevoegt met Azure Virtual Desktop, hebt u de volgende ondersteunde scenario's om verbinding te maken met Azure Virtual Desktop. Elk kan worden ingeschakeld of uitgeschakeld, afhankelijk van uw vereisten. U kunt deze privé-eindpunten delen in uw netwerktopologie of u kunt uw virtuele netwerken isoleren, zodat elk een eigen privé-eindpunt heeft voor de hostgroep of werkruimte.

  1. Zowel clients als sessiehost-VM's maken gebruik van privéroutes. U hebt de volgende privé-eindpunten nodig:

    Doel Brontype Stel subresource in Aantal eindpunten
    Verbinding maken ies voor hostgroepen Microsoft.DesktopVirtualization/hostpools verbinding Eén per hostgroep
    Feed downloaden Microsoft.DesktopVirtualization/workspaces feed Eén per werkruimte
    Initiële feeddetectie Microsoft.DesktopVirtualization/workspaces global Slechts één voor al uw Azure Virtual Desktop-implementaties

  2. Clients gebruiken openbare routes terwijl sessiehost-VM's privéroutes gebruiken. U hebt de volgende privé-eindpunten nodig. Eindpunten voor werkruimten zijn niet vereist.

    Doel Brontype Stel subresource in Aantal eindpunten
    Verbinding maken ies voor hostgroepen Microsoft.DesktopVirtualization/hostpools verbinding Eén per hostgroep

  3. Zowel clients als sessiehost-VM's gebruiken openbare routes. Private Link wordt niet gebruikt in dit scenario.

Voor verbindingen met een werkruimte, met uitzondering van de werkruimte die wordt gebruikt voor initiële feeddetectie (globale subresource), wordt in de volgende tabel het resultaat van elk scenario beschreven:

Configuratie Resultaat
Openbare toegang ingeschakeld vanuit alle netwerken Aanvragen voor werkruimtefeeds zijn toegestaan vanuit openbare routes.

Aanvragen voor werkruimtefeeds zijn toegestaan vanuit privéroutes .
Openbare toegang uitgeschakeld vanuit alle netwerken Aanvragen voor werkruimtefeeds worden geweigerd vanuit openbare routes.

Aanvragen voor werkruimtefeeds zijn toegestaan vanuit privéroutes .

Met het reverse connect-transport zijn er twee netwerkverbindingen voor verbindingen met hostgroepen: de client naar de gateway en de sessiehost naar de gateway. Naast het in- of uitschakelen van openbare toegang voor beide verbindingen, kunt u er ook voor kiezen om openbare toegang in te schakelen voor clients die verbinding maken met de gateway en alleen privétoegang toestaan voor sessiehosts die verbinding maken met de gateway. In de volgende tabel wordt het resultaat van elk scenario beschreven:

Configuratie Resultaat
Openbare toegang ingeschakeld vanuit alle netwerken Externe sessies zijn toegestaan wanneer de client of sessiehost een openbare route gebruikt.

Externe sessies zijn toegestaan wanneer de client of sessiehost een privéroute gebruikt.
Openbare toegang uitgeschakeld vanuit alle netwerken Externe sessies worden geweigerd wanneer de client of sessiehost een openbare route gebruikt.

Externe sessies zijn toegestaan wanneer zowel de client als de sessiehost een privéroute gebruiken.
Openbare toegang ingeschakeld voor clientnetwerken, maar uitgeschakeld voor sessiehostnetwerken Externe sessies worden geweigerd als de sessiehost een openbare route gebruikt, ongeacht de route die de client gebruikt.

Externe sessies zijn toegestaan zolang de sessiehost een privéroute gebruikt, ongeacht de route die de client gebruikt.

Belangrijk

  • Een privé-eindpunt voor de globale subresource van elke werkruimte bepaalt de gedeelde FQDN (Fully Qualified Domain Name) voor initiële feeddetectie. Hierdoor kunnen feeddetecties voor alle werkruimten worden ingeschakeld. Omdat de werkruimte die is verbonden met het privé-eindpunt zo belangrijk is, zorgt het verwijderen ervoor dat alle feeddetectieprocessen niet meer werken. U wordt aangeraden een ongebruikte tijdelijke aanduiding voor de globale subresource te maken.

  • U kunt de toegang tot de werkruimte die wordt gebruikt voor de initiële feeddetectie (globale subresource) niet beheren. Als u deze werkruimte zo configureert dat alleen privétoegang is toegestaan, wordt de instelling genegeerd. Deze werkruimte is altijd toegankelijk vanuit openbare routes.

  • Als u netwerkpoorten wilt beperken van de clientapparaten van de gebruiker of van uw sessiehost-VM's naar de privé-eindpunten, moet u verkeer toestaan over het hele dynamische TCP-poortbereik van 1 - 65535 naar het privé-eindpunt voor de hostgroepresource met behulp van de subresource van de verbinding . Het volledige dynamische TCP-poortbereik is nodig omdat poorttoewijzing wordt gebruikt voor alle globale gateways via het IP-adres van één privé-eindpunt dat overeenkomt met de subresource van de verbinding . Als u poorten beperkt tot het privé-eindpunt, kunnen uw gebruikers mogelijk geen verbinding maken met Azure Virtual Desktop.

Clientverbindingsreeks

Wanneer een gebruiker via Private Link verbinding maakt met Azure Virtual Desktop en Azure Virtual Desktop zodanig is geconfigureerd dat alleen clientverbindingen van privéroutes zijn toegestaan, is de verbindingsreeks als volgt:

  1. Met een ondersteunde client abonneert een gebruiker zich op een werkruimte. Het apparaat van de gebruiker vraagt DNS op voor het adres rdweb.wvd.microsoft.com (of het bijbehorende adres voor andere Azure-omgevingen).

  2. Uw privé-DNS-zone voor privatelink-global.wvd.microsoft.com retourneert het privé-IP-adres voor de eerste feeddetectie (globale subresource).

  3. Voor elke werkruimte in de feed wordt een DNS-query gemaakt voor het adres <workspaceId>.privatelink.wvd.microsoft.com.

  4. Uw privé-DNS-zone voor privatelink.wvd.microsoft.com retourneert het privé-IP-adres voor het downloaden van de werkruimtefeed en downloadt de feed via TCP-poort 443.

  5. Wanneer u verbinding maakt met een externe sessie, bevat het .rdp bestand dat afkomstig is van de download van de werkruimtefeed het adres voor de Azure Virtual Desktop-gatewayservice met de laagste latentie voor het apparaat van de gebruiker. Er wordt een DNS-query uitgevoerd op een adres in de indeling <hostpooId>.afdfp-rdgateway.wvd.microsoft.com.

  6. Uw privé-DNS-zone voor privatelink.wvd.microsoft.com retourneert het privé-IP-adres voor de Azure Virtual Desktop-gatewayservice die moet worden gebruikt voor de hostgroep die de externe sessie levert. Indeling via het virtuele netwerk en het privé-eindpunt maakt gebruik van TCP-poort 443.

  7. Na indeling wordt het netwerkverkeer tussen de client, de Azure Virtual Desktop-gatewayservice en de sessiehost overgebracht naar een poort in het dynamische TCP-poortbereik van 1 - 65535. Het hele poortbereik is nodig omdat poorttoewijzing wordt gebruikt voor alle globale gateways via het IP-adres van één privé-eindpunt dat overeenkomt met de subresource van de verbinding . Privénetwerken van Azure worden deze poorten intern toegewezen aan de juiste gateway die is geselecteerd tijdens clientindeling.

Bekende problemen en beperkingen

Private Link met Azure Virtual Desktop heeft de volgende beperkingen:

  • Voordat u Private Link voor Azure Virtual Desktop gebruikt, moet u Private Link met Azure Virtual Desktop inschakelen voor elk Azure-abonnement waarvoor u Private Link wilt gebruiken met Azure Virtual Desktop.

  • Alle Extern bureaublad-clients om verbinding te maken met Azure Virtual Desktop kunnen worden gebruikt met Private Link. Als u de Extern bureaublad-client voor Windows gebruikt in een particulier netwerk zonder internettoegang en u bent geabonneerd op zowel openbare als privéfeeds, hebt u geen toegang tot uw feed.

  • Nadat u een privé-eindpunt hebt gewijzigd in een hostgroep, moet u de EXTERN BUREAUBLAD Agent Loader-service (RDAgentBootLoader) opnieuw starten op elke sessiehost in de hostgroep. U moet deze service ook opnieuw starten wanneer u de netwerkconfiguratie van een hostgroep wijzigt. In plaats van de service opnieuw te starten, kunt u elke sessiehost opnieuw starten.

  • Het gebruik van zowel Private Link als RDP Shortpath heeft de volgende beperkingen:

  • Vroeg in de preview van Private Link met Azure Virtual Desktop heeft het privé-eindpunt voor de eerste feeddetectie (voor de globale subresource) de naam van privatelink.wvd.microsoft.com de privé-DNS-zone gedeeld met andere privé-eindpunten voor werkruimten en hostgroepen. In deze configuratie kunnen gebruikers geen privé-eindpunten maken voor hostgroepen en werkruimten. Vanaf 1 september 2023 wordt het delen van de privé-DNS-zone in deze configuratie niet meer ondersteund. U moet een nieuw privé-eindpunt maken voor de globale subresource om de naam van de privé-DNS-zone van privatelink-global.wvd.microsoft.comte gebruiken. Zie De eerste feeddetectie voor de stappen om dit te doen.

Volgende stappen