Guía de diseño de la topología de red y la conectividad de Azure Virtual Desktop

En este artículo se describe cómo diseñar la topología de red y la conectividad para Azure Virtual Desktop (AVD) dentro de una zona de aterrizaje de Azure. Ayuda a los responsables de la toma de decisiones técnicas a comprender los requisitos de red que sus equipos deben seguir para garantizar la conectividad segura y escalable entre Azure, las redes privadas y la red pública de Internet. Antes de que su organización implemente AVD, debe tener una zona de aterrizaje de Azure en su lugar. A continuación, implemente recursos de AVD en una zona de aterrizaje de la aplicación.

Componentes de red de AVD

Componentes principales de red

• Azure Virtual Network es el bloque de creación fundamental para las redes privadas en Azure. Con Virtual Network, muchos tipos de recursos de Azure, como Azure Virtual Machines, pueden comunicarse entre sí, Internet y centros de datos locales. Una red virtual es similar a una red tradicional que operas en tu propio centro de datos. Pero una red virtual ofrece las ventajas de la infraestructura de Azure de escala, disponibilidad y aislamiento.
• Hub-Spoke Network Topology es un tipo de arquitectura de red en la que una red virtual central actúa como punto central de conectividad a varias redes virtuales radiales. El centro también puede ser el punto de conectividad a los centros de datos locales. Las redes virtuales radiales se emparejan con el concentrador y ayudan a aislar las cargas de trabajo.
• Azure Virtual WAN es un servicio de red que reúne las funciones de red, seguridad y enrutamiento en una única interfaz operativa.

Protección del acceso y el control de tráfico

• Los grupos de seguridad de red se usan para filtrar el tráfico de red hacia y desde recursos de Azure en una red virtual de Azure. Un grupo de seguridad de red contiene reglas de seguridad que permiten o deniegan el tráfico de red entrante o el tráfico de red saliente de varios tipos de recursos de Azure.
• Los grupos de seguridad de aplicaciones proporcionan una manera de configurar la seguridad de red como una extensión natural de la estructura de una aplicación. Puede usar grupos de seguridad de aplicaciones para agrupar máquinas virtuales y definir directivas de seguridad de red basadas en esos grupos. Puede reutilizar la directiva de seguridad a escala sin necesidad de mantener manualmente direcciones IP explícitas.
• Una puerta de enlace NAT proporciona servicios NAT para el tráfico de salida de subredes privadas a Internet. No permite el tráfico entrante, excepto los paquetes de respuesta. Esta configuración proporciona entornos de Azure Virtual Desktop la capacidad de salir explícitamente a Internet y también mitigar los efectos de rendimiento del envío del tráfico del servicio AVD a través de un firewall o una aplicación virtual de red.

Enrutamiento y optimización

• Azure Firewall o aplicación virtual de red (NVA) es un dispositivo de red que admite funciones como conectividad, control de aplicaciones, optimización de red de área extensa (WAN) y seguridad. Las NVAs incluyen Azure Firewall y appliances de red de proveedores que se encuentran en el marketplace.
• Las rutas definidas por el usuario (UDR) se pueden usar para invalidar las rutas del sistema predeterminadas de Azure. También puede usar UDRs para agregar rutas adicionales a la tabla de rutas de la subred que permite enrutar tráfico específico y servicios de Azure a destinos a través de sus redes y Azure.

Mejoras de Azure Virtual Desktop

• Remote Desktop Protocol Shortpath (RDP Shortpath) es una característica de Azure Virtual Desktop basada en el Protocolo de control de velocidad universal (URCP). RDP Shortpath establece un transporte directo que usa el Protocolo de datagramas de usuario (UDP) entre un cliente de Escritorio remoto de Windows compatible y los hosts de sesión de Azure Virtual Desktop. URCP mejora las conexiones UDP al proporcionar una supervisión activa de las condiciones de red y las funcionalidades de calidad de servicio (QoS).
• Azure Private Link con Azure Virtual Desktop (opcional) proporciona una manera de usar un punto de conexión privado en Azure para conectar hosts de sesión al servicio Azure Virtual Desktop. Con Private Link, el tráfico entre la red virtual y el servicio Azure Virtual Desktop viaja en la red troncal de Microsoft. Como resultado, no es necesario conectarse a la red pública de Internet para acceder a los servicios de Azure Virtual Desktop.

Recomendaciones de redes de AVD

Azure Virtual Desktop requiere consideraciones de diseño de red específicas para garantizar una conectividad confiable, seguridad y rendimiento. La arquitectura de red afecta directamente a la experiencia del usuario, la protección de datos y la eficacia operativa en todo el entorno de escritorio virtual.

Planeamiento de la topología de red de AVD

Use Virtual WAN cuando necesite conectividad de tránsito entre VPN y ExpressRoute. Virtual WAN proporciona un modelo de concentrador y satélites administrado por Microsoft (centros virtuales y redes virtuales vinculadas) con enrutamiento transitivo integrado. Use Virtual WAN cuando necesite tránsito global administrado y enrutamiento/seguridad integrados.

Configuración de servicios de identidad de AVD

• Máquinas virtuales unidas a Microsoft Entra Domain Services: asegúrese de que las redes de Azure Virtual Desktop tienen conectividad con la red que hospeda el servicio de identidad.

• Máquinas virtuales unidas a Microsoft Entra ID: los hosts de sesión de Azure Virtual Desktop crean conexiones salientes a puntos de conexión públicos de Microsoft Entra ID. No se requieren configuraciones de conectividad privada.

Configuración de DNS de AVD

Los hosts de sesión de Azure Virtual Desktop tienen los mismos requisitos para la resolución de nombres que cualquier otra carga de trabajo de infraestructura como servicio (IaaS). Como resultado, se requiere conectividad a servidores DNS personalizados o acceso a través de un vínculo de red virtual a zonas DNS privadas de Azure. Se requieren zonas DNS privadas adicionales de Azure para hospedar los espacios de nombres del punto de conexión privado de determinados servicios de plataforma como servicio (PaaS), como cuentas de almacenamiento y servicios de administración de claves. Para más información, consulte Configuración de DNS para puntos de conexión privados de Azure.

Opcionalmente, puede configurar la detección de fuentes basadas en correo electrónico para simplificar la incorporación de usuarios. Los clientes modernos de Azure Virtual Desktop también pueden suscribirse directamente mediante la detección de áreas de trabajo a través del servicio sin la detección de correo electrónico basada en DNS. Para obtener más información, consulte Configurar la detección del correo electrónico para suscribirse a la fuente RDS.

Optimización del ancho de banda y la latencia de AVD

Azure Virtual Desktop usa RDP. Para más información sobre RDP, consulte Requisitos de ancho de banda del Protocolo de escritorio remoto (RDP).

La latencia de conexión varía, en función de la ubicación de los usuarios y de las máquinas virtuales. Los servicios de Azure Virtual Desktop se implementan continuamente en nuevas zonas geográficas para mejorar la latencia. Para minimizar la latencia que experimentan los clientes de Azure Virtual Desktop, use el estimador de experiencia de Azure Virtual Desktop. Esta herramienta proporciona ejemplos de tiempo de ida y vuelta (RTT) de clientes. Puede usar esta información para colocar hosts de sesión en la región más cercana a los usuarios finales y que tenga el RTT más bajo. Para obtener información sobre cómo interpretar los resultados de la herramienta estimador, consulte Análisis de la calidad de conexión en Azure Virtual Desktop.

Implementación de directivas de QoS de AVD con RDP Shortpath

RDP Shortpath para redes administradas proporciona un transporte directo basado en UDP entre un cliente de Escritorio remoto y un host de sesión. RDP Shortpath para redes administradas proporciona una manera de configurar directivas de QoS para los datos RDP. QoS en Azure Virtual Desktop permite que el tráfico RDP en tiempo real, que es sensible a los retrasos de red, tenga prioridad sobre el tráfico menos sensible. Puede usar RDP Shortpath de dos maneras:

• En redes administradas, donde se establece la conectividad directa entre el cliente y el host de sesión cuando se usa una conexión privada, como una conexión ExpressRoute o una VPN.

• En redes públicas, donde se establece la conectividad directa entre el cliente y el host de sesión cuando se usa una conexión pública. Algunos ejemplos de conexiones públicas incluyen redes domésticas, redes de cafeterías y redes de hoteles. Hay dos tipos de conexión posibles cuando se usa una conexión pública. Una conexión UDP directa entre un cliente y un host de sesión que usa el protocolo STUN. Una conexión UDP indirecta que usa el protocolo TURN con una retransmisión entre un cliente RDP y un host de sesión. Esta opción se usa si la puerta de enlace o el enrutador no permiten conexiones UDP directas.

La ruta de acceso RDP amplía las funcionalidades de transporte múltiple de RDP. No reemplaza el transporte de conexión inversa, sino que lo complementa. La intermediación de sesiones iniciales se gestiona a través del servicio Azure Virtual Desktop y el transporte de conexión inversa, que está basado en TCP. Todos los intentos de conexión se ignorarán a menos que primero coincidan con la sesión de conexión inversa.

RDP Shortpath, que se basa en UDP, se establece después de la autenticación. Si RDP Shortpath se establece correctamente, se desactiva el transporte de conexión inversa. A continuación, todo el tráfico fluye a través de uno de los métodos de RDP Shortpath que en esta sección se enumeran anteriormente. Para más información, consulte RDP Shortpath para Azure Virtual Desktop.

Para más información, consulte Implementación de calidad de servicio (QoS) para Azure Virtual Desktop.

Protección del acceso a Internet de AVD

Los recursos de proceso y los clientes de Azure Virtual Desktop requieren acceso a puntos de conexión públicos específicos, por lo que necesitan conexiones enlazadas a Internet. Los escenarios de red, como la tunelización forzada para mejorar la seguridad y el filtrado, se admiten cuando se cumplen los requisitos de Azure Virtual Desktop.

Para comprender los requisitos de los hosts de sesión y los dispositivos cliente de Azure Virtual Desktop, consulte Direcciones URL necesarias para Azure Virtual Desktop.

Validar los requisitos de protocolo y puerto de AVD

Los modelos de conexión de Azure Virtual Desktop usan los siguientes puertos y protocolos:

• Modelo estándar: 443/TCP
• Modelo de RDP Shortpath: 443/TCP y 3390/UDP o 3478/UDP para el protocolo STUN o TURN

Continuidad empresarial y recuperación ante desastres de AVD

Para la continuidad empresarial y la recuperación ante desastres, se requiere una determinada configuración de red. En concreto, para implementar y recuperar recursos en un entorno de destino, use una de las siguientes configuraciones:

• Una configuración de red con las mismas funcionalidades que la del entorno de origen
• Una configuración de red que tenga conectividad con los servicios de identidad y DNS

Escenarios de red de AVD

Para establecer la zona de aterrizaje de Azure Virtual Desktop, el diseño e implementación de las funcionalidades de red es fundamental. Los productos y servicios de red de Azure admiten una amplia variedad de funcionalidades. La arquitectura que elija y la forma en que estructura los servicios dependen de las cargas de trabajo, la gobernanza y los requisitos de su organización.

Los siguientes requisitos clave y consideraciones afectan a las decisiones de implementación de Azure Virtual Desktop:

• Requisitos de entrada y salida de Internet.
• Uso de NVA en la arquitectura actual.
• Conectividad de Azure Virtual Desktop a una red virtual de hub estándar o un centro de Virtual WAN.
• Modelo de conexión de host de sesión. Puede usar un modelo nativo o RDP Shortpath.
• Requisitos de inspección del tráfico para:
  • Salida de Internet desde Azure Virtual Desktop.
  • Ingreso de Internet a Azure Virtual Desktop.
  • Tráfico de Azure Virtual Desktop a centros de datos locales.
  • Tráfico de Azure Virtual Desktop a otras instancias de Virtual Network.
  • Tráfico dentro de la red virtual de Azure Virtual Desktop.

El escenario de red más común para Azure Virtual Desktop es una topología hub-and-spoke con conectividad híbrida.

Escenario 1: concentrador y radio con conectividad híbrida

En este escenario se usa el modelo de conexión de host de sesión estándar.

Perfil de cliente para concentrador y radio con conectividad híbrida

Este escenario es ideal si:

• No necesita la inspección del tráfico entre redes de Azure Virtual Desktop y otras redes virtuales de Azure.
• No necesita inspección del tráfico entre redes de Azure Virtual Desktop y centros de datos locales.
• No es necesario inspeccionar el tráfico de salida de Internet desde redes de Azure Virtual Desktop.
• No es necesario controlar las direcciones IP públicas que se usan durante la traducción de direcciones de red de origen (SNAT) para las conexiones salientes de Internet de Azure Virtual Desktop.
• No aplica el tráfico interno de red de Azure Virtual Desktop.
• Tiene una conectividad híbrida preexistente con entornos locales, ya sea a través de Azure ExpressRoute o de una VPN de sitio a sitio (S2S).
• Tiene servidores personalizados preexistentes de Active Directory Domain Services (AD DS) y Sistema de Nombres de Dominio (DNS).
• Puede consumir Azure Virtual Desktop mediante un modelo de conexión estándar, no RDP Shortpath.

Componentes arquitectónicos para el modelo hub and spoke con conectividad híbrida

Puede implementar este escenario con:

• Servidores de AD DS y servidores DNS personalizados.
• Grupos de seguridad de red.
• Azure Network Watcher.
• Internet saliente a través de una ruta predeterminada de la red virtual de Azure.
• ExpressRoute o una puerta de enlace de red virtual VPN para la conectividad híbrida con sistemas locales.
• Una zona DNS privada de Azure.
• Puntos de conexión privados de Azure.
• Cuentas de almacenamiento de Azure Files.
• Azure Key Vault

Descargue un archivo de Visio de la arquitectura resistente a varias regiones de Azure Virtual Desktop completa.

Consideraciones para el concentrador y radio con conectividad híbrida

• Este escenario no admite la conectividad directa de red entre un cliente y un host de sesión público o privado. No puede usar RDP Shortpath en este escenario.
• La puerta de enlace del plano de control de Azure Virtual Desktop, que usa un punto de conexión público, administra las conexiones de cliente. Como resultado, los clientes de Azure Virtual Desktop pueden crear conexiones salientes a las direcciones URL de Azure Virtual Desktop necesarias. Para más información sobre las direcciones URL necesarias, consulte la sección Internet de este artículo y direcciones URL necesarias para Azure Virtual Desktop.
• No se necesitan direcciones IP públicas ni otras rutas de acceso de entrada públicas a los hosts de sesión. El tráfico de los clientes a los hosts de sesión se transmite a través de la puerta de enlace del plano de control de Azure Virtual Desktop.
• No hay ningún emparejamiento de red virtual entre los spokes de Azure Virtual Desktop. Todo el tráfico pasa por el centro de conectividad.
• Las conexiones salientes a Internet de los hosts de sesión de Azure Virtual Desktop pasan por el proceso predeterminado de traducción de direcciones de red de salida de Azure (NAT). Se usan direcciones IP públicas dinámicas de Azure. Los clientes no tienen control sobre las direcciones IP públicas salientes que se usan.
• Las conexiones de los hosts de sesión a las cuentas de almacenamiento de Azure Files se establecen mediante puntos de conexión privados.
• Las zonas DNS privadas de Azure se usan para resolver espacios de nombres de punto de conexión privado para los siguientes servicios:
  • Cuentas de almacenamiento de Azure Files, que usan el nombre privatelink.file.core.windows.net
  • Almacenes de claves, que usan el nombre privatelink.vaultcore.azure.net
• El filtrado de red no se aplica para este escenario. Pero los grupos de seguridad de red se colocan en todas las subredes para que pueda supervisar el tráfico y derivar información. En Network Watcher, el análisis de tráfico y la característica de registro de flujo del grupo de seguridad de red se usan para estos fines.

Escenario 2: concentrador y radio con conectividad híbrida a través de redes administradas mediante RDP Shortpath

Para obtener instrucciones detalladas sobre la implementación, consulte Conectividad de RDP Shortpath para redes administradas.

Perfil de cliente para hub y nodo con conectividad híbrida a través de redes administradas usando RDP Shortpath

Este escenario es ideal si:

• Quiere limitar el número de conexiones a través de Internet a hosts de sesión de Azure Virtual Desktop.
• Tiene conectividad híbrida preexistente desde un entorno local a Azure, ya sea a través de ExpressRoute o una VPN de sitio a sitio (S2S) o de punto a sitio (P2S).
• Tiene conectividad de red con visibilidad directa entre clientes RDP y hosts de Azure Virtual Desktop. Normalmente, se usa una de las siguientes configuraciones en este escenario:
  • Redes locales que se enrutan a redes de Azure Virtual Desktop
  • Conexiones VPN de cliente que se enrutan a redes virtuales de Azure Virtual Desktop
• Debe limitar el uso de ancho de banda de los hosts de máquina virtual a través de redes privadas, como una VPN o ExpressRoute.
• Quiere priorizar el tráfico de Azure Virtual Desktop en la red.
• No necesita la inspección del tráfico entre redes de Azure Virtual Desktop y otras redes virtuales de Azure.
• No necesita inspección del tráfico entre redes de Azure Virtual Desktop y centros de datos locales.
• Tiene servidores personalizados de Active Directory Domain Services (AD DS) o Domain Name System (DNS) ya preexistentes.

Componentes arquitectónicos para hub-and-spoke con conectividad híbrida a través de redes administradas utilizando RDP Shortpath

Puede implementar este escenario con:

• ExpressRoute o una puerta de enlace de red virtual VPN para lograr la conectividad híbrida hacia entornos locales, asegurando un ancho de banda suficiente.
• Servidores de AD DS y servidores DNS personalizados.
• Grupos de seguridad de red.
• Internet saliente a través de una ruta predeterminada de la red virtual de Azure.
• Objetos de directiva de grupo de dominio (GPO) o GPO locales.
• Cuentas de almacenamiento de Azure Files.
• Puntos de conexión privados de Azure.
• Una zona DNS privada de Azure.

Consideraciones para la topología de hub and spoke con conectividad híbrida a través de redes administradas mediante RDP Shortpath

• La conectividad híbrida debe estar disponible a través de una VPN o ExpressRoute, con conectividad directa de red del cliente RDP a los anfitriones de MV privados en el puerto 3390.

• Se debe usar un GPO de dominio o un GPO local para habilitar UDP a través de redes administradas.
• La conectividad híbrida debe tener suficiente ancho de banda para permitir conexiones directas UDP a hosts de máquina virtual.
• La conectividad híbrida debe tener enrutamiento directo para permitir conexiones a hosts de máquina virtual.
• La puerta de enlace del plano de control de Azure Virtual Desktop, que usa un punto de conexión público, administra las conexiones de cliente. Como resultado, los clientes de Azure Virtual Desktop pueden crear conexiones salientes a las direcciones URL de Azure Virtual Desktop necesarias. Para más información sobre las direcciones URL necesarias, consulte la sección Internet de este artículo y direcciones URL necesarias para Azure Virtual Desktop.
• No se necesitan direcciones IP públicas ni otras rutas de acceso de entrada públicas a los hosts de sesión. El tráfico de los clientes a los hosts de sesión se transmite a través de la puerta de enlace del plano de control de Azure Virtual Desktop.
• La conexión saliente a Internet de los hosts de sesión de Azure Virtual Desktop pasa por el proceso NAT de salida de Azure predeterminado. Se usan direcciones IP públicas dinámicas de Azure. Los clientes no tienen control sobre las direcciones IP públicas salientes que se usan.
• Las conexiones de los hosts de sesión a las cuentas de almacenamiento de Azure Files se establecen mediante puntos de conexión privados.
• Las zonas DNS privadas de Azure se usan para resolver espacios de nombres de punto de conexión privado.
• El filtrado de red no se aplica para este escenario. Pero los grupos de seguridad de red se colocan en todas las subredes para que pueda supervisar el tráfico y derivar información. En Network Watcher, el análisis de tráfico y la característica de registro de flujo del grupo de seguridad de red se usan para estos fines.

Escenario 3: Hub y Spoke con redes públicas usando RDP Shortpath

Para obtener instrucciones detalladas sobre la implementación, consulte Conectividad de RDP Shortpath para redes públicas.

Perfil de cliente para concentrador y radio con redes públicas mediante RDP Shortpath

Este escenario es ideal si:

• Las conexiones de cliente de Azure Virtual Desktop atraviesan la red pública de Internet. Entre los escenarios típicos se incluyen usuarios de trabajo desde casa, usuarios de sucursal remota que no están conectados a redes corporativas y usuarios de contratistas remotos.
• Tiene conexiones de alta latencia o bajo ancho de banda a hosts de sesión de Azure Virtual Desktop.
• Debe limitar el uso de ancho de banda de los hosts de sesión de Azure Virtual Desktop a través de directivas de red de QoS.
• Quiere priorizar el tráfico de Azure Virtual Desktop en la red a través de directivas de QoS.
• Las conexiones RDP de cliente comienzan desde redes con ancho de banda y velocidad incoherentes.
• Tiene conectividad de salida directa desde hosts de sesión de Azure Virtual Desktop. No se usa un enrutamiento de túnel forzado a través de redes locales.
• No necesita la inspección del tráfico entre redes de Azure Virtual Desktop y otras redes virtuales de Azure.
• No necesita inspección del tráfico entre redes de Azure Virtual Desktop y centros de datos locales.
• Tiene servidores personalizados de Active Directory Domain Services (AD DS) o Domain Name System (DNS) ya preexistentes.

Componentes arquitectónicos para concentrador y radio con redes públicas mediante RDP Shortpath

Puede implementar este escenario con:

• ExpressRoute o una puerta de enlace de red virtual VPN para la conectividad híbrida con entornos locales. Esta configuración es adecuada cuando hay suficiente ancho de banda para admitir conexiones a aplicaciones locales, datos o conexiones de AD DS. No se recomienda usar la tunelización forzada para enviar tráfico de Azure Virtual Desktop a través de enrutadores locales.
• Servidores de AD DS y servidores DNS personalizados.
• Grupos de seguridad de red.
• Network Watcher.
• Internet saliente a través de una ruta predeterminada de la red virtual de Azure.
• GPO de dominio o GPO local.
• Cuentas de almacenamiento de Azure Files.
• Puntos de conexión privados de Azure.
• Una zona DNS privada de Azure.

Consideraciones para el concentrador y el radio con redes públicas mediante RDP Shortpath

• Permita los siguientes tipos de conexiones:

  • Conexiones UDP salientes de los hosts de sesión de Azure Virtual Desktop a las utilidades de recorrido de sesión de Azure Virtual Desktop para NAT (STUN) y Traversal using Relay NAT (TURN) en el puerto 3478
  • Conexiones UDP desde clientes RDP en el intervalo de puertos 49152-65535

  La configuración que configura estas conexiones está activada de forma predeterminada y mantiene el mismo nivel de cifrado que la conexión inversa del Protocolo de control de transmisión (TCP). Para obtener información sobre cómo limitar los intervalos de puertos de cliente RDP, consulte Limitar el intervalo de puertos al usar RDP Shortpath para redes públicas.

• La puerta de enlace del plano de control de Azure Virtual Desktop, que usa un punto de conexión público, administra las conexiones de cliente. Como resultado, los clientes de Azure Virtual Desktop pueden crear conexiones salientes a las direcciones URL de Azure Virtual Desktop necesarias. Para más información sobre las direcciones URL necesarias, consulte la sección Internet de este artículo y direcciones URL necesarias para Azure Virtual Desktop.

• Los enrutadores de consumidor que normalmente se encuentran en las redes de usuarios domésticos deben tener habilitado Universal Plug and Play (UPnP).

• No se necesitan direcciones IP públicas ni otras rutas de acceso de entrada públicas a los hosts de sesión. El tráfico de los clientes a los hosts de sesión se transmite a través de la puerta de enlace del plano de control de Azure Virtual Desktop.

• La conexión saliente a Internet de los hosts de sesión de Azure Virtual Desktop pasa por el proceso NAT de salida de Azure predeterminado. Se usan direcciones IP públicas dinámicas de Azure. Los clientes no tienen control sobre las direcciones IP públicas salientes que se usan.

• Debe configurar el marcado de punto de código de servicios diferenciados (DSCP) en los hosts de sesión. Use GPO locales o GPO de dominio para esta configuración. Al usar marcadores DSCP, los dispositivos de red pueden aplicar directivas de QoS para el tráfico de Azure Virtual Desktop. Para más información, consulte Implementación de calidad de servicio (QoS) para Azure Virtual Desktop.

• Las conexiones desde los hosts de sesión a las cuentas de almacenamiento de Azure Files se establecen mediante puntos de conexión privados.

• Las zonas DNS privadas de Azure se usan para resolver espacios de nombres de punto de conexión privado.

• El filtrado de red no se aplica para este escenario. Pero los grupos de seguridad de red se colocan en todas las subredes para que pueda supervisar el tráfico y derivar información. En Network Watcher, el análisis de tráfico y la característica de registro de flujo del grupo de seguridad de red se usan para estos fines.

Pasos siguientes

Obtenga información sobre la organización de recursos para un escenario de escala empresarial de Azure Virtual Desktop.