Topologie et connectivité réseau pour Azure Virtual Desktop

La conception et l’implémentation des capacités réseau dans Azure Virtual Desktop sont essentielles pour votre zone d’atterrissage Azure Virtual Desktop. Cet article s’appuie sur plusieurs principes architecturaux du Cloud Adoption Framework pour Azure pour les zones d’atterrissage à l’échelle de l’entreprise et sur des recommandations pour la gestion de la topologie réseau et de la connectivité à grande échelle.

Les bases de conception sont les suivantes :

• Intégration hybride pour la connectivité entre les environnements locaux, multiclouds et de périphérie, et les utilisateurs globaux. Pour plus d’informations, consultez Prise en charge à l’échelle de l’entreprise - Hybride et multicloud.
• Performances et fiabilité à grande échelle pour une scalabilité et une expérience cohérente et à faible latence pour les charges de travail.
• Sécurité réseau basée sur la Confiance zéro pour sécuriser le périmètre réseau et les flux de trafic. Pour plus d’informations, consultez Stratégies de sécurité réseau sur Azure.
• Extensibilité pour étendre facilement l’empreinte réseau sans remaniement de la conception.

Composants et concepts réseau

• Le réseau virtuel Azure est le composant fondamental pour vos réseaux privés dans Azure. Avec le service Réseau virtuel, de nombreux types de ressources Azure, telles que les machines virtuelles Azure, peuvent communiquer entre elles, avec Internet et avec des centres de données locaux. Un réseau virtuel est similaire à un réseau traditionnel que vous utilisez dans votre propre centre de données. Toutefois, un réseau virtuel offre les avantages de l’infrastructure Azure tels que la scalabilité, la disponibilité et l’isolation.
• Une topologie réseau hub-and-spoke est un type d’architecture réseau dans lequel un réseau virtuel hub joue le rôle de point central de la connectivité pour de nombreux réseaux virtuels spoke. Le hub peut également être le point de connectivité aux centres de données locaux. Les réseaux virtuels spoke sont appairés avec le hub et permettent d’isoler les charges de travail.
• Azure Virtual WAN est un service réseau qui combine des fonctions de mise en réseau, de sécurité et de routage dans une interface opérationnelle unique.
• Une appliance virtuelle réseau (NVA, Network Virtual Appliance) est un périphérique réseau qui prend en charge des fonctions telles que la connectivité, la distribution d’applications, l’optimisation de réseau étendu (WAN) et la sécurité. Les NVA incluent le Pare-feu Azure et Azure Load Balancer.
• Dans un scénario de tunneling forcé, tout le trafic lié à Internet qui provient de machines virtuelles Azure est routé, ou contraint, de passer par une appliance d’inspection et d’audit. L’accès Internet non autorisé peut entraîner la divulgation d’informations ou tout autre type de faille de sécurité sans inspection ou audit du trafic.
• Les groupes de sécurité réseau sont utilisés pour filtrer le trafic réseau à destination et en provenance de ressources Azure dans un réseau virtuel Azure. Un groupe de sécurité réseau contient des règles de sécurité qui autorisent ou refusent le trafic réseau entrant ou sortant en direction/à partir des différents types de ressources Azure.
• Les groupes de sécurité d’application vous permettent de configurer la sécurité réseau comme le prolongement naturel d’une structure d’application. Vous pouvez utiliser des groupes de sécurité d’application pour regrouper des machines virtuelles et définir des stratégies de sécurité réseau basées sur ces groupes. Vous pouvez réutiliser votre stratégie de sécurité à grande échelle sans maintenance manuelle des adresses IP explicites.
• Les routes définies par l’utilisateur peuvent être utilisées pour remplacer les routes système par défaut Azure. Vous pouvez également utiliser des routes définies par l’utilisateur pour ajouter des routes supplémentaires à une table de routage de sous-réseau.
• Remote Desktop Protocol Shortpath (RDP Shortpath) est une fonctionnalité d’Azure Virtual Desktop basée sur le protocole URCP (Universal Rate Control Protocol). RDP Shortpath établit un transport direct basé sur le protocole UDP (User Datagram Protocol) entre un client Windows Remote Desktop pris en charge et des hôtes de session Azure Virtual Desktop. URCP améliore les connexions UDP en fournissant un monitoring actif des conditions réseau et des capacités de qualité de service (QoS).
• Azure Private Link avec Azure Virtual Desktop (préversion) vous permet d’utiliser un point de terminaison privé dans Azure pour connecter des hôtes de session au service Azure Virtual Desktop. Avec Private Link, le trafic entre votre réseau virtuel et le service Azure Virtual Desktop transite par le réseau principal Microsoft. Ainsi, vous n’avez pas besoin de vous connecter à l’Internet public pour accéder aux services Azure Virtual Desktop.

Scénarios réseau

Pour établir la zone d’atterrissage Azure Virtual Desktop, la conception et l’implémentation des fonctionnalités réseau sont essentielles. Les produits et services réseau Azure prennent en charge un large éventail de fonctionnalités. L’architecture que vous choisissez et la manière dont vous structurez les services dépendent des charges de travail, de la gouvernance et des exigences de votre organisation.

Les exigences et considérations principales suivantes affectent vos choix en matière de déploiement Azure Virtual Desktop :

• Exigences d’entrée et de sortie Internet.
• Utilisation d’une appliance virtuelle réseau dans l’architecture actuelle.
• Connectivité Azure Virtual Desktop à un réseau virtuel hub standard ou à un hub WAN virtuel.
• Le modèle de connexion de l’hôte de session. Vous pouvez utiliser un modèle natif ou RDP Shortpath.
• Exigences en matière d’inspection du trafic pour les éléments suivants :
  • Sortie Internet depuis Azure Virtual Desktop.
  • Entrée Internet vers Azure Virtual Desktop.
  • Le trafic Azure Virtual Desktop vers les centres de données locaux.
  • Le trafic Azure Virtual Desktop vers d’autres instances de réseau virtuel.
  • Trafic au sein du réseau virtuel Azure Virtual Desktop.

Le scénario de réseau le plus courant pour Azure Virtual Desktop est une topologie hub-and-spoke avec connectivité hybride.

Scénario 1 : réseau hub-and-spoke avec connectivité hybride

Ce scénario utilise le modèle de connexion hôte de session standard.

Profil client

Ce scénario est idéal dans les cas suivants :

• Vous n’avez pas besoin d’une inspection de trafic entre les réseaux Azure Virtual Desktop et les autres réseaux virtuels Azure.
• Vous n’avez pas besoin d’une inspection de trafic entre les réseaux Azure Virtual Desktop et les centres de données locaux.
• Vous n’avez pas besoin d’une inspection de trafic pour le trafic Internet sortant provenant de réseaux Azure Virtual Desktop.
• Vous n’avez pas besoin de contrôler les adresses IP publiques utilisées lors de la traduction d’adresses réseau sources (SNAT) pour les connexions Internet sortantes Azure Virtual Desktop.
• Vous n’appliquez pas le trafic interne au réseau Azure Virtual Desktop.
• Vous disposez d’une connectivité hybride préexistante à des environnements locaux, par le biais d’Azure ExpressRoute ou d’un réseau privé virtuel (VPN) site à site (S2S).
• Vous disposez de serveurs personnalisés AD DS (Active Directory Domain Services) et DNS (Domain Name System) préexistants.
• Vous utilisez Azure Virtual Desktop au moyen d’un modèle de connexion standard, et non RDP Shortpath.

Composants architecturaux

Vous pouvez implémenter ce scénario avec :

• Serveurs AD DS et serveurs DNS personnalisés.
• Groupes de sécurité réseau.
• Azure Network Watcher.
• Internet sortant via un chemin réseau virtuel Azure par défaut.
• ExpressRoute ou une passerelle de réseau virtuel VPN pour la connectivité hybride vers les centres de données locaux.
• Une zone DNS privée Azure.
• Points de terminaison privés Azure.
• Des comptes de stockage Azure Files.
• Azure Key Vault.

À propos de l’installation

• Ce scénario ne prend pas en charge la connectivité réseau directe entre un client et un hôte de session public ou privé. Vous ne pouvez pas utiliser RDP Shortpath dans ce scénario.
• La passerelle de plan de contrôle Azure Virtual Desktop, qui utilise un point de terminaison public, gère les connexions clientes. Par conséquent, les clients Azure Virtual Desktop peuvent créer des connexions sortantes vers les URL Azure Virtual Desktop nécessaires. Pour plus d’informations sur les URL requises, consultez la section Internet de cet article et URL requises pour Azure Virtual Desktop.
• Aucune adresse IP publique ou autre chemin entrant public vers les hôtes de session n’est nécessaire. Le trafic entre les clients et les hôtes de session transite par la passerelle du plan de contrôle Azure Virtual Desktop.
• Il n’existe aucun appairage de réseaux virtuels entre les spokes Azure Virtual Desktop. Tout le trafic passe par le hub de connectivité.
• Les connexions Internet sortantes à partir des hôtes de session Azure Virtual Desktop passent par le processus de traduction d’adresses réseau (NAT) sortantes Azure par défaut. Des adresses IP publiques Azure dynamiques sont utilisées. Les clients n’ont aucun contrôle sur les adresses IP publiques sortantes utilisées.
• Les connexions des hôtes de session aux comptes de stockage Azure Files sont établies à l’aide de points de terminaison privés.
• Des zones DNS privées Azure sont utilisées pour résoudre les espaces de noms de points de terminaison privés pour les services suivants :
  • Comptes de stockage Azure Files, qui utilisent le nom privatelink.file.core.windows.net
  • Coffres de clés, qui utilisent le nom privatelink.vaultcore.azure.net
• Le filtrage réseau n’est pas appliqué pour ce scénario. Toutefois, des groupes de sécurité réseau sont placés sur tous les sous-réseaux afin de pouvoir superviser le trafic et dériver des insights. Dans Network Watcher, l’analytique du trafic et la fonctionnalité de journalisation des flux de groupe de sécurité réseau sont utilisées à ces fins.

Scénario 2 : Hub-and-spoke avec une connectivité hybride sur des réseaux managés à l’aide de RDP Shortpath

Pour obtenir des instructions de déploiement détaillées, consultez Connectivité RDP Shortpath pour les réseaux managés.

Profil client

Ce scénario est idéal dans les cas suivants :

• Vous souhaitez limiter le nombre de connexions sur Internet aux hôtes de session Azure Virtual Desktop.
• Vous disposez d’une connectivité hybride préexistante à partir d’un environnement local vers Azure, via ExpressRoute ou un VPN S2S ou point à site (P2S).
• Vous disposez d’une connectivité réseau directe entre les clients RDP et les hôtes Azure Virtual Desktop. En règle générale, l’une des configurations suivantes est utilisée dans ce scénario :
  • Réseaux locaux routés vers des réseaux Azure Virtual Desktop
  • Connexions VPN clientes routées vers des réseaux virtuels Azure Virtual Desktop
• Vous devez limiter l’utilisation de la bande passante des hôtes de machine virtuelle sur des réseaux privés, tels que VPN ou ExpressRoute.
• Vous souhaitez rendre prioritaire le trafic Azure Virtual Desktop sur votre réseau.
• Vous n’avez pas besoin d’une inspection de trafic entre les réseaux Azure Virtual Desktop et les autres réseaux virtuels Azure.
• Vous n’avez pas besoin d’une inspection de trafic entre les réseaux Azure Virtual Desktop et les centres de données locaux.
• Vous disposez de serveurs personnalisés AD DS ou DNS préexistants.

Composants architecturaux

Vous pouvez implémenter ce scénario avec :

• ExpressRoute ou une passerelle de réseau virtuel VPN pour la connectivité hybride aux environnements locaux avec une bande passante suffisante.
• Serveurs AD DS et serveurs DNS personnalisés.
• Groupes de sécurité réseau.
• Internet sortant via un chemin réseau virtuel Azure par défaut.
• Des objets de stratégie de groupe de domaine ou objets de stratégie de groupe locaux.
• Des comptes de stockage Azure Files.
• Points de terminaison privés Azure.
• Une zone DNS privée Azure.

À propos de l’installation

• La connectivité hybride doit être disponible, via un VPN ou ExpressRoute, avec une connectivité réseau directe du client RDP aux hôtes de machine virtuelle privée sur le port 3390.

Remarque

Pour les réseaux managés, le port UDP par défaut peut être modifié.

• Un objet de stratégie de groupe de domaine ou un objet de stratégie de groupe local doit être utilisé pour activer UDP sur des réseaux managés.
• La connectivité hybride doit disposer d’une bande passante suffisante pour autoriser des connexions directes UDP aux hôtes de machine virtuelle.
• La connectivité hybride doit disposer d’un routage direct pour autoriser les connexions aux hôtes de machine virtuelle.
• La passerelle de plan de contrôle Azure Virtual Desktop, qui utilise un point de terminaison public, gère les connexions clientes. Par conséquent, les clients Azure Virtual Desktop peuvent créer des connexions sortantes vers les URL Azure Virtual Desktop nécessaires. Pour plus d’informations sur les URL requises, consultez la section Internet de cet article et URL requises pour Azure Virtual Desktop.
• Aucune adresse IP publique ou autre chemin entrant public vers les hôtes de session n’est nécessaire. Le trafic entre les clients et les hôtes de session transite par la passerelle du plan de contrôle Azure Virtual Desktop.
• Les connexions Internet sortantes à partir des hôtes de session Azure Virtual Desktop passent par le processus NAT sortant Azure par défaut. Des adresses IP publiques Azure dynamiques sont utilisées. Les clients n’ont aucun contrôle sur les adresses IP publiques sortantes utilisées.
• Les connexions des hôtes de session aux comptes de stockage Azure Files sont établies à l’aide de points de terminaison privés.
• Les zones DNS privées Azure sont utilisées pour résoudre les espaces de noms de points de terminaison privés.
• Le filtrage réseau n’est pas appliqué pour ce scénario. Toutefois, des groupes de sécurité réseau sont placés sur tous les sous-réseaux afin de pouvoir superviser le trafic et dériver des insights. Dans Network Watcher, l’analytique du trafic et la fonctionnalité de journalisation des flux de groupe de sécurité réseau sont utilisées à ces fins.

Remarque

Actuellement, Azure Virtual Desktop ne prend pas en charge l’utilisation simultanée de Private Link et RDP Shortpath.

Scénario 3 : Hub-and-spoke avec des réseaux publics utilisant RDP Shortpath

Pour obtenir des instructions de déploiement détaillées, consultez Connectivité RDP Shortpath pour les réseaux publics.

Profil client

Ce scénario est idéal dans les cas suivants :

• Vos connexions clientes Azure Virtual Desktop transitent par l’Internet public. Les scénarios classiques incluent les utilisateurs travaillant à domicile, les utilisateurs de succursales distantes qui ne sont pas connectés aux réseaux d’entreprise, et les utilisateurs sous-traitants distants.
• Vous disposez de connexions à faible latence ou à faible bande passante aux hôtes de session Azure Virtual Desktops.
• Vous devez limiter l’utilisation de la bande passante des hôtes de session Azure Virtual Desktop via des stratégies réseau QoS.
• Vous souhaitez rendre prioritaire le trafic Azure Virtual Desktop sur votre réseau via des stratégies QoS.
• Les connexions RDP clientes proviennent de réseaux ayant une bande passante et une vitesse irrégulières.
• Vous disposez d’une connectivité sortante directe à partir d’hôtes de session Azure Virtual Desktop. Vous n’utilisez pas de routage à tunneling forcé via des réseaux locaux.
• Vous n’avez pas besoin d’une inspection de trafic entre les réseaux Azure Virtual Desktop et les autres réseaux virtuels Azure.
• Vous n’avez pas besoin d’une inspection de trafic entre les réseaux Azure Virtual Desktop et les centres de données locaux.
• Vous disposez de serveurs personnalisés AD DS ou DNS préexistants.

Composants architecturaux

Vous pouvez implémenter ce scénario avec :

• ExpressRoute ou une passerelle de réseau virtuel VPN pour la connectivité hybride vers les environnements locaux. Cette configuration est appropriée lorsque la bande passante est suffisante pour prendre en charge les connexions aux applications ou données locales, ou les connexions AD DS. Nous vous déconseillons d’utiliser le tunneling forcé pour envoyer le trafic Azure Virtual Desktop via des routeurs locaux.
• Serveurs AD DS et serveurs DNS personnalisés.
• Groupes de sécurité réseau.
• Network Watcher.
• Internet sortant via un chemin réseau virtuel Azure par défaut.
• Des objets de stratégie de groupe de domaine ou objets de stratégie de groupe locaux.
• Des comptes de stockage Azure Files.
• Points de terminaison privés Azure.
• Une zone DNS privée Azure.

À propos de l’installation

• Autorisez les types de connexions suivants :

  • Connexions UDP sortantes à partir d’hôtes de session Azure Virtual Desktop vers les utilitaires de traversée de session pour NAT (STUN) Azure Virtual Desktop et les services TURN (Traversal Using Relay NAT) sur le port 3478
  • Connexions UDP à partir de clients RDP dans la plage de ports 49 152-65 535

  Le paramètre qui configure ces connexions est activé par défaut et conserve le même niveau de chiffrement que la connexion inverse TCP (Transmission Control Protocol). Pour plus d’informations sur la limitation des plages de ports de clients RDP, consultez Limiter la plage de ports lors de l’utilisation de RDP Shortpath pour les réseaux publics.

• La passerelle de plan de contrôle Azure Virtual Desktop, qui utilise un point de terminaison public, gère les connexions clientes. Par conséquent, les clients Azure Virtual Desktop peuvent créer des connexions sortantes vers les URL Azure Virtual Desktop nécessaires. Pour plus d’informations sur les URL requises, consultez la section Internet de cet article et URL requises pour Azure Virtual Desktop.

• Sur les routeurs grand public qui se trouvent généralement dans les réseaux d’utilisateurs domestiques, UPnP (Universal Plug and Play) doit être activé.

• Aucune adresse IP publique ou autre chemin entrant public vers les hôtes de session n’est nécessaire. Le trafic entre les clients et les hôtes de session transite par la passerelle du plan de contrôle Azure Virtual Desktop.

• Les connexions Internet sortantes à partir des hôtes de session Azure Virtual Desktop passent par le processus NAT sortant Azure par défaut. Des adresses IP publiques Azure dynamiques sont utilisées. Les clients n’ont aucun contrôle sur les adresses IP publiques sortantes utilisées.

• Vous devez configurer DSCP (Differentiated Services Code Point) sur les hôtes de session. Utilisez des objets de stratégie de groupe locaux ou des objets de stratégie de groupe de domaine pour cette configuration. Lorsque vous utilisez des marqueurs DSCP, les appareils réseau peuvent appliquer des stratégies QoS pour le trafic Azure Virtual Desktop. Pour plus d’informations, consultez Implémenter la qualité de service (QoS) pour Azure Virtual Desktop.

• Les connexions des hôtes de session aux comptes de stockage Azure Files sont établies à l’aide de points de terminaison privés.

• Les zones DNS privées Azure sont utilisées pour résoudre les espaces de noms de points de terminaison privés.

• Le filtrage réseau n’est pas appliqué pour ce scénario. Toutefois, des groupes de sécurité réseau sont placés sur tous les sous-réseaux afin de pouvoir superviser le trafic et dériver des insights. Dans Network Watcher, l’analytique du trafic et la fonctionnalité de journalisation des flux de groupe de sécurité réseau sont utilisées à ces fins.

Recommandations et considérations générales relatives à la conception

Les sections suivantes fournissent des recommandations et considérations générales relatives à la conception pour la connectivité et la topologie réseau Azure Virtual Desktop.

Hub-and-spoke vs Topologie de réseau Virtual WAN

Virtual WAN prend en charge la connectivité de transit entre VPN et ExpressRoute, mais ne prend pas en charge les topologies hub-and-spoke.

Services d’identité

Les exigences de connectivité des services d’identité dans les hôtes de session Azure Virtual Desktop dépendent du modèle d’identité.

• Pour les machines virtuelles jointes à Microsoft Entra Domain Services : les réseaux Azure Virtual Desktop doivent disposer d’une connectivité au réseau où le service d’identité est hébergé.
• Pour les machines virtuelles jointes à Microsoft Entra ID : les hôtes de session Azure Virtual Desktop créent des connexions sortantes vers les points de terminaison publics Microsoft Entra ID. Par conséquent, aucune configuration de connectivité privée n’est requise.

DNS

Les hôtes de session Azure Virtual Desktop ont les mêmes exigences de résolution de noms que toute autre charge de travail IaaS (infrastructure as a service). Par conséquent, la connectivité aux serveurs DNS personnalisés ou l’accès via une liaison de réseau virtuel à des zones DNS privées Azure est requis. Des zones DNS privées Azure supplémentaires sont requises pour héberger les espaces de noms de points de terminaison privés de certains services PaaS (platform as a service), tels que les comptes de stockage et les services de gestion des clés.

Pour plus d’informations, consultez Configuration DNS des points de terminaison privés Azure.

Pour faciliter la configuration du client Azure Virtual Desktop de l’utilisateur final, y compris l’abonnement au flux des services Bureau à distance (RDS), il est préférable de configurer la découverte des e-mails. Vous devez configurer la découverte des e-mails dans le domaine DNS public, puis vous abonner à votre flux RDS. Pour plus d’informations, consultez Configurer la découverte des e-mails pour vous abonner à votre flux RDS.

Bande passante et latence

Azure Virtual Desktop utilise le protocole RDP. Pour en savoir plus sur le protocole RDP, consultez Exigences en matière de bande passante RDP (Remote Desktop Protocol).

La latence de connexion varie en fonction de la localisation des utilisateurs et des machines virtuelles. Les services Azure Virtual Desktop sont déployés en permanence vers de nouvelles zones géographiques pour améliorer la latence. Pour réduire la latence rencontrée par les clients Azure Virtual Desktop, utilisez l’Estimateur d’expérience Azure Virtual Desktop. Cet outil fournit des exemples de RTT (round-trip time) de clients. Vous pouvez utiliser ces informations pour placer des hôtes de session dans la région qui est la plus proche des utilisateurs finaux et dont le RTT est le plus faible. Pour plus d’informations sur l’interprétation des résultats de l’outil estimateur, consultez Analyser la qualité de la connexion dans Azure Virtual Desktop.

QoS avec RDP Shortpath

RDP Shortpath pour les réseaux managés fournit un transport UDP direct entre un client Bureau à distance et un hôte de session. RDP Shortpath pour les réseaux managés permet de configurer des stratégies QoS pour les données RDP. QoS dans Azure Virtual Desktop permet au trafic RDP en temps réel qui est sensible aux retards réseau de passer avant le trafic qui y est moins sensible.

Vous pouvez utiliser RDP Shortpath de deux façons :

• Dans des réseaux managés, où une connectivité directe est établie entre le client et l’hôte de session lorsque vous utilisez une connexion privée, par exemple une connexion ExpressRoute ou un VPN.
• Dans des réseaux publics, où une connectivité directe est établie entre le client et l’hôte de session lorsque vous utilisez une connexion publique. Parmi les connexions publiques, citons les réseaux domestiques, les réseaux des cafés et les réseaux des hôtels. Il existe deux types de connexion possibles lorsque vous utilisez une connexion publique :

  • Une connexion UDP directe entre un client et un hôte de session qui utilise le protocole STUN.

  • Une connexion UDP indirecte qui utilise le protocole TURN avec un relais entre un client RDP et un hôte de session. Cette option est utilisée si la passerelle ou le routeur n’autorise pas les connexions UDP directes.

    Remarque

    À l’heure actuelle, l’utilisation de la fonctionnalité RDP Shortpath pour les réseaux publics avec TURN pour Azure Virtual Desktop est en préversion. Pour plus d’informations, consultez RDP Shortpath pour Azure Virtual Desktop.

Le chemin RDP étend les capacités multitransport du protocole RDP. Il ne remplace pas le transport de connexion inverse mais le complète.

La répartition de session initiale est gérée via le service Azure Virtual Desktop et le transport de connexion inverse, qui est basé sur TCP. Toutes les tentatives de connexion sont ignorées, sauf si elles correspondent d’abord à la session de connexion inverse.

RDP Shortpath, qui est basé sur UDP, est établi après l’authentification. Si RDP Shortpath est correctement établi, le transport de connexion inverse est supprimé. Ensuite, tout le trafic circule par le biais de l’une des méthodes RDP Shortpath listées plus haut dans cette section.

Pour plus d’informations, consultez Implémenter la qualité de service (QoS) pour Azure Virtual Desktop.

Internet

Les ressources de calcul et les clients Azure Virtual Desktop doivent accéder à des points de terminaison publics spécifiques, ils ont donc besoin de connexions Internet. Les scénarios de réseau, tels que le tunneling forcé pour durcir la sécurité et le filtrage, sont pris en charge quand les exigences d’Azure Virtual Desktop sont satisfaites.

Pour comprendre les exigences relatives aux appareils clients et aux hôtes de session Azure Virtual Desktop, consultez URL requises pour Azure Virtual Desktop.

Exigences liées aux ports et aux protocoles

Les modèles de connexion Azure Virtual Desktop utilisent les ports et protocoles suivants :

• Modèle standard : 443/TCP
• Modèle RDP Shortpath : 443/TCP et 3390/UDP ou 3478/UDP pour le protocole STUN ou TURN

Continuité d’activité et reprise d’activité

Pour la continuité d’activité et la reprise d’activité, une configuration réseau spécifique est requise. Plus précisément, pour déployer et récupérer des ressources dans un environnement cible, utilisez l’une des configurations suivantes :

• Une configuration réseau avec les mêmes capacités que celles de l’environnement source
• Une configuration réseau ayant une connectivité aux services d’identité et DNS

Étapes suivantes

Découvrez l’organisation des ressources dans un scénario Azure Virtual Desktop à l’échelle de l’entreprise.

Organisation des ressources