Netwerktopologie en connectiviteit voor Azure Virtual Desktop

Het ontwerp en de implementatie van Azure-netwerkmogelijkheden in Azure Virtual Desktop is essentieel voor uw Azure Virtual Desktop-landingszone. Dit artikel is gebaseerd op verschillende Cloud Adoption Framework voor architectuurprincipes en aanbevelingen voor landingszones op ondernemingsniveau van Azure voor het beheren van netwerktopologie en connectiviteit op schaal.

De ontwerpfundamenten zijn:

• Hybride integratie voor connectiviteit tussen on-premises, multicloud- en edge-omgevingen en globale gebruikers. Zie Ondersteuning op ondernemingsniveau voor hybride en multicloud voor meer informatie.
• Prestaties en betrouwbaarheid op schaal voor een consistente ervaring met lage latentie en schaalbaarheid voor workloads.
• Netwerkbeveiliging op basis van nulvertrouwen om netwerkperimeters en verkeersstromen te beveiligen. Zie Netwerkbeveiligingsstrategieën in Azure voor meer informatie.
• Uitbreidbaarheid voor het eenvoudig uitbreiden van een netwerkvoetafdruk zonder ontwerpherwerk.

Netwerkonderdelen en -concepten

• Azure Virtual Network is de fundamentele bouwsteen voor privénetwerken in Azure. Met Virtual Network kunnen veel soorten Azure-resources, zoals Azure Virtual Machines, met elkaar communiceren, internet en on-premises datacenters. Een virtueel netwerk is vergelijkbaar met een traditioneel netwerk dat u in uw eigen datacenter uitvoert. Maar een virtueel netwerk biedt de voordelen van de Azure-infrastructuur van schaal, beschikbaarheid en isolatie.
• Een hub-spoke-netwerktopologie is een type netwerkarchitectuur waarin een virtueel hubnetwerk fungeert als een centraal punt van connectiviteit met verschillende virtuele spoke-netwerken. De hub kan ook het connectiviteitspunt zijn naar on-premises datacenters. De spoke virtuele netwerken peeren met de hub en helpen om workloads te isoleren.
• Azure Virtual WAN is een netwerkservice die netwerk-, beveiligings- en routeringsfuncties samenbrengt in één operationele interface.
• Een virtueel netwerkapparaat (NVA) is een netwerkapparaat dat ondersteuning biedt voor functies zoals connectiviteit, toepassingslevering, WAN-optimalisatie (Wide Area Network) en beveiliging. NVA's omvatten Azure Firewall en Azure Load Balancer.
• In een scenario met geforceerde tunneling wordt al het internetverkeer dat afkomstig is van virtuele Azure-machines (VM's) gerouteerd of geforceerd, om een inspectie- en controleapparaat te doorlopen. Onbevoegde internettoegang kan mogelijk leiden tot openbaarmaking van informatie of andere soorten beveiligingsschendingen zonder de verkeersinspectie of controle.
• Netwerkbeveiligingsgroepen worden gebruikt om netwerkverkeer naar en van Azure-resources in een virtueel Azure-netwerk te filteren. Een netwerkbeveiligingsgroep bevat beveiligingsregels waarmee binnenkomend netwerkverkeer naar, of uitgaand netwerkverkeer van, diverse typen Azure-resources kan worden toegestaan of geweigerd.
• Toepassingsbeveiligingsgroepen bieden een manier om netwerkbeveiliging te configureren als een natuurlijke uitbreiding van de structuur van een toepassing. U kunt toepassingsbeveiligingsgroepen gebruiken om VM's te groeperen en netwerkbeveiligingsbeleid te definiëren dat op deze groepen is gebaseerd. U kunt uw beveiligingsbeleid op schaal opnieuw gebruiken zonder expliciete IP-adressen handmatig te hoeven onderhouden.
• Door de gebruiker gedefinieerde routes (UDR's) kunnen worden gebruikt om standaardsysteemroutes van Azure te overschrijven. U kunt ook UDR's gebruiken om extra routes toe te voegen aan een subnetroutetabel.
• Remote Desktop Protocol Shortpath (RDP Shortpath) is een functie van Azure Virtual Desktop die is gebaseerd op URCP (Universal Rate Control Protocol). RDP Shortpath brengt een direct transport tot stand dat is gebaseerd op User Datagram Protocol (UDP) tussen een ondersteunde Windows Remote Desktop-client en Azure Virtual Desktop-sessiehosts. URCP verbetert UDP-verbindingen door actieve bewaking van netwerkomstandigheden en QoS-mogelijkheden (Quality of Service) te bieden.
• Azure Private Link met Azure Virtual Desktop (preview) biedt een manier om een privé-eindpunt in Azure te gebruiken om sessiehosts te verbinden met de Azure Virtual Desktop-service. Met Private Link gaat verkeer tussen uw virtuele netwerk en de Azure Virtual Desktop-service naar het Microsoft backbone-netwerk . Als gevolg hiervan hoeft u geen verbinding te maken met het openbare internet om toegang te krijgen tot Azure Virtual Desktop-services.

Netwerkscenario's

Om de landingszone van Azure Virtual Desktop tot stand te brengen, is het ontwerpen en implementeren van netwerkmogelijkheden essentieel. Azure-netwerkproducten en -services ondersteunen een groot aantal mogelijkheden. De architectuur die u kiest en de manier waarop u services structureert, is afhankelijk van de workloads, governance en vereisten van uw organisatie.

De volgende belangrijke vereisten en overwegingen zijn van invloed op uw azure Virtual Desktop-implementatiebeslissingen:

• Vereisten voor inkomend en uitgaand internet.
• NVA-gebruik in de huidige architectuur.
• Azure Virtual Desktop-connectiviteit met een standaardhub virtueel netwerk of Virtual WAN-hub.
• Het sessiehostverbindingsmodel. U kunt een systeemeigen model of RDP Shortpath gebruiken.
• Vereisten voor verkeersinspectie voor:
  • Uitgaand internetverkeer van Azure Virtual Desktop.
  • Inkomend internet naar Azure Virtual Desktop.
  • Azure Virtual Desktop-verkeer naar on-premises datacenters.
  • Verkeer van Azure Virtual Desktop naar andere exemplaren van een virtueel netwerk.
  • Verkeer binnen het virtuele Azure Virtual Desktop-netwerk.

Het meest voorkomende netwerkscenario voor Azure Virtual Desktop is een hub-and-spoke-topologie met hybride connectiviteit.

Scenario 1: Hub en spoke met hybride connectiviteit

In dit scenario wordt gebruikgemaakt van het standaardverbindingsmodel voor sessiehosts.

Klantprofiel

Dit scenario is ideaal als:

• U hebt geen verkeersinspectie nodig tussen Azure Virtual Desktop-netwerken en andere virtuele Azure-netwerken.
• U hebt geen verkeersinspectie nodig tussen Azure Virtual Desktop-netwerken en on-premises datacenters.
• U hebt geen verkeersinspectie van uitgaand internetverkeer van Azure Virtual Desktop-netwerken nodig.
• U hoeft niet de openbare IP-adressen te beheren die worden gebruikt tijdens de vertaling van bronnetwerkadressen (SNAT) voor uitgaande internetverbindingen van Azure Virtual Desktop.
• U dwingt geen intern netwerkverkeer van Azure Virtual Desktop af.
• U hebt al bestaande hybride connectiviteit met on-premises omgevingen, hetzij via Azure ExpressRoute of een site-naar-site (S2S) virtueel particulier netwerk (VPN).
• U hebt al bestaande aangepaste Active Directory-domein Services (AD DS) en DNS-servers (Domain Name System).
• U gebruikt Azure Virtual Desktop met behulp van een standaardverbindingsmodel, niet RDP Shortpath.

Architectuuronderdelen

U kunt dit scenario implementeren met:

• AD DS-servers en aangepaste DNS-servers.
• Netwerkbeveiligingsgroepen.
• Azure Network Watcher.
• Uitgaand internet via een standaardpad naar een virtueel Azure-netwerk.
• ExpressRoute of een virtuele VPN-netwerkgateway voor hybride connectiviteit met on-premises systemen.
• Een privé-DNS-zone van Azure.
• Privé-eindpunten van Azure.
• Azure Files-opslagaccounts.
• Azure Key Vault.

Overwegingen

• In dit scenario is geen directe netwerkverbinding mogelijk tussen een client en een openbare of privésessiehost. In dit scenario kunt u RDP Shortpath niet gebruiken.
• De azure Virtual Desktop-besturingsvlakgateway, die gebruikmaakt van een openbaar eindpunt, beheert clientverbindingen. Hierdoor kunnen Azure Virtual Desktop-clients uitgaande verbindingen maken met de vereiste Url's van Azure Virtual Desktop. Zie de sectie Internet van dit artikel en Vereiste URL's voor Azure Virtual Desktop voor meer informatie over vereiste URL's.
• Er zijn geen openbare IP-adressen of andere openbare binnenkomende paden naar sessiehosts nodig. Verkeer van clients naar sessiehosts stroomt via de Gateway van het besturingsvlak van Azure Virtual Desktop.
• Er is geen peering van virtuele netwerken tussen Azure Virtual Desktop-spokes. Al het verkeer gaat via de connectiviteitshub.
• De uitgaande internetverbinding van Azure Virtual Desktop-sessiehosts doorlopen het standaardproces voor het omzetten van uitgaande netwerkadressen (NAT). Dynamische openbare IP-adressen van Azure worden gebruikt. Klanten hebben geen controle over de uitgaande openbare IP-adressen die worden gebruikt.
• Verbinding maken van sessiehosts naar Azure Files-opslagaccounts worden gemaakt met behulp van privé-eindpunten.
• Privé-DNS-zones van Azure worden gebruikt voor het omzetten van privé-eindpuntnaamruimten voor de volgende services:
  • Azure Files-opslagaccounts, die de naam gebruiken privatelink.file.core.windows.net
  • Sleutelkluizen, die de naam gebruiken privatelink.vaultcore.azure.net
• Netwerkfiltering wordt niet afgedwongen voor dit scenario. Netwerkbeveiligingsgroepen worden echter op alle subnetten geplaatst, zodat u verkeer kunt bewaken en inzichten kunt afleiden. In Network Watcher worden verkeersanalyses en de functie voor logboekregistratie van netwerkbeveiligingsgroepen gebruikt voor deze doeleinden.

Scenario 2: Hub en spoke met hybride connectiviteit via beheerde netwerken met behulp van RDP Shortpath

Zie RDP Shortpath-connectiviteit voor beheerde netwerken voor gedetailleerde implementatierichtlijnen.

Klantprofiel

Dit scenario is ideaal als:

• U wilt het aantal over-internetverbindingen beperken tot Azure Virtual Desktop-sessiehosts.
• U hebt al bestaande hybride connectiviteit van een on-premises omgeving naar Azure, hetzij via ExpressRoute of een S2S- of punt-naar-site-VPN (P2S).
• U hebt directe line-of-sight-netwerkconnectiviteit tussen RDP-clients en Azure Virtual Desktop-hosts. Normaal gesproken wordt in dit scenario een van de volgende instellingen gebruikt:
  • On-premises netwerken die worden gerouteerd naar Azure Virtual Desktop Azure-netwerken
  • Vpn-verbindingen van clients die worden gerouteerd naar virtuele Azure-netwerken van Azure Virtual Desktop
• U moet het bandbreedtegebruik van VM-hosts via privénetwerken beperken, zoals een VPN of ExpressRoute.
• U wilt prioriteit geven aan Azure Virtual Desktop-verkeer in uw netwerk.
• U hebt geen verkeersinspectie nodig tussen Azure Virtual Desktop-netwerken en andere virtuele Azure-netwerken.
• U hebt geen verkeersinspectie nodig tussen Azure Virtual Desktop-netwerken en on-premises datacenters.
• U hebt al bestaande aangepaste AD DS- of DNS-servers.

Architectuuronderdelen

U kunt dit scenario implementeren met:

• ExpressRoute of een virtuele VPN-netwerkgateway voor hybride connectiviteit met on-premises omgevingen met voldoende bandbreedte.
• AD DS-servers en aangepaste DNS-servers.
• Netwerkbeveiligingsgroepen.
• Uitgaand internet via een standaardpad naar een virtueel Azure-netwerk.
• Groepsbeleidsobjecten (GPO's) of lokale GPO's voor domeinen.
• Azure Files-opslagaccounts.
• Privé-eindpunten van Azure.
• Een privé-DNS-zone van Azure.

Overwegingen

• Hybride connectiviteit moet beschikbaar zijn via een VPN of ExpressRoute, waarbij de RDP-client een directe netwerkverbinding heeft met privé-VM-hosts op poort 3390.

Notitie

Voor beheerde netwerken kan de standaard UDP-poort worden gewijzigd.

• Er moet een domein-GPO of lokaal groepsbeleidsobject worden gebruikt om UDP via beheerde netwerken in te schakelen.
• Hybride connectiviteit moet voldoende bandbreedte hebben om UDP-directe verbindingen met VM-hosts mogelijk te maken.
• Hybride connectiviteit moet directe routering hebben om verbindingen met VM-hosts toe te staan.
• De azure Virtual Desktop-besturingsvlakgateway, die gebruikmaakt van een openbaar eindpunt, beheert clientverbindingen. Hierdoor kunnen Azure Virtual Desktop-clients uitgaande verbindingen maken met de vereiste Url's van Azure Virtual Desktop. Zie de sectie Internet van dit artikel en Vereiste URL's voor Azure Virtual Desktop voor meer informatie over vereiste URL's.
• Er zijn geen openbare IP-adressen of andere openbare binnenkomende paden naar sessiehosts nodig. Verkeer van clients naar sessiehosts stroomt via de Gateway van het besturingsvlak van Azure Virtual Desktop.
• De uitgaande internetverbinding van Azure Virtual Desktop-sessiehosts doorloopt het standaard uitgaande NAT-proces van Azure. Dynamische openbare IP-adressen van Azure worden gebruikt. Klanten hebben geen controle over de uitgaande openbare IP-adressen die worden gebruikt.
• Verbinding maken van sessiehosts naar Azure Files-opslagaccounts worden gemaakt met behulp van privé-eindpunten.
• Privé-DNS-zones van Azure worden gebruikt voor het omzetten van privé-eindpuntnaamruimten.
• Netwerkfiltering wordt niet afgedwongen voor dit scenario. Netwerkbeveiligingsgroepen worden echter op alle subnetten geplaatst, zodat u verkeer kunt bewaken en inzichten kunt afleiden. In Network Watcher worden verkeersanalyses en de functie voor logboekregistratie van netwerkbeveiligingsgroepen gebruikt voor deze doeleinden.

Notitie

Momenteel biedt Azure Virtual Desktop geen ondersteuning voor het gebruik van Private Link en RDP Shortpath tegelijk.

Scenario 3: Hub en spoke met openbare netwerken met behulp van RDP Shortpath

Zie RDP Shortpath-connectiviteit voor openbare netwerken voor gedetailleerde implementatierichtlijnen.

Klantprofiel

Dit scenario is ideaal als:

• Uw Azure Virtual Desktop-clientverbindingen gaan via het openbare internet. Typische scenario's zijn werk-van-thuisgebruikers, externe filiaalgebruikers die niet zijn verbonden met bedrijfsnetwerken en externe contractanten.
• U hebt verbindingen met hoge latentie of lage bandbreedte met Azure Virtual Desktops-sessiehosts.
• U moet het bandbreedtegebruik van Azure Virtual Desktop-sessiehosts beperken via QoS-netwerkbeleid.
• U wilt prioriteit geven aan Azure Virtual Desktop-verkeer in uw netwerk via QoS-beleid.
• RdP-verbindingen van clients beginnen met netwerken met inconsistente bandbreedte en snelheid.
• U hebt directe uitgaande connectiviteit van Azure Virtual Desktop-sessiehosts. U gebruikt geen geforceerde tunnelroutering via on-premises netwerken.
• U hebt geen verkeersinspectie nodig tussen Azure Virtual Desktop-netwerken en andere virtuele Azure-netwerken.
• U hebt geen verkeersinspectie nodig tussen Azure Virtual Desktop-netwerken en on-premises datacenters.
• U hebt al bestaande aangepaste AD DS- of DNS-servers.

Architectuuronderdelen

U kunt dit scenario implementeren met:

• ExpressRoute of een virtuele VPN-netwerkgateway voor hybride connectiviteit met on-premises omgevingen. Deze installatie is geschikt wanneer er voldoende bandbreedte is om verbindingen met on-premises toepassingen, gegevens of AD DS-verbindingen te ondersteunen. Het wordt afgeraden geforceerde tunneling te gebruiken om Verkeer van Azure Virtual Desktop via on-premises routers te verzenden.
• AD DS-servers en aangepaste DNS-servers.
• Netwerkbeveiligingsgroepen.
• Network Watcher.
• Uitgaand internet via een standaardpad naar een virtueel Azure-netwerk.
• Domein-GPO's of lokale GPO's.
• Azure Files-opslagaccounts.
• Privé-eindpunten van Azure.
• Een privé-DNS-zone van Azure.

Overwegingen

• Sta de volgende typen verbindingen toe:

  • Uitgaande UDP-verbindingen van Azure Virtual Desktop-sessiehosts naar de Azure Virtual Desktop Session Traversal Utilities for NAT (STUN) en Traversal Using Relay NAT (TURN) services op poort 3478
  • UDP-verbindingen van RDP-clients in poortbereik 49152-65535

  De instelling die deze verbindingen configureert, is standaard ingeschakeld en onderhoudt hetzelfde versleutelingsniveau als TCP (Transmission Control Protocol) reverse connect. Zie Het poortbereik beperken bij het gebruik van RDP Shortpath voor openbare netwerken voor meer informatie over het beperken van RDP-clientpoortbereiken.

• De azure Virtual Desktop-besturingsvlakgateway, die gebruikmaakt van een openbaar eindpunt, beheert clientverbindingen. Hierdoor kunnen Azure Virtual Desktop-clients uitgaande verbindingen maken met de vereiste Url's van Azure Virtual Desktop. Zie de sectie Internet van dit artikel en Vereiste URL's voor Azure Virtual Desktop voor meer informatie over vereiste URL's.

• Consumentenrouters die zich doorgaans in thuisgebruikersnetwerken bevinden, moeten Universal Plug en Play (UPnP) hebben ingeschakeld.

• Er zijn geen openbare IP-adressen of andere openbare binnenkomende paden naar sessiehosts nodig. Verkeer van clients naar sessiehosts stroomt via de Gateway van het besturingsvlak van Azure Virtual Desktop.

• De uitgaande internetverbinding van Azure Virtual Desktop-sessiehosts doorloopt het standaard uitgaande NAT-proces van Azure. Dynamische openbare IP-adressen van Azure worden gebruikt. Klanten hebben geen controle over de uitgaande openbare IP-adressen die worden gebruikt.

• U moet dscP-markering (Differentd Services Code Point) configureren op de sessiehosts. Gebruik lokale GPO's of domein-GPO's voor deze configuratie. Wanneer u DSCP-markeringen gebruikt, kunnen netwerkapparaten QoS-beleid toepassen voor Verkeer van Azure Virtual Desktop. Zie Quality of Service (QoS) implementeren voor Azure Virtual Desktop voor meer informatie.

• Verbinding maken van sessiehosts naar Azure Files-opslagaccounts worden ingesteld met behulp van privé-eindpunten.

• Privé-DNS-zones van Azure worden gebruikt voor het omzetten van privé-eindpuntnaamruimten.

• Netwerkfiltering wordt niet afgedwongen voor dit scenario. Netwerkbeveiligingsgroepen worden echter op alle subnetten geplaatst, zodat u verkeer kunt bewaken en inzichten kunt afleiden. In Network Watcher worden verkeersanalyses en de functie voor logboekregistratie van netwerkbeveiligingsgroepen gebruikt voor deze doeleinden.

Algemene ontwerpoverwegingen en aanbevelingen

De volgende secties bevatten algemene ontwerpoverwegingen en aanbevelingen voor de topologie en connectiviteit van azure Virtual Desktop-netwerken.

Hub en spoke versus Virtual WAN-netwerktopologie

Virtual WAN biedt ondersteuning voor transitconnectiviteit tussen VPN en ExpressRoute , maar biedt geen ondersteuning voor hub-and-spoke-topologieën.

Identiteitsservices

De connectiviteitsvereisten van identiteitsservices in Azure Virtual Desktop-sessiehosts zijn afhankelijk van het identiteitsmodel.

• Voor aan Microsoft Entra Domain Services gekoppelde VM's: Azure Virtual Desktop-netwerken moeten verbinding hebben met het netwerk waarop de identiteitsservice wordt gehost.
• Voor aan Microsoft Entra ID gekoppelde VM's: Azure Virtual Desktop-sessiehosts maken uitgaande verbindingen met openbare Microsoft Entra ID-eindpunten. Als gevolg hiervan zijn er geen configuraties voor privéconnectiviteit vereist.

DNS

Azure Virtual Desktop-sessiehosts hebben dezelfde vereisten voor naamomzetting als elke andere IaaS-workload (Infrastructure as a Service). Als gevolg hiervan is connectiviteit met aangepaste DNS-servers of toegang via een virtuele netwerkkoppeling naar privé-DNS-zones van Azure vereist. Extra privé-DNS-zones van Azure zijn vereist voor het hosten van de privé-eindpuntnaamruimten van bepaalde PaaS-services (Platform as a Service), zoals opslagaccounts en sleutelbeheerservices.

Zie DNS-configuratie voor privé-eindpunten in Azure voor meer informatie.

Om de configuratie van de Azure Virtual Desktop-client voor eindgebruikers te vergemakkelijken, inclusief het abonnement op de RDS-feed (Remote Desktop Services), kunt u het beste e-maildetectie instellen. U moet e-maildetectie instellen in het openbare DNS-domein en u vervolgens abonneren op uw RDS-feed. Zie E-maildetectie instellen om u te abonneren op uw RDS-feed voor meer informatie.

Bandbreedte en latentie

Azure Virtual Desktop maakt gebruik van RDP. Zie de bandbreedtevereisten van Remote Desktop Protocol (RDP) voor meer informatie over RDP.

De verbindingslatentie varieert, afhankelijk van de locatie van de gebruikers en de VM's. Azure Virtual Desktop-services worden continu geïmplementeerd in nieuwe geografische gebieden om de latentie te verbeteren. Gebruik de Azure Virtual Desktop Experience Estimator om de latentie te minimaliseren die azure Virtual Desktop-clients ervaren. Dit hulpprogramma biedt rtt-voorbeelden (round-trip time) van clients. U kunt deze informatie gebruiken om sessiehosts te plaatsen in de regio die zich het dichtst bij eindgebruikers bevindt en de laagste RTT heeft. Zie Verbindingskwaliteit analyseren in Azure Virtual Desktop voor informatie over het interpreteren van resultaten van het hulpprogramma estimator.

QoS met RDP Shortpath

RDP Shortpath voor beheerde netwerken biedt een direct UDP-transport tussen een Extern bureaublad-client en een sessiehost. RDP Shortpath voor beheerde netwerken biedt een manier om QoS-beleid voor de RDP-gegevens te configureren. QoS in Azure Virtual Desktop maakt realtime RDP-verkeer mogelijk dat gevoelig is voor netwerkvertragingen om 'in lijn' te snijden voor minder gevoelig verkeer.

U kunt RDP Shortpath op twee manieren gebruiken:

• In beheerde netwerken, waarbij directe connectiviteit tot stand wordt gebracht tussen de client en de sessiehost wanneer u een privéverbinding gebruikt, zoals een ExpressRoute-verbinding of een VPN.
• In openbare netwerken, waarbij directe connectiviteit tot stand wordt gebracht tussen de client en de sessiehost wanneer u een openbare verbinding gebruikt. Voorbeelden van openbare verbindingen zijn thuisnetwerken, koffiezetapparaatnetwerken en hotelnetwerken. Er zijn twee mogelijke verbindingstypen wanneer u een openbare verbinding gebruikt:

  • Een directe UDP-verbinding tussen een client en een sessiehost die gebruikmaakt van het STUN-protocol.

  • Een indirecte UDP-verbinding die gebruikmaakt van het TURN-protocol met een relay tussen een RDP-client en een sessiehost. Deze optie wordt gebruikt als de gateway of router directe UDP-verbindingen niet toestaat.

    Notitie

    Het gebruik van RDP Shortpath voor openbare netwerken met TURN voor Azure Virtual Desktop is momenteel in preview. Zie RDP Shortpath voor Azure Virtual Desktop voor meer informatie.

Het RDP-pad breidt de MOGELIJKHEDEN voor meerdere transporten van RDP uit. Het vervangt niet het omgekeerde verbindingstransport, maar vormt een aanvulling op het transport.

Initiële sessiebrokering wordt beheerd via de Azure Virtual Desktop-service en het reverse connect-transport, dat op TCP is gebaseerd. Alle verbindingspogingen worden genegeerd, tenzij ze eerst overeenkomen met de sessie voor reverse connect.

RDP Shortpath, op basis van UDP, wordt tot stand gebracht na verificatie. Als RDP Shortpath tot stand is gebracht, wordt het transport voor reverse connect verwijderd. Vervolgens loopt al het verkeer via een van de RDP Shortpath-methoden die eerder in deze sectie worden vermeld.

Zie Quality of Service (QoS) implementeren voor Azure Virtual Desktop voor meer informatie.

Internet

Azure Virtual Desktop-rekenresources en -clients hebben toegang nodig tot specifieke openbare eindpunten, zodat ze internetverbindingen nodig hebben. Netwerkscenario's, zoals geforceerde tunneling om de beveiliging en filtering te verbeteren, worden ondersteund wanneer aan de vereisten van Azure Virtual Desktop wordt voldaan.

Zie Vereiste URL's voor Azure Virtual Desktop voor Azure Virtual Desktop-sessiehosts en clientapparaten voor meer informatie over vereisten.

Poort- en protocolvereisten

De verbindingsmodellen van Azure Virtual Desktop gebruiken de volgende poorten en protocollen:

• Standaardmodel: 443/TCP
• RDP Shortpath-model: 443/TCP en 3390/UDP of 3478/UDP voor het STUN- of TURN-protocol

Bedrijfscontinuïteit en herstel na noodgevallen

Voor bedrijfscontinuïteit en herstel na noodgevallen is een bepaalde netwerkinstallatie vereist. Voor het implementeren en herstellen van resources in een doelomgeving gebruikt u een van de volgende configuraties:

• Een netwerkinstallatie met dezelfde mogelijkheden als die in de bronomgeving
• Een netwerkinstallatie met connectiviteit met identiteit en DNS-services

Volgende stappen

Meer informatie over resourceorganisatie voor een scenario op ondernemingsniveau van Azure Virtual Desktop.

Resourceorganisatie