Topología de red y conectividad para Azure Virtual Desktop

El diseño y la implementación de las funcionalidades de red de Azure son fundamentales para la zona de aterrizaje de Azure Virtual Desktop. El artículo se basa en varios principios arquitectónicos de zonas de aterrizaje de escala empresarial de Cloud Adoption Framework y recomendaciones para administrar la topología de red y la conectividad a gran escala.

Las bases de diseño incluyen lo siguiente:

• Integración híbrida para la conectividad entre entornos locales, multinube y perimetrales, y usuarios globales. Para obtener más información, consulte Compatibilidad de la escala empresarial con la arquitectura híbrida y multinube.
• Rendimiento y confiabilidad a gran escala para una experiencia coherente y de baja latencia y escalabilidad de las cargas de trabajo.
• Seguridad de red basada en confianza cero para ayudar a proteger los perímetros de red y los flujos de tráfico. Para obtener más información, consulte Estrategias de seguridad de red de Azure.
• Extensibilidad para expandir fácilmente la superficie de red sin necesidad de repetir el trabajo de diseño.

Componentes y conceptos 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í, con Internet y con centros de datos locales. Una red virtual es similar a una red tradicional con la que trabajaría en su propio centro de datos. Sin embargo, una red virtual ofrece las ventajas de la infraestructura de Azure, como escalabilidad, disponibilidad y aislamiento.
• Una topología en estrella tipo hub-and-spoke es un tipo de arquitectura de red en el que una red virtual de centro sirve como punto central de la conectividad para varias redes virtuales de radio. El centro también puede ser el punto de conectividad con los centros de datos locales. Las redes virtuales de radio se emparejan con el centro y ayudan a aislar las cargas de trabajo.
• Azure Virtual WAN es un servicio de red que agrupa funciones de red, seguridad y enrutamiento en una única interfaz operativa.
• Una aplicación virtual de red (NVA) es un dispositivo de red que admite funciones como la conectividad, la entrega de aplicaciones, la optimización de red de área extensa (WAN) y la seguridad. Las NVA incluyen Azure Firewall y Azure Load Balancer.
• En el escenario de tunelización forzada, todo el tráfico enlazado a Internet que se origina en máquinas virtuales (VM) de Azure se enruta o se "fuerza" que pase por un dispositivo de inspección y auditoría. Un acceso no autorizado a Internet puede provocar la divulgación de información u otros tipos de infracciones de seguridad sin la inspección o la auditoría del tráfico.
• Los grupos de seguridad de red (NSG) 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 ofrecen una manera de configurar la seguridad de red como extensión natural de la estructura de una aplicación. Puede usar los grupos de seguridad de aplicaciones para agrupar máquinas virtuales y definir directivas de seguridad de red basadas en dichos grupos. Puede reutilizar la directiva de seguridad a gran escala sin necesidad de mantener manualmente direcciones IP explícitas.
• Se pueden usar rutas definidas por el usuario (UDR) para invalidar las rutas del sistema predeterminadas de Azure. También puede usar UDR para agregar rutas adicionales a una tabla de rutas de subred.
• El protocolo de Escritorio remoto 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 basado en el protocolo de datagramas de usuario (UDP) entre un cliente de Escritorio remoto de Windows admitido 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 (versión preliminar) 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 por 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.

Escenarios de redes

Para establecer la zona de aterrizaje de Azure Virtual Desktop, es esencial diseñar e implementar las funcionalidades de red. Los servicios y productos de redes de Azure admiten una amplia variedad de funcionalidades. La arquitectura que elija y la forma de estructurar los servicios dependen de las cargas de trabajo, la gobernanza y los requisitos de la organización.

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

• Requisitos de las entradas y salidas de Internet.
• Uso de NVA en la arquitectura actual.
• Conectividad de Azure Virtual Desktop con una red virtual de centro 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 de tráfico para:
  • Salida de Internet desde Azure Virtual Desktop.
  • Entrada a 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 red virtual.
  • Tráfico dentro de la red virtual de Azure Virtual Desktop.

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

Escenario 1: Centro y radio con conectividad híbrida

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

Perfil de cliente

Este escenario es ideal en las situaciones siguientes:

• No necesita inspeccionar el tráfico entre redes de Azure Virtual Desktop y otras redes virtuales de Azure.
• No necesita inspeccionar el tráfico entre redes de Azure Virtual Desktop y centros de datos locales.
• No es necesario inspeccionar el tráfico de salida a 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 impone el tráfico interno de redes de Azure Virtual Desktop.
• Tiene conectividad híbrida existente con entornos locales, ya sea a través de Azure ExpressRoute o una red privada virtual (VPN) de sitio a sitio (S2S).
• Tiene servidores personalizados de Active Directory Domain Services y Sistema de nombres de dominio (DNS).
• Consume Azure Virtual Desktop con un modelo de conexión estándar (sin RDP Shortpath).

Componentes de la arquitectura

Puede implementar este escenario con:

• Servidores AD DS y DNS personalizados.
• Grupos de seguridad de red.
• Azure Network Watcher.
• Internet saliente a través de una ruta de acceso predeterminada de Azure Virtual Network.
• ExpressRoute o 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.

Consideraciones

• 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 fluye 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 radios de Azure Virtual Desktop. Todo el tráfico pasa por el centro de conectividad.
• Las conexiones salientes a Internet desde hosts de sesión de Azure Virtual Desktop pasan por el proceso predeterminado de traducción de direcciones de red (NAT) salientes de Azure. Se usan direcciones IP públicas de Azure dinámicas. Los clientes no tienen control sobre las direcciones IP públicas salientes que se usan.
• Las conexiones desde los hosts de sesión a las cuentas de almacenamiento de Azure Files se establecen mediante puntos de conexión privados.
• Se usan zonas DNS privadas de Azure 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 en este escenario. Sin embargo, se colocan grupos de seguridad de red en todas las subredes para que pueda supervisar el tráfico y obtener información detallada. 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: Centro y radio con conectividad híbrida a través de redes administradas mediante RDP Shortpath

Para obtener una guía de implementación detallada, consulte Conectividad de RDP Shortpath para redes administradas.

Perfil de cliente

Este escenario es ideal en las situaciones siguientes:

• Quiere limitar el número de conexiones a través de Internet a los hosts de sesión de Azure Virtual Desktop.
• Ya tiene conectividad híbrida desde un entorno local a Azure, ya sea a través de ExpressRoute o de una VPN de punto a sitio (P2S).
• Tiene conectividad de red de visión 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 inspeccionar el tráfico entre redes de Azure Virtual Desktop y otras redes virtuales de Azure.
• No necesita inspeccionar el tráfico entre redes de Azure Virtual Desktop y centros de datos locales.
• Ya tiene servidores personalizados de AD DS y DNS.

Componentes de la arquitectura

Puede implementar este escenario con:

• ExpressRoute o una puerta de enlace de red virtual VPN para la conectividad híbrida con sistemas locales con ancho de banda suficiente.
• Servidores AD DS y DNS personalizados.
• Grupos de seguridad de red.
• Internet saliente a través de una ruta de acceso predeterminada de Azure Virtual Network.
• 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

• Debe haber conectividad híbrida, a través de una VPN o ExpressRoute, con conectividad de red directa de clientes RDP a hosts de máquina virtual privada en el puerto 3390.

Nota:

En el caso de las redes administradas, se puede cambiar el puerto UDP predeterminado.

• 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 fluye a través de la puerta de enlace del plano de control de Azure Virtual Desktop.
• Las conexiones salientes a Internet desde hosts de sesión de Azure Virtual Desktop pasan por el proceso NAT saliente predeterminado de Azure. Se usan direcciones IP públicas de Azure dinámicas. Los clientes no tienen control sobre las direcciones IP públicas salientes que se usan.
• Las conexiones desde los hosts de sesión a las cuentas de almacenamiento de Azure Files se establecen mediante puntos de conexión privados.
• Se usan zonas DNS privadas de Azure para resolver espacios de nombres de punto de conexión privado.
• El filtrado de red no se aplica en este escenario. Sin embargo, se colocan grupos de seguridad de red en todas las subredes para que pueda supervisar el tráfico y obtener información detallada. 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.

Nota:

Actualmente, Azure Virtual Desktop no admite el uso de Private Link y RDP Shortpath al mismo tiempo.

Escenario 3: Centro y radio con redes públicas mediante RDP Shortpath

Para obtener una guía detallada, consulte Conectividad de RDP Shortpath para redes administradas.

Perfil de cliente

Este escenario es ideal en las situaciones siguientes:

• Las conexiones de cliente de Azure Virtual Desktop atraviesan la red pública de Internet. Entre los escenarios típicos se incluyen usuarios que trabajan desde casa, usuarios de sucursal remota que no están conectados a redes corporativas y usuarios de contratistas remotos.
• Tiene conexiones de bajo ancho de banda o alta latencia a hosts de sesión de Azure Virtual Desktops.
• 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 mediante 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 mediante redes locales.
• No necesita inspeccionar el tráfico entre redes de Azure Virtual Desktop y otras redes virtuales de Azure.
• No necesita inspeccionar el tráfico entre redes de Azure Virtual Desktop y centros de datos locales.
• Ya tiene servidores personalizados de AD DS y DNS.

Componentes de la arquitectura

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 mediante enrutadores locales.
• Servidores AD DS y DNS personalizados.
• Grupos de seguridad de red.
• Network Watcher.
• Internet saliente a través de una ruta de acceso predeterminada de Azure Virtual Network.
• GPO de dominio o GPO locales.
• Cuentas de almacenamiento de Azure Files.
• Puntos de conexión privados de Azure.
• Una zona DNS privada de Azure.

Consideraciones

• Permita los siguientes tipos de conexiones:

  • Conexiones UDP salientes desde los hosts de sesión de Azure Virtual Desktop hasta los servicios Session Traversal Utilities for NAT (STUN) y Traversal Using Relay NAT (TURN) de Azure Virtual Desktop en el puerto 3478
  • Conexiones UDP desde clientes RDP en el intervalo de puertos 49152–65535.

  La opció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 información sobre cómo limitar los intervalos de puertos de cliente RDP, consulte Limitación del 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 fluye a través de la puerta de enlace del plano de control de Azure Virtual Desktop.

• Las conexiones salientes a Internet desde hosts de sesión de Azure Virtual Desktop pasan por el proceso NAT saliente predeterminado de Azure. Se usan direcciones IP públicas de Azure dinámicas. 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 al 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 de hosts de sesión a cuentas de almacenamiento de Azure Files se establecen mediante puntos de conexión privados.

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

• El filtrado de red no se aplica en este escenario. Sin embargo, se colocan grupos de seguridad de red en todas las subredes para que pueda supervisar el tráfico y obtener información detallada. 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.

Recomendaciones y consideraciones generales de diseño

En las secciones siguientes se proporcionan algunas consideraciones y recomendaciones generales de diseño para la conectividad y la topología de red de Azure Virtual Desktop.

Centro y radio frente a Topología de red de Virtual WAN

Virtual WAN admite la conectividad de tránsito entre VPN y ExpressRoute, pero no la topología de red en estrella tipo hub-and-spoke.

Servicios de identidad

Los requisitos de conectividad de los servicios de identidad de los hosts de sesión de Azure Virtual Desktop dependen del modelo de identidad.

• Para máquinas virtuales unidas a Microsoft Entra Domain Services: las redes de Azure Virtual Desktop deben tener conectividad a la red donde se hospeda el servicio de identidad.
• Para máquinas virtuales unidas a Microsoft Entra: los hosts de sesión de Azure Virtual Desktop crean conexiones salientes a puntos de conexión públicos de Microsoft Entra ID. Como resultado, no se requieren configuraciones de conectividad privada.

DNS

Los hosts de sesión de Azure Virtual Desktop tienen los mismos requisitos de 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 de Azure adicionales para hospedar los espacios de nombres de 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.

Para facilitar la configuración del cliente de Azure Virtual Desktop para el usuario final, incluida la suscripción a la fuente de Servicios de Escritorio remoto (RDS), es mejor configurar la detección de correo electrónico. Debe configurar la detección de correo electrónico en el dominio de DNS público y, luego, suscribirse a la fuente de RDS. Para más información, consulte Configuración de la detección de correo electrónico para suscribirse a la fuente de RDS.

Ancho de banda y latencia

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 la conexión varía en función de la ubicación de los usuarios y las máquinas virtuales. Los servicios de Azure Virtual Desktop se implementan continuamente en geografías nuevas 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 información sobre cómo interpretar los resultados de la herramienta de estimación, consulte Análisis de la calidad de conexión en Azure Virtual Desktop.

QoS con RDP Shortpath

RDP Shortpath para redes administradas proporciona un transporte directo basado en UDP entre un cliente de Escritorio remoto y el host de sesión. RDP Shortpath para redes administradas proporciona una manera de configurar directivas de QoS para los datos de RDP. QoS en Azure Virtual Desktop permite que el tráfico de RDP en tiempo real que es sensible a los retrasos en la red "se cuele" delante del tráfico menos sensible.

Puede usar RDP Shortpath de dos maneras:

• Enredes 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.

    Nota:

    El uso de RDP Shortpath en redes públicas con TURN para Azure Virtual Desktop se encuentra actualmente en versión preliminar. Para más información, consulte RDP Shortpath para Azure Virtual Desktop.

RDP Shortpath amplía las capacidades multitransporte de RDP. No reemplaza el transporte de conexión inversa, sino que lo complementa.

La negociación de la sesión inicial se administra mediante el servicio Azure Virtual Desktop y el transporte de conexión inversa, que se basa 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 descarta 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 se enumeran anteriormente en esta sección.

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

Internet

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.

Requisitos de puerto y protocolo

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 cara a 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.

Pasos siguientes

Aprenda sobre la organización de recursos en un escenario de escala empresarial de Azure Virtual Desktop.

Organización de recursos