Para que el proceso de implementación del pod implemente el pod correctamente en Microsoft Azure, debe configurar los firewalls para permitir que el administrador de pods activo acceda a las direcciones del servicio de nombres de dominio (DNS) que necesita. Además, el DNS debe resolver nombres específicos, como se describe en este tema. Además de la implementación del pod principal, cuando se implementa la puerta de enlace externa en su propia VNet, esa subred de la VNet debe cumplir los mismos requisitos de DNS que la subred de administración de la VNet del pod independiente, tal como se describe en este tema.

Importante:

El proceso de implementación del pod utiliza una máquina virtual de Jump Box. Esta máquina virtual de Jump Box tiene requisitos de puertos y protocolos para el proceso de implementación del pod, así como para configurar las opciones de las máquinas virtuales de Unified Access Gateway del pod cuando se implementa una configuración de Unified Access Gateway para el pod. Consulte Puertos y protocolos requeridos por Jump Box del pod durante las implementaciones y las actualizaciones del pod.

La implementación de la puerta de enlace externa en su propia VNet también utiliza su propia máquina virtual de Jump Box, independiente de la del pod. Esa máquina virtual de Jump Box tiene sus propios requisitos de puertos y protocolos para el proceso de implementación de la puerta de enlace. Consulte Cuando la puerta de enlace externa se implementa en su propia VNet: requisitos de puertos y protocolos del Jump Box de la configuración de puerta de enlace externa durante las implementaciones y las actualizaciones de la puerta de enlace.

Después de que un pod se implementa correctamente, se necesitan protocolos y puertos específicos para las operaciones de Horizon Cloud en curso. Los puertos y los protocolos específicos necesarios dependen de si el pod tiene la versión de manifiesto de la versión de septiembre de 2019 o una versión de manifiesto anterior.

Requisitos de DNS para el proceso de implementación del pod global, las actualizaciones del pod y las operaciones en curso

Debe asegurarse de que los siguientes nombres DNS puedan resolverse y accederse desde las subredes de tenant y de administración con los protocolos y puertos específicos, como se indica en la siguiente tabla. Horizon Cloud utiliza los puertos de salida específicos para descargar de forma segura el software del pod en su entorno de Microsoft Azure y para que el pod se pueda conectar con el plano de control de Horizon Cloud. Debe configurar el firewall de red, las reglas de grupo de seguridad de red (NSG) y los servidores de proxy de modo que el administrador de pods activo tenga la capacidad de ponerse en contacto con las direcciones DNS en los puertos que requiera. De lo contrario, se producirá un error en el proceso de implementación del pod.

Importante:
  • Cuando se utiliza la función para implementar la puerta de enlace externa en su propia VNet, la subred de administración de esa VNet debe cumplir los mismos requisitos de DNS que se indican en la tabla a continuación para la subred de administración en la VNet del pod. La subred de DMZ y la subred de back-end de la VNet de la puerta de enlace externa no tienen requisitos de DNS específicos.
  • Cuando se implementa el pod con una puerta de enlace externa, una puerta de enlace interna o ambas, se debe cargar un certificado que el implementador de pods configurará en esas configuraciones de puerta de enlace. Si el certificado o los certificados que proporciona para este propósito usan ajustes de CRL (Lista de revocación de certificados) o OCSP (Protocolo de estado de certificados en línea) que hacen referencia a nombres de DNS específicos, debe asegurarse de que el acceso a Internet saliente en la red virtual se pueda resolver y que se pueda acceder a ellos. Durante la configuración del certificado proporcionado en la configuración de la puerta de enlace de Unified Access Gateway, el software de Unified Access Gateway accederá a esos nombres DNS para comprobar el estado de revocación del certificado. Si no se puede acceder a esos nombres DNS, se producirá un error en la implementación del pod durante la fase de Conexión. Estos nombres dependen en gran medida de la entidad de certificación que se utilizó para obtener los certificados y, por lo tanto, no quedan bajo el control de VMware.

El correo electrónico de bienvenida al servicio de Horizon indicará en qué instancia del plano de control regional se creó la cuenta de tenant. Debido a un problema conocido que se producía al enviar el correo electrónico de bienvenida, es posible que, en el correo electrónico que reciba, se indiquen los nombres de cadena del sistema que se utilizan para las regiones en lugar de los nombres descriptivos. Si ve un nombre de cadena del sistema en el correo electrónico de bienvenida, puede utilizar la siguiente tabla para relacionar lo que se muestra en el correo electrónico con los nombres DNS del plano de control regional.

Tabla 1. Regiones del correo electrónico de bienvenida asignadas a nombres DNS del plano de control regional
El correo electrónico de bienvenida dice Nombre DNS regional
USA cloud.horizon.vmware.com
EU_CENTRAL_1 o Europe cloud-eu-central-1.horizon.vmware.com
AP_SOUTHEAST_2 o Australia cloud-ap-southeast-2.horizon.vmware.com
PROD1_NORTHCENTRALUS2_CP1 o USA-2 cloud-us-2.horizon.vmware.com
PROD1_NORTHEUROPE_CP1 o Europe-2 cloud-eu-2.horizon.vmware.com
PROD1_AUSTRALIAEAST_CP1 o Australia-2 cloud-ap-2.horizon.vmware.com
Japan cloud-jp.horizon.vmware.com
Tabla 2. Requisitos de DNS de operaciones e implementación del pod
Origen de subred Destino (nombre DNS) Puerto Protocolo Propósito
Administración Uno de los siguientes, según la instancia de plano de control de Horizon Cloud regional que se especifique en su cuenta de tenant de Horizon Cloud. La instancia regional se establece cuando se crea la cuenta, tal y como se describe en Incorporación a Horizon Cloud para Microsoft Azure, Horizon local y Horizon on VMware Cloud on AWS.
  • cloud.horizon.vmware.com
  • cloud-us-2.horizon.vmware.com
  • cloud-eu-central-1.horizon.vmware.com
  • cloud-eu-2.horizon.vmware.com
  • cloud-ap-southeast-2.horizon.vmware.com
  • cloud-ap-2.horizon.vmware.com
  • cloud-jp.horizon.vmware.com
443 TCP Instancia regional del plano de control de Horizon Cloud
  • Estados Unidos: cloud.horizon.vmware.com, cloud-us-2.horizon.vmware.com
  • Europa: cloud-eu-central-1.horizon.vmware.com, cloud-eu-2.horizon.vmware.com
  • Asia Pacífico: cloud-ap-southeast-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com
  • Japón: cloud-jp.horizon.vmware.com
Administración softwareupdate.vmware.com 443 TCP Servidor de paquete de software de VMware. Se utiliza para descargar actualizaciones del software relacionado con el agente que se usa en las operaciones relacionadas con la imagen del sistema.
Administración Uno de los siguientes nombres, en función de los nombres de DNS regionales que se apliquen a su cuenta.
  • d1mes20qfad06k.cloudfront.net
  • hydra-softwarelib-cdn.azureedge.net
443 TCP Servidor de distribución de contenido de Horizon Cloud. En la subred de administración, se utiliza este sitio para descargar los archivos VHD (discos duros virtuales) para el administrador de pods y las máquinas virtuales de Unified Access Gateway. También se utiliza para el VHD de la máquina virtual del conector de puerta de enlace, en caso de que la puerta de enlace externa se encuentre en su propia VNet.

d1mes20qfad06k.cloudfront.net corresponde a las instancias regionales para cloud.horizon.vmware.com, cloud-eu-central-1.horizon.vmware.com, cloud-ap-southeast-2.horizon.vmware.com.

hydra-softwarelib-cdn.azureedge.net corresponde a las instancias regionales para cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com, cloud-jp.horizon.vmware.com

Administración packages.microsoft.com 443 y 11371 TCP Servidor de paquete de software Microsoft. Se utiliza para descargar de forma segura el software de la interfaz de línea de comandos (CLI) de Microsoft Azure.
Administración azure.archive.ubuntu.com 80 TCP Servidor de paquete de software de Ubuntu. Utilizado por máquinas virtuales basadas en Linux relacionadas con el pod para las actualizaciones del sistema operativo Ubuntu.
Administración api.snapcraft.io 443 TCP Servidor de paquete de software de Ubuntu. Utilizado por máquinas virtuales basadas en Linux del pod para las actualizaciones del sistema operativo Ubuntu.
Administración archive.ubuntu.com 80 TCP Servidor de paquete de software de Ubuntu. Utilizado por máquinas virtuales basadas en Linux del pod para las actualizaciones del sistema operativo Ubuntu.
Administración changelogs.ubuntu.com 80 TCP Servidor de paquete de software de Ubuntu. Utilizado por máquinas virtuales basadas en Linux del pod para el seguimiento de las actualizaciones del sistema operativo Ubuntu.
Administración security.ubuntu.com 80 TCP Servidor de paquete de software de Ubuntu. Utilizado por máquinas virtuales basadas en Linux del pod para las actualizaciones del sistema operativo Ubuntu relacionadas con la seguridad.
Administración Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que va a implementar el pod:
  • Microsoft Azure (global): login.microsoftonline.com
  • Microsoft Azure, Alemania: login.microsoftonline.de
  • Microsoft Azure, China: login.chinacloudapi.cn
  • Microsoft Azure, gobierno de EE. UU.: login.microsoftonline.us
443 TCP Esta dirección web la suelen utilizar las aplicaciones para autenticarse en los servicios de Microsoft Azure. Para algunas descripciones de la documentación de Microsoft Azure, consulte Flujo de código de autorización de OAuth 2.0, Azure Active Directory 2.0 y el protocolo de OpenID Connect y Nubes nacionales. En el tema Nubes nacionales, se describen los diferentes endpoints de autenticación de Azure AD para cada nube nacional de Microsoft Azure.
Administración Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que va a implementar el pod:
  • Microsoft Azure (global): management.azure.com
  • Microsoft Azure, Alemania: management.microsoftazure.de
  • Microsoft Azure, China: management.chinacloudapi.cn
  • Microsoft Azure, gobierno de EE. UU.: management.usgovcloudapi.net
443 TCP Se utiliza para las solicitudes de API del pod a los endpoints del administrador de recursos de Microsoft Azure para usar los servicios de dicho administrador. El administrador de recursos de Microsoft Azure proporciona una capa de administración coherente para llevar a cabo tareas a través de Azure PowerShell, Azure CLI, el portal de Azure, la REST API y los SDK de cliente.
Administración Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que va a implementar el pod:
  • Microsoft Azure (global): graph.windows.net
  • Microsoft Azure, Alemania: graph.cloudapi.de
  • Microsoft Azure, China: graph.chinacloudapi.cn
  • Microsoft Azure, gobierno de EE. UU.: graph.windows.net
443 TCP El acceso a la API de gráfico de Azure Active Directory (Azure AD), que se utiliza para el acceso programático del pod a Azure Active Directory (Azure AD) a través de endpoints de la REST API de OData.
Administración Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que implementó el pod:
  • Microsoft Azure (global): *.blob.core.windows.net
  • Microsoft Azure, Alemania: *.blob.core.cloudapi.de
  • Microsoft Azure, China: *.blob.core.chinacloudapi.cn
  • Microsoft Azure, gobierno de EE. UU.: *.blob.core.usgovcloudapi.net
443 TCP Se utiliza para el acceso programático del pod a Azure Blob Storage. Azure Blob Storage es un servicio que sirve para almacenar grandes cantidades de datos de objeto sin estructura, como texto o datos binarios.
Administración Una de las siguientes opciones, en función de la nube de Microsoft Azure en la que implementó el pod:
  • Microsoft Azure (global): *.vault.azure.net
  • Microsoft Azure, Alemania: *.vault.microsoftazure.de
  • Microsoft Azure, China: *.vault.azure.cn
  • Microsoft Azure, gobierno de EE. UU.: *.vault.usgovcloudapi.net
443 TCP Se utiliza para la capacidad del pod para trabajar de forma programática con el servicio de nube de Azure Key Vault. Azure Key Vault es un servicio de nube que proporciona un almacén seguro para la información confidencial.
Administración Si el firewall o el NSG admiten el uso de etiquetas de servicio, una de las siguientes opciones:
  • Etiqueta de servicio SQL de Azure global: Sql
  • Etiqueta de servicio SQL específica de la región de Azure en la que se implementa el pod: Sql.región, como Sql.WestUS.

Si el firewall o el NSG no admiten el uso de etiquetas de servicio, puede utilizar el nombre de host de la base de datos. Este nombre sigue el patrón *.postgres.database.azure.com.

5432 TCP Se usa para la comunicación del pod con el servidor de base de datos de Microsoft Azure PostgreSQL. A partir de la versión de septiembre de 2019, los pods recién implementados después de esa fecha de publicación y los pods actualizados a la versión de manifiesto de la versión de septiembre de 2019 se configuran con un servidor de base de datos de Microsoft Azure PostgreSQL.

Para obtener información sobre las etiquetas de servicio en los grupos de seguridad, consulte el tema Etiquetas de servicio en la documentación de Microsoft Azure.

Administración Uno de los siguientes, según la instancia de plano de control de Horizon Cloud regional que se especifique en su cuenta de tenant de Horizon Cloud. La instancia regional se establece cuando se crea la cuenta, tal y como se describe en Incorporación a Horizon Cloud para Microsoft Azure, Horizon local y Horizon on VMware Cloud on AWS.
  • connector-azure-us.vmwarehorizon.com
  • connector-azure-eu.vmwarehorizon.com
  • connector-azure-aus.vmwarehorizon.com
  • connector-azure-jp.vmwarehorizon.com
443 TCP Instancia regional del servicio del Universal Broker.
  • Estados Unidos: connector-azure-us.vmwarehorizon.com
  • Europa: connector-azure-eu.vmwarehorizon.com
  • Australia: connector-azure-aus.vmwarehorizon.com
  • Japón: connector-azure-jp.vmwarehorizon.com
Arrendatario Uno de los siguientes nombres, en función de los nombres de DNS regionales que se apliquen a su cuenta.
  • d1mes20qfad06k.cloudfront.net
  • hydra-softwarelib-cdn.azureedge.net
443 TCP Servidor de distribución de contenido de Horizon Cloud. En la subred del tenant, el proceso automatizado Importar imagen del sistema utiliza este sitio para descargar al instalador del software relacionado con el agente.

d1mes20qfad06k.cloudfront.net corresponde a las instancias regionales para cloud.horizon.vmware.com, cloud-eu-central-1.horizon.vmware.com, cloud-ap-southeast-2.horizon.vmware.com.

hydra-softwarelib-cdn.azureedge.net corresponde a las instancias regionales para cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com, cloud-jp.horizon.vmware.com

Arrendatario Según el plano de control de Horizon Cloud regional especificado en la cuenta de Horizon Cloud:

América del Norte:

  • kinesis.us-east-1.amazonaws.com
  • query-prod-us-east-1.cms.vmware.com

Europa:

  • kinesis.eu-central-1.amazonaws.com
  • query-prod-eu-central-1.cms.vmware.com

Australia:

  • kinesis.ap-southeast-2.amazonaws.com
  • query-prod-ap-southeast-2.cms.vmware.com

Japón:

  • kinesis.ap-northeast-1.amazonaws.com
  • query-prod-ap-northeast-1.cms.vmware.com
443 TCP Servicio de supervisión en la nube (CMS)

Puertos y protocolos requeridos por Jump Box del pod durante las implementaciones y las actualizaciones del pod

Tal como se describe en Requisitos de máquina Virtual de Microsoft Azure para un pod de Horizon Cloud en Microsoft Azure, se usa una máquina virtual de Jump Box en la creación inicial de un pod y durante las actualizaciones de software posteriores en el entorno del pod. Después de crear un pod, se elimina la máquina virtual de Jump Box. A continuación, cuando se actualiza el pod, la máquina virtual de Jump Box se vuelve a crear para ejecutar el proceso de actualización, y se elimina cuando se completa la actualización. Estas actualizaciones incluyen cuando se edita un pod para agregar una configuración de Unified Access Gateway.

Nota: Un pod recién implementado en Microsoft Azure a partir de la versión de septiembre de 2019 o actualizado al nivel de manifiesto de la versión de septiembre de 2019 que tiene habilitada la función de alta disponibilidad tiene dos máquinas virtuales del administrador. En los siguientes párrafos, se utiliza el término "máquinas virtuales" en plural para indicar que la máquina virtual de Jump Box debe comunicarse con todas las máquinas virtuales del administrador del pod, independientemente de que el pod tenga una sola o dos.

Durante estos procesos, la máquina virtual de Jump Box se comunica con lo siguiente:

  • Las máquinas virtuales del administrador del pod que usan SSH al puerto 22 de las máquinas virtuales del administrador. Como resultado, durante el proceso de implementación y actualización del pod, se debe cumplir el requisito de comunicación entre la máquina virtual de Jump Box y el puerto 22 de las máquinas virtuales del administrador. Se debe habilitar el puerto 22 de las máquinas virtuales de administrador entre la máquina virtual de Jump Box como origen y las máquinas virtuales del administrador como destino.
  • La máquinas virtuales de Unified Access Gateway que utilizan HTTPS al puerto 9443 de esas máquinas virtuales, en caso de que un pod se implemente con, o se edite para agregar, una configuración de Unified Access Gateway. Como resultado, durante el proceso de implementación y actualización del pod, cuando la configuración del pod incluye Unified Access Gateway, se debe cumplir el requisito de comunicación entre la máquina virtual de Jump Box y el puerto 9443 de las máquinas virtuales de Unified Access Gateway. Se debe habilitar el puerto 9443 de las máquinas virtuales de Unified Access Gateway entre la máquina virtual de Jump Box como origen y las máquinas virtuales de Unified Access Gateway como destino.

Debido a que las direcciones IP de estas máquinas virtuales se asignan de forma dinámica, las reglas de red para permitir esta comunicación deben utilizar:

  • El CIDR de subred de administración como el origen y el destino, con el puerto de destino 22, el puerto de origen cualquiera y el protocolo TCP.
  • El CIDR de subred de administración como el origen y el destino, con el puerto de destino 9443, el puerto de origen cualquiera y el protocolo TCP, cuando se implica una configuración de Unified Access Gateway.
Nota: Las operaciones del pod en curso no requieren la disponibilidad del puerto 22 en las máquinas virtuales del administrador del pod. Sin embargo, si realiza una solicitud de soporte a VMware y el equipo de soporte determina que la forma de solucionar el problema de esa solicitud es implementar una máquina virtual de Jump Box para la comunicación SSH con las máquinas virtuales del administrador del pod, deberá cumplir este requisito de puerto mientras el equipo de soporte de VMware necesite el puerto para depurar el problema. El equipo de soporte de VMware le informará de los requisitos, según corresponda para cualquier situación de soporte.

Cuando la puerta de enlace externa se implementa en su propia VNet: requisitos de puertos y protocolos del Jump Box de la configuración de puerta de enlace externa durante las implementaciones y las actualizaciones de la puerta de enlace

Tal como se describe en Requisitos de máquina Virtual de Microsoft Azure para un pod de Horizon Cloud en Microsoft Azure, se usa una máquina virtual de Jump Box en la creación inicial de la puerta de enlace externa en su propia VNet y durante las actualizaciones de software posteriores en esa puerta de enlace. Después de crear la puerta de enlace externa en su propia VNet, se elimina la máquina virtual de Jump Box. A continuación, cuando se actualiza la puerta de enlace externa, la máquina virtual de Jump Box se vuelve a crear para ejecutar el proceso de actualización, y se elimina cuando se completa la actualización. Estas actualizaciones incluyen cuando se edita un pod para agregar una puerta de enlace externa en su propia VNet.

Durante estos procesos, la máquina virtual de Jump Box se comunica con lo siguiente:

  • Durante estos procesos, esa máquina virtual de Jump Box se comunica con la máquina virtual del conector de puerta de enlace mediante SSH con el puerto 22 de la máquina virtual del conector. Como resultado, durante el proceso de implementación y actualización de la puerta de enlace, se debe cumplir el requisito de comunicación entre la máquina virtual de Jump Box y el puerto 22 de las máquinas virtuales del conector. Se debe habilitar el puerto 22 de las máquinas virtuales del conector entre la máquina virtual de Jump Box como origen y las máquinas virtuales del conector como destino.
  • Las máquinas virtuales de Unified Access Gateway que usan HTTPS al puerto 9443 de esas máquinas virtuales. Como resultado, durante el proceso de implementación y actualización del pod, cuando la configuración del pod incluye Unified Access Gateway, se debe cumplir el requisito de comunicación entre la máquina virtual de Jump Box y el puerto 9443 de las máquinas virtuales de Unified Access Gateway. Se debe habilitar el puerto 9443 de las máquinas virtuales de Unified Access Gateway entre la máquina virtual de Jump Box como origen y las máquinas virtuales de Unified Access Gateway como destino.

Debido a que las direcciones IP de estas máquinas virtuales se asignan de forma dinámica, las reglas de red para permitir esta comunicación deben utilizar:

  • El CIDR de subred de administración como el origen y el destino, con el puerto de destino 22, el puerto de origen cualquiera y el protocolo TCP.
  • El CIDR de subred de administración como el origen y el destino, con el puerto de destino 9443, el puerto de origen cualquiera y el protocolo TCP.
Nota: Las operaciones de pod en curso no requieren la disponibilidad del puerto 22 en la máquina virtual del conector de puerta de enlace. Sin embargo, si realiza una solicitud de soporte a VMware y el equipo de soporte determina que la forma de solucionar el problema de esa solicitud es implementar una máquina virtual de Jump Box para la comunicación SSH con la máquina virtual del conector de esa puerta de enlace, deberá cumplir este requisito de puerto mientras el equipo de soporte de VMware necesite el puerto para depurar el problema. El equipo de soporte de VMware le informará de los requisitos, según corresponda para cualquier situación de soporte.