Para un uso correcto de extremo a extremo de las funciones del servicio, debe asegurarse de que los nombres DNS que se describen en este artículo de la documentación puedan resolverse y accederse desde las subredes de arrendatario y de administración con los protocolos y puertos específicos, como se indica en las tablas de este artículo. El proceso de implementación de pods que crea instancias de un pod basado en el administrador de pods en una suscripción de Microsoft Azure requiere que los dispositivos relacionados con el implementador tengan acceso a nombres DNS específicos a través de la VNet seleccionada. A continuación, después de crear correctamente una instancia de pod en la suscripción con sus dispositivos relacionados con el pod en funcionamiento, varias operaciones de servicio cotidianas requieren acceso a la red a nombres DNS específicos, así como el proceso de actualización del pod para actualizar el software del pod cuando VMware hace que el nuevo software esté disponible. En este artículo se describen estos requisitos de DNS.

Algunos puntos clave predominantes

Acerca de estos nombres DNS requeridos
El implementador de pods de Horizon Cloud que automatiza el proceso para crear instancias de pods basados en el administrador de pods y sus puertas de enlace asociadas en las suscripciones de Microsoft Azure requiere acceso de red a direcciones DNS específicas a través de las VNet de esas suscripciones. Para que el implementador de pods cree instancias correctamente de los componentes del pod en la suscripción, debe configurar los firewalls para permitir a los dispositivos relacionados con el implementador de claves el acceso de red que necesitan para acceder a esas direcciones DNS. El propósito de cada dirección DNS se indica en las tablas siguientes. Además de permitir la comunicación de red con esas direcciones DNS, la configuración de DNS debe resolver nombres específicos, como se describe en este artículo. Cuando se elige la opción para implementar la puerta de enlace externa en su propia VNet independiente de la VNet del administrador de pods, la subred de la VNet debe cumplir con los mismos requisitos de DNS que la subred de administración de la VNet del administrador de pods.

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.

Además del implementador de pods y sus flujos de trabajo, varias funciones de servicio requieren acceso a direcciones DNS específicas para que esas funciones funcionen de extremo a extremo. Esos nombres DNS también se proporcionan en las siguientes tablas.

Algunos de estos nombres DNS incluyen un elemento regional.

La activación de Supervisión de la infraestructura de Horizon en un pod crea automáticamente una instancia de Dispositivo virtual de Horizon Edge en la VNet y la subred de administración del administrador de pods. Dispositivo virtual de Horizon Edge tiene sus propios requisitos de nombre DNS. Por lo tanto, antes de activar Supervisión de la infraestructura de Horizon en un pod, asegúrese de cumplir los requisitos de DNS de Dispositivo virtual de Horizon Edge como se indica en las siguientes tablas.

Acerca de los puertos y protocolos después de implementar un pod para las operaciones relacionadas con el servicio en curso
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.

Nombres DNS del plano de control regional

El correo electrónico de bienvenida al servicio de Horizon indicará en qué instancia del plano de control regional se creó la cuenta de arrendatario. 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
UK cloud-uk.horizon.vmware.com
Europe-3 cloud-de.horizon.vmware.com

Para las direcciones DNS regionales que aparecen en las siguientes tablas de Dispositivo virtual de Horizon Edge, estas direcciones usan las mismas regiones que los nombres DNS del plano de control regional.

Requisitos de DNS para el proceso de implementación del pod predominante, la activación de varias funciones de servicio y las operaciones en curso

Para un uso correcto de extremo a extremo de las funciones del servicio, debe asegurarse de que los siguientes nombres DNS puedan resolverse y accederse desde las subredes de arrendatario y de administración con los protocolos y puertos específicos, como se indica en las siguientes tablas. Algunas de las funciones de servicio que requieren la capacidad para acceder a nombres DNS específicos son:

  • El implementador de pods que implementa automáticamente un pod de Horizon basado en el administrador de pods en la suscripción de Microsoft Azure
  • La función de actualización de pods, que actualiza el software del pod a una versión de software más reciente
  • El proceso de importación de imagen que utiliza el asistente Importar desde Marketplace
  • Las funciones relacionadas con el agente, como la actualización automatizada de agentes (AAU)
  • Universal Broker
  • Supervisión de la infraestructura de Horizon y sus Dispositivo virtual de Horizon Edge
  • Características relacionadas con Cloud Management Service (CMS)
Sobre todo para la implementación de pods, las actualizaciones de pods y al activar Supervisión de la infraestructura de Horizon en un pod
Debe asegurarse de que los siguientes nombres DNS puedan resolverse y accederse desde las subredes de arrendatario y de administración con los protocolos y puertos específicos, como se indica en las siguientes tablas. Los dispositivos utilizados en estos flujos de trabajo utilizan puertos salientes específicos para descargar de forma segura el software que estos procesos necesitan en el entorno de Microsoft Azure. Esos nombres DNS también se utilizan para que los dispositivos adecuados relacionados con el flujo de trabajo puedan comunicarse con el plano de control de la nube.

Para los nuevos implementaciones de pod, debe configurar el firewall de red, las reglas de grupo de seguridad de red (NSG) y los servidores de proxy de modo que los dispositivos relacionados con la implementación clave tengan la capacidad de ponerse en contacto con las direcciones DNS en los puertos que requieran. De lo contrario, se producirá un error en el proceso de implementación del pod.

Al activar Supervisión de la infraestructura de Horizon en un pod, se crearán instancias de Dispositivo virtual de Horizon Edge en la misma VNet y la misma subred de administración que los dispositivos del administrador de pods del pod. Debe asegurarse de que la configuración del firewall de red, las reglas de NSG y los servidores proxy permita a Dispositivo virtual de Horizon Edge comunicarse con las direcciones DNS en los puertos que requiera. De lo contrario, se producirá un error en la implementación de ese dispositivo.

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 siguiente tabla 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
Debe cargar un certificado que el implementador de pods configure 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.

Requisitos de DNS para la nueva implementación de pods, las actualizaciones de pods y las operaciones de servicio que se aplican en todo el arrendatario

En la siguiente tabla se describen los requisitos de DNS para una nueva implementación de pods, las actualizaciones de pods y las operaciones de servicio que se aplican en todo el arrendatario. Para la activación de Supervisión de la infraestructura de Horizon y los requisitos de DNS de Dispositivo virtual de Horizon Edge, consulte la siguiente sección. Dado que la función de Supervisión de la infraestructura de Horizon se activa por pod, sus requisitos de DNS merecen su propia tabla descriptiva.

Atención: A partir de principios de 2021, como resultado de una actualización a las instancias de plano de control regional del servicio, ya no se requiere el nombre DNS de d1mes20qfad06k.cloudfront.net para ninguna de las instancias de plano de control regional. Todas las instancias de plano de control regional ahora utilizan el nombre DNS de hydra-softwarelib-cdn.azureedge.net. El contenido de la siguiente tabla está conforme con esa realidad actual.
Tabla 2. Requisitos de DNS para la nueva implementación de pods, las actualizaciones de pods y las operaciones de servicio que se aplican en todo el arrendatario
Origen de subred Destino (nombre DNS) Puerto Protocolo Propósito
Administración Uno de los siguientes nombres, según la instancia de plano de control que esté especificada en su cuenta de arrendatario de Horizon Cloud. La instancia regional se establece cuando se crea la cuenta, tal y como se describe en Implementaciones e incorporación a Horizon Cloud para pods de Microsoft Azure y Horizon.
  • 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
  • cloud-uk.horizon.vmware.com
  • cloud-de.horizon.vmware.com
443 TCP Instancia de plano de control regional
  • 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
  • Reino Unido: cloud-uk.horizon.vmware.com
  • Alemania: cloud-de.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 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.
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 esm.ubuntu.com 80 TCP Servidor de paquete de software de Ubuntu. Utilizado por las máquinas virtuales basadas en Linux del pod para realizar un seguimiento de las actualizaciones de seguridad para CVE (vulnerabilidades y exposiciones comunes) altas y críticas en el sistema operativo base Ubuntu y la infraestructura de escalado horizontal.
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 nombres, según la instancia de plano de control que esté especificada en su cuenta de arrendatario de Horizon Cloud. La instancia regional se establece cuando se crea la cuenta, tal y como se describe en Implementaciones e incorporación a Horizon Cloud para pods de Microsoft Azure y Horizon.
  • connector-azure-us.vmwarehorizon.com
  • connector-azure-eu.vmwarehorizon.com
  • connector-azure-aus.vmwarehorizon.com
  • connector-azure-jp.vmwarehorizon.com
  • connector-azure-uk.vmwarehorizon.com
  • connector-azure-de.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
  • Reino Unido: connector-azure-uk.vmwarehorizon.com
  • Alemania: connector-azure-de.vmwarehorizon.com
Administración Según el plano de control regional que se aplica a la cuenta de Horizon Cloud:
  • Norteamérica: kinesis.us-east-1.amazonaws.com
  • Europa, Alemania: kinesis.eu-central-1.amazonaws.com
  • Australia: kinesis.ap-southeast-2.amazonaws.com
  • Japón: kinesis.ap-northeast-1.amazonaws.com
  • Reino Unido: kinesis.eu-west-2.amazonaws.com
443 TCP Cloud Monitoring Service (CMS)
Arrendatario hydra-softwarelib-cdn.azureedge.net 443 TCP Servidor de distribución de contenido de Horizon Cloud. En la subred del arrendatario, el proceso automatizado Importar imagen del sistema utiliza este sitio para descargar al instalador del software relacionado con el agente.

Requisitos de DNS del Dispositivo virtual de Horizon Edge

Al activar Supervisión de la infraestructura de Horizon en un pod, se crearán instancias de Dispositivo virtual de Horizon Edge basado en Linux en la suscripción de Microsoft Azure. Dispositivo virtual de Horizon Edge se implementa en la suscripción del pod con una NIC en la subred de administración del pod, la misma subred de administración que los dispositivos del administrador de pods del pod. En la siguiente tabla, los propósitos enumerados se encuentran en el contexto de este dispositivo virtual.

Nota: No hay nombres DNS con uk en esta tabla, a diferencia de la tabla anterior. Como se indica en las notas de la versión, esta función de Supervisión de la infraestructura de Horizon está actualmente bajo disponibilidad limitada.
Tabla 3. Requisitos de DNS de supervisión de la infraestructura de Horizon
Origen de subred Destino (nombre DNS) Puerto/protocolo Propósito
Administración
  • azure.archive.ubuntu.com
  • archive.ubuntu.com
  • changelogs.ubuntu.com
  • security.ubuntu.com
80 y 443/TCP Servidor de paquete de software de Ubuntu. Utilizado por el dispositivo basado en Linux para las actualizaciones del sistema operativo Ubuntu.
Administración esm.ubuntu.com 80/TCP Servidor de paquete de software de Ubuntu. Utilizado por el dispositivo basado en Linux para realizar un seguimiento de las actualizaciones de seguridad para CVE (vulnerabilidades y exposiciones comunes) altas y críticas en el sistema operativo base Ubuntu y la infraestructura de escalado horizontal.
Administración
  • *.blob.core.windows.net
  • horizonedgeprod.azurecr.io
443 / TCP Se utiliza para el acceso programático a Azure Blob Storage.

Se utiliza para descargar las imágenes de Docker de las direcciones DNS que requiere el módulo del dispositivo.

Administración

*.azure-devices.net, o uno de los siguientes nombres específicos de la región, según el plano de control regional que se aplica a la cuenta de arrendatario:

América del Norte:

  • edgehubprodna.azure-devices.net

Europa:

  • edgehubprodeu.azure-devices.net

Australia:

  • edgehubprodap.azure-devices.net

Japón:

  • edgehubprodjp.azure-devices.net
443 / TCP Se utiliza para conectar el dispositivo al plano de control de Horizon Cloud, para descargar configuraciones para el módulo del dispositivo y para actualizar el estado de tiempo de ejecución del módulo del dispositivo.
Administración
  • *.docker.com
  • *.docker.io
  • docker.io
  • cloud.google.com
  • gcr.io
  • dl.k8s.io
  • k8s.gcr.io
  • storage.googleapis.com
  • cloud.weave.works
  • packages.cloud.google.com
  • apt.kubernetes.io
443 / TCP Se utiliza para descargar los archivos binarios de Docker y de Kubernetes que el dispositivo necesita.
Administración Según el plano de control regional que se aplica a la cuenta de arrendatario:

América del Norte:

  • kinesis.us-east-1.amazonaws.com
  • sauron.horizon.vmware.com

Europa:

  • kinesis.eu-central-1.amazonaws.com
  • sauron-eu.horizon.vmware.com

Australia:

  • kinesis.ap-southeast-2.amazonaws.com
  • sauron-ap.horizon.vmware.com

Japón:

  • kinesis.ap-northeast-1.amazonaws.com
  • sauron-jp.horizon.vmware.com
443 / TCP Se utiliza para enviar los datos de supervisión del pod recopilados por el dispositivo al plano de control de Horizon Cloud.

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, 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.

Dado 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, 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.

Dado 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.