Si las redes de su entorno no están configuradas correctamente para su uso con el pod de Horizon Cloudfirst-gen en Microsoft Azure, el proceso para crear el pod puede quedar atascado en el estado PENDIENTE o puede fallar la acción posterior a la implementación de enlace de dominio para el entorno de Active Directory. Las dos causas más comunes de errores relacionados con la red son no abrir los puertos salientes necesarios y no poder habilitar el DNS para resolver las direcciones internas y externas. Siguiendo los pasos de solución de problemas descritos aquí, puede ejecutar algunas pruebas para comprobar que los puertos salientes necesarios estén abiertos y el DNS pueda resolver las direcciones internas y externas.

Importante: Esta información se aplica únicamente cuando tenga acceso a un entorno de arrendatario de first-gen en el plano de control de first-gen. Como se describe en el artículo 92424 de la base de conocimientos, el plano de control de first-gen ha llegado a la fecha de fin de disponibilidad (EOA). Consulte el artículo para obtener información.

Los requisitos de redes generales para implementar correctamente un pod se establecen en la lista de comprobación de requisitos previos y se describen en Arrendatarios de first-gen: configurar las opciones del servidor DNS que necesita la topología de VNet que se utilizará para los pods de Horizon Cloud en Microsoft Azure y Arrendatarios de first-gen - Implementaciones de Horizon Cloud on Microsoft Azure: requisitos de resolución de nombres de host, nombres DNS. Si las redes de su entorno no cumplen estos requisitos, se enfrentará a uno o ambos de estos dos problemas:

Problemas Causas comunes
  • La página Introducción muestra el pod en estado pendiente y nunca pasa al estado de conexión. Por lo general, un pod está en estado pendiente durante aproximadamente 10 minutos (excepto cuando se implementa un pod en la nube de Microsoft Azure China, que tarda más).
  • Incluso cuando el pod se haya implementado correctamente, cuando se intenta registrar Active Directory, el paso del enlace de dominio falla y presenta el error Unable to register Active Directory
  • Los puertos salientes necesarios no están abiertos o están bloqueados por su entorno de firewall. Si los puertos salientes necesarios no están abiertos o están bloqueados por un firewall, se impide que el software del pod se descargue de forma segura en el entorno de nube de Microsoft Azure y vuelva a conectarse con el plano de control de la nube de Horizon Cloud. Como resultado, se produce el problema de estado pendiente.
  • El servidor DNS de la VNet no está configurado correctamente para que apunte a un servidor DNS válido que pueda resolver nombres de máquina tanto internos como externos.
  • Aunque el servidor DNS de la VNet apunte correctamente a un servidor DNS, ese servidor DNS no puede resolver los nombres de máquina internos ni externos.

Si no se proporciona a la VNet ninguna resolución de DNS para los nombres de máquina externos, se puede producir el problema de estado pendiente y el problema de enlace de dominio. Por ejemplo, si el DNS no se puede resolver en Active Directory en los controladores de dominio, se produce un error en el paso del enlace de dominio. Para obtener más información sobre la configuración de DNS de la VNet, consulte Arrendatarios de first-gen: configurar las opciones del servidor DNS que necesita la topología de VNet que se utilizará para los pods de Horizon Cloud en Microsoft Azure.

Para ejecutar algunas pruebas que comprobarán que la configuración de DNS puede resolver nombres internos y externos, y comprobar que los puertos salientes necesarios estén abiertos, debe implementar una máquina virtual (VM) de prueba pequeña en la suscripción de Microsoft Azure y, a continuación, usar esa máquina virtual para ejecutar estas pruebas de redes. La secuencia de alto nivel de pasos para solucionar problemas es la siguiente:

  1. Cree un par de claves de SSH.
  2. Cree la máquina virtual de prueba en la suscripción a Microsoft Azure.
  3. Conéctese a esa máquina virtual de prueba.
  4. Ejecute las pruebas de redes.
  5. Al realizar la prueba, elimine la máquina virtual de prueba y todos los artefactos relacionados con la prueba que se crearon en su entorno de Microsoft Azure para realizar esta solución de problemas.
Nota: Si no elimina los artefactos relacionados con la prueba y utiliza posteriormente la acción Eliminar de la consola para eliminar el pod, pueden producirse resultados inesperados. Al eliminar un pod, el sistema comprueba las subredes del pod para comprobar que todos los elementos conectados a las subredes pertenecen al pod, de acuerdo con el ID del pod. Si el sistema determina que máquinas virtuales adicionales, discos de máquina virtual, direcciones IP u otros artefactos están conectados a las subredes del pod, el sistema no puede eliminar el pod correctamente.

Para obtener más información sobre la ejecución de las pruebas de solución de problemas, consulte las secciones siguientes.

Importante: Aunque todas estas pruebas manuales se realicen correctamente, si dirige todo el tráfico a través de la red local y solo permite el paso del tráfico autenticado, pero no proporcionó los valores para usar un proxy en el asistente de implementación de pods, la implementación de pods puede bloquearse en estado pendiente. Si esta descripción coincide con su situación, debe eliminar el pod de la página de introducción, volver a ejecutar el asistente de implementación de pods y especificar la información requerida del proxy.

Solución de problemas de implementación de pods de Horizon Cloud: crear un par de claves SSH

Como parte de esta solución de problemas, se implementa una máquina virtual Linux de prueba en la suscripción de Microsoft Azure. Para autenticarse en la máquina virtual Linux de prueba, necesita un par de claves SSH. Cree el par de claves en el sistema que se utiliza para la conexión SSH con la máquina virtual de prueba. Este paso es opcional si ya tiene un par de claves en ese sistema.

Para crear este par de claves SSH, puede utilizar un sistema Microsoft Windows o Linux. Los pasos para ambos tipos de sistemas se describen a continuación. Seleccione los pasos más adecuados para su situación.

Crear un par de claves SSH en un sistema Microsoft Windows

Siga estos pasos cuando vaya a utilizar un sistema Microsoft Windows para conexión SSH con la máquina virtual Linux de prueba que se va a implementar en su suscripción a Microsoft Azure.

Cuando se crea la máquina virtual de prueba en Microsoft Azure, utilizará el contenido del archivo de la clave pública generada. Si ya tiene un par de claves SSH existente en el sistema Microsoft Windows que se va a utilizar para conectarse con la máquina virtual de prueba, puede omitir este paso y continuar con la creación de la máquina virtual de prueba, como se describe en Crear la máquina virtual de prueba en la suscripción a Microsoft Azure.

Siguiendo estos pasos, se genera el par de claves SSH, se copia el contenido del archivo de clave pública de manera que pueda utilizarlo al crear la máquina virtual de prueba y se carga la clave privada en la herramienta Pageant de PuTTY. Pageant es un agente de autenticación SSH que puede contener las claves privadas en la memoria. Manteniendo la clave privada en la memoria, la clave privada se aplica automáticamente contra cualquier sesión SSH de ese sistema Microsoft Windows, lo que facilita aún más su uso.

Requisitos previos

Un sistema Microsoft Windows no tiene instalado de forma predeterminada el software de par de claves SSH. Compruebe que el software de generación de par de claves SSH esté instalado en el sistema que va a utilizar. Puede utilizar cualquier software de generación de par de claves SSH. Los siguientes pasos describen cómo usar el software PuTTY en Microsoft Windows para crear el par de claves SSH. Puede obtener el software PuTTY en www.putty.org. Tras la instalación, el conjunto de herramientas PuTTY está disponible. La siguiente captura de pantalla muestra un ejemplo de las herramientas PuTTY en el menú Inicio.


Captura de pantalla de las herramientas PuTTY, tal y como aparecen en el menú Inicio de Microsoft Windows 10.

Procedimiento

  1. En el sistema Microsoft Windows, inicie PuTTYgen (el generador de claves de PuTTY).
    Se muestra la ventana del generador de claves de PuTTY. Como se resaltó en la siguiente captura de pantalla, el objetivo es generar un par de claves pública y privada, del tipo SSH-2 RSA y tener 2048 bits.
    Captura de pantalla de la ventana del generador de claves de PuTTY, con flechas verdes que señalan a los puntos clave.

  2. Compruebe que SSH 2RSA esté seleccionado, 2048 esté establecido como la cantidad de bits y, a continuación, haga clic en Generar. La ventana cambia a la ventana Clave que muestra una barra de progreso.
  3. Siga las instrucciones en pantalla para mover el cursor de forma aleatoria en el área en blanco situada debajo de la barra de progreso. Como se indica en la interfaz de usuario de PuTTY, al mover el cursor por el área, se agrega la aleatoriedad necesaria al proceso.
  4. Guarde la clave privada en el sistema. Para ello introduzca una frase de contraseña de clave y haga clic en Guardar la clave privada.
    Nota: Utilizar una frase de contraseña de clave es una práctica recomendada opcional. Sin embargo, si hace clic en Guardar la clave privada sin tener que introducir una frase de contraseña de clave, una ventana emergente le pide que confirme si desea guardar la clave privada sin una frase de contraseña de clave.
    La clave privada se descarga como un archivo PPK. Después de hacer clic en Guardar la clave privada, puede desplazarse a un directorio en el sistema local, escribir un nombre de archivo y guardar el archivo.
  5. Utilice el botón Guardar la clave pública para guardar la clave pública en una ubicación desde donde pueda copiarla al crear la máquina virtual de prueba.
  6. Inicie Pageant, el agente de autenticación SSH de PuTTY.
    Si el sistema es Windows 10, el icono de Pageant se cargará en la bandeja del sistema.
  7. Agregue la clave privada a Pageant haciendo clic derecho en ese icono de bandeja del sistema, haciendo clic en Agregar clave y utilizando la ventana de selección de archivo para ir a archivo de clave privada (PPK) guardado y seleccionarlo.
    Nota: Si especificó una frase de contraseña de clave cuando se guardó el archivo de clave privada anteriormente, se muestra un cuadro para que escribir esa frase de contraseña.

Resultados

En este punto, la clave privada se carga en Pageant. Puede utilizar la opción de Ver claves en el menú Acción para ver la clave en la lista de claves cargadas. Cuando inicie una sesión SSH con PuTTY, PuTTY recuperará la clave automáticamente desde Pageant y la utilizará para autenticar sin tener que escribir la frase de contraseña. Posteriormente, cuando haya terminado de ejecutar las sesiones de SSH y desee apagar Pageant, utilice la opción Salir desde el menú secundario del icono de la bandeja del sistema de Pageant.

Qué hacer a continuación

Cree la máquina virtual de prueba siguiendo los pasos que aparecen en Crear la máquina virtual de prueba en la suscripción a Microsoft Azure.

Crear un par de claves SSH en un sistema Linux

Siga estos pasos cuando utilice un sistema Linux para conectarse mediante SSH a la máquina virtual Linux de prueba que se implementará en la suscripción de Microsoft Azure.

En los pasos para crear la máquina virtual de prueba en Microsoft Azure, se utilizará el contenido del archivo de claves públicas generado. Si ya hay un par de claves SSH en el sistema Linux que se utilizará para conectarse a la máquina virtual de prueba, puede omitir este paso y continuar con la creación de la máquina virtual de prueba, tal como se describe en Crear la máquina virtual de prueba en la suscripción a Microsoft Azure.

Requisitos previos

Antes de realizar estos pasos, asegúrese de que no se sobrescribirá ningún par de claves SSH existente que desee conservar para otros fines. En un sistema Linux, los archivos de claves SSH públicas y privadas se crean en el directorio de Linux ~/.ssh/id_rsa de forma predeterminada. Si ya existe un par de claves SSH en el directorio, y se usa el mismo nombre de archivo al ejecutar este comando, o si se especifica una ubicación diferente en el comando y ya existe un par de claves SSH en esa ubicación, el par existente se sobrescribirá.

Procedimiento

  1. En el sistema Linux, abra un shell de bash.
  2. En el shell de bash, escriba el siguiente comando: 
    ssh-keygen -t rsa -b 2048
  3. Siga las instrucciones que aparecen en pantalla para introducir el archivo en el que se guardará la clave, escribir una frase de contraseña y confirmar la frase de contraseña.
    A continuación, se muestra un ejemplo de las instrucciones en pantalla, donde mykey se ha introducido como el archivo en el que se guardará la clave. 
    -bash-4.1$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/mts-cm/home/user1/.ssh/id_rsa): mykey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
    Nota: El uso de una frase de contraseña de clave es una práctica recomendada opcional.
    La clave privada se guardará en el archivo que se especifique, mientras que la clave pública se guardará en un archivo con el mismo nombre y la extensión .pub. Retomando el ejemplo anterior donde se introdujo mykey como archivo, la salida sería: 
    Your identification has been saved in mykey.
Your public key has been saved in mykey.pub.

Qué hacer a continuación

Cree la máquina virtual de prueba siguiendo los pasos que aparecen en Crear la máquina virtual de prueba en la suscripción a Microsoft Azure.

Crear la máquina virtual de prueba en la suscripción a Microsoft Azure

Para ejecutar las pruebas de comprobación de que la conectividad de red esté configurada para el pod de Horizon Cloud utilizará una máquina virtual (VM) de prueba de Linux en el entorno de Microsoft Azure.

Requisitos previos

Compruebe que tenga la clave pública de SSH creada como se describe en Solución de problemas de implementación de pods de Horizon Cloud: crear un par de claves SSH. Esa clave pública se proporcionará en el Asistente de creación de la máquina virtual para que esta última confíe en las conexiones de SSH procedentes del sistema que tenga la clave privada correspondiente.

Compruebe que el nombre de la red virtual (VNet) sea el mismo que se utiliza para implementar el pod, tal como se describe en Horizon Cloud first-gen: configurar la red virtual obligatoria en Microsoft Azure.

Si no utilizó la opción del asistente Agregar pod para usar sus propias subredes con nombre en el pod y, en su lugar, introdujo los CIDR para las subredes, el implementador de pods creará la subred de administración del pod. Es posible que, en el punto del proceso de implementación donde se produjo el error, el propio proceso cree la subred de administración del pod en la VNet.

  • Si el implementador ya creó esa subred de administración, se recomienda implementar en ella la máquina virtual de prueba. Para identificar la existencia de la subred de administración del pod en la VNet, inicie sesión en el portal de Microsoft Azure, desplácese a esa VNet y examine la lista de subredes que tiene. Si el implementador de pods crea automáticamente las subredes del pod (porque no se aplicó la opción para usar subredes con nombre propias en el pod), la subred de administración del pod tendrá un nombre con el patrón vmw-hcs-podID-net-management, donde "podID" es el UUID del pod. En caso contrario, la subred de administración del pod será la que creó para la implementación del pod.
  • Si el proceso de implementación no creó la subred de administración del pod en la VNet, puede elegir cualquier subred disponible en la VNet o crear una nueva para que la use la máquina virtual de prueba.

Procedimiento

  1. Inicie sesión en el portal de Microsoft Azure.
  2. En el portal, cree una máquina virtual de procesos desde Azure Martketplace y defina para ella el tipo de modelo Ubuntu Server LTS.
    Cuando se redactó este documento, podía elegirse Ubuntu Server 20.04 LTS en Azure Marketplace.
  3. Para crear esta máquina virtual Linux de prueba, siga la interfaz de usuario del asistente y configure las opciones requeridas. Asegúrese de configurar los siguientes elementos tal y como se indica a continuación.
    Opción Descripción
    Suscripción Indique la opción que seleccionó para el pod en el asistente Agregar pod.
    Grupo de recursos La opción recomendada es crear un nuevo grupo de recursos para la máquina virtual de prueba. Siga los mensajes en pantalla para crear un nuevo grupo de recursos.

    Aunque pueda usar un grupo de recursos existente con esta máquina virtual de prueba, se recomienda un grupo de recursos específico, ya que resulta más fácil eliminar la máquina virtual y los artefactos relacionados simplemente eliminando el grupo de recursos completo cuando haya finalizado la ejecución de las pruebas.

    Región Indique la opción que seleccionó para el pod en el asistente Agregar pod.
    Tamaño Debido a que se espera que sea una máquina virtual temporal, utilizada solo para completar las pruebas de comprobación, puede elegir cualquier tamaño. No obstante, los tamaños más reducidos suelen tener menores costes asociados en Microsoft Azure y, por lo general, suelen elegirse tamaños pequeños para las máquinas virtuales de prueba (como el modelo de 2 vCPU).
    Nombre de usuario Tome nota de este nombre debido a que deberá utilizarlo más adelante.
    Tipo de autenticación Seleccione Clave pública SSH.
    Origen de clave pública de SSH Seleccione Usar clave pública existente. Al seleccionar esa opción, aparecerá el campo Clave pública SSH y podrá pegar la suya.
    Clave pública SSH En este campo, pegue la clave pública SSH que creó al generar el par de claves SSH. El contenido pegado debe comenzar con la línea ---- BEGIN SSH2 PUBLIC KEY ---- y terminar con la línea ---- END SSH2 PUBLIC KEY ---- de la clave pública.
    Puertos de entrada públicos Permita el puerto SSH (22) seleccionado para poder realizar las pruebas con esta máquina virtual de prueba.
    Red virtual Seleccione la misma VNet que se utilizó para la implementación del pod con errores.
    Subred Si ya ha intentado implementar el pod y el proceso falló, es posible que la subred de administración del pod se haya creado en la red virtual. Si la subred está allí, se recomienda seleccionar esa subred para la máquina virtual de prueba. Haga clic en la opción Subred para desplazarse a las subredes que existen en la red virtual seleccionada. Es posible que deba pasar el cursor sobre la subred para ver su nombre completo en la información sobre herramientas.

    Si el proceso de implementación del pod no creó la subred de administración del pod en la VNet, seleccione la subred de la VNet que identificó para usar para la máquina virtual de prueba (como se describe en los requisitos previos anteriores).

    Nota: Si el pod se implementó correctamente, pero está solucionando problemas de unión a dominio, puede seleccionar la subred de escritorio del pod para la máquina virtual de prueba en lugar de la subred de administración, debido a que las operaciones de unión a dominio se usan con las imágenes de escritorio que se conectan a esa subred de escritorio.
    IP pública Seleccione esta opción para que la máquina virtual de prueba que creó tenga una dirección IP pública asignada. Tener una dirección IP pública le permite conectarse a ella a través de la red de área extensa (WAN).
    Nota: Es posible que no sea técnicamente viable usar una dirección IP pública en la configuración de red. Si no se puede crear la máquina virtual de prueba con una IP pública, deberá tener conectividad de red desde el sistema local hacia la subred seleccionada en el campo Subred o será necesario conectarse a alguna otra máquina en la red y, a continuación, realizar una conexión de entrada a la máquina virtual de prueba.
  4. En el último paso del asistente, compruebe que la información clave (suscripción, ubicación regional, red virtual y subred) coincide con la indicada en el pod y haga clic en Enviar para crear la máquina virtual.

Utilizar SSH para conectarse a la máquina virtual de prueba

Establezca una conexión SSH (shell seguro) con la máquina virtual de prueba para poder ejecutar las pruebas de conectividad de red en el entorno de Microsoft Azure.

Conexión SSH con la máquina virtual de prueba desde un sistema Microsoft Windows

Esta conexión se establece desde el sistema Microsoft Windows que tiene la clave privada que corresponde a la clave pública que se especificó cuando se creó la máquina virtual de prueba.

Requisitos previos

Compruebe que tenga la dirección IP de la máquina virtual de prueba y el nombre de usuario que especificó cuando se creó la máquina virtual.

En un sistema Microsoft Windows, por lo general, se utiliza PuTTY. Para permitir que PuTTY cargue con facilidad la clave privada al iniciar la sesión de SSH, antes de iniciar PuTTY, inicie Pageant como se describe en Crear un par de claves SSH en un sistema Microsoft Windows y agregue la clave privada de SSH a la lista de claves de Pageant. La clave privada de SSH debe coincidir con la clave pública que se especificó al crear la máquina virtual de prueba. Cuando se cargue la clave privada en Pageant, la sesión de SSH de PuTTY utilizará automáticamente esa clave privada.

Procedimiento

  1. Inicie PuTTY (Opción de PuTTY en el menú Inicio de Microsoft Windows 10).
    Se abre la ventana de configuración de PuTTY.
  2. En la ventana de configuración de PuTTY, especifique el nombre de host, seleccione SSH y, a continuación, haga clic en Abrir.
    En el campo Nombre de host de la ventana de configuración de PuTTY, escriba una cadena con el patrón 
    testvm_username@testvmip
    sustituyendo el nombre de usuario y la dirección IP de la máquina virtual de prueba de testvm_username y testvmip en la cadena.
    Importante: Después de hacer clic en Abrir, si es la primera vez que se conecta a la máquina virtual de prueba, aparecerá un mensaje de seguridad de PuTTY indicando que la clave de host del servidor no está almacenada en caché y mostrando la huella digital de la clave rsa2 del servidor. Para seguir realizando la conexión, puede hacer clic en Sí, para agregar la clave de host del servidor en la memoria caché de PuTTY, o en No, para conectarse sin agregar la clave a la memoria caché de PuTTY. Si sospecha que no se está estableciendo la conexión con su máquina virtual de prueba, haga clic en Cancelar para abandonar la conexión y vuelva a la ventana de configuración de PuTTY para comprobar la entrada del nombre de host.
    La siguiente captura de pantalla es una ilustración de la ventana con este ejemplo: 
    [email protected]

    Captura de pantalla que muestra la ventana de configuración de PuTTY con los valores introducidos y flechas verdes que apuntan hacia el campo Nombre de host, al botón SSH y al botón Abrir.

Resultados

Cuando se establece la conexión SSH, se muestra una ventana de línea de comandos.

Qué hacer a continuación

Ahora que está conectado a la máquina virtual de prueba, puede ejecutar las pruebas para comprobar la conectividad de red dentro de su entorno de Microsoft Azure. Siga los pasos que se describen en Ejecutar las pruebas para comprobar las redes en su entorno de Microsoft Azure.

Conexión de SSH con la máquina virtual de prueba desde un sistema Linux

Esta conexión se establece desde el sistema Linux que tiene la clave privada que se corresponde con la clave pública especificada cuando se creó la máquina virtual de prueba.

Requisitos previos

Compruebe que tiene la dirección IP de la máquina virtual de prueba y el nombre de usuario que especificó cuando se creó la máquina virtual.

Procedimiento

  1. Abra un shell de bash.
  2. En la línea de comandos $ del shell de bash, introduzca el comando ssh tal como se muestra a continuación, sustituyendo la dirección IP y el nombre de usuario de la máquina virtual de prueba por testvmip y testvm_username en el comando: 
    ssh testvm_username@testvmip
    Por ejemplo, con la información de la máquina virtual de prueba de los ejemplos de Crear la máquina virtual de prueba en la suscripción a Microsoft Azure, este sería el aspecto del comando de ejemplo: 
    ssh [email protected]

Resultados

Cuando se establece la conexión SSH, aparece una ventana de la línea de comandos con un aspecto parecido a la siguiente captura de pantalla.
Sesión de SSH conectada de muestra

Qué hacer a continuación

Ahora que se ha establecido la conexión con la máquina virtual de prueba, puede ejecutar las pruebas para comprobar la conectividad de red en el entorno de Microsoft Azure. Siga los pasos que se describen en Ejecutar las pruebas para comprobar las redes en su entorno de Microsoft Azure.

Ejecutar las pruebas para comprobar las redes en su entorno de Microsoft Azure

Puede ejecutar estas pruebas para comprobar que estas dos áreas relacionadas con la red estén configuradas correctamente: que el DNS pueda resolver las direcciones internas y externas, y que los puertos salientes necesarios estén abiertos. Estas pruebas se ejecutan con la máquina virtual de prueba.

El pod se basa en DNS para resolver las direcciones internas y externas. Las dos primeras pruebas aquí comprueban si el DNS configurado en el entorno de red puede resolver los FQDN conocidos para las direcciones internas y externas.

Importante: Aunque todas estas pruebas manuales se realicen correctamente, si dirige todo el tráfico a través de la red local y solo permite el paso del tráfico autenticado, pero no proporcionó los valores para usar un proxy en el asistente de implementación de pods, la implementación de pods puede bloquearse en estado pendiente. Si esta descripción coincide con su situación, debe eliminar el pod de la página de introducción, volver a ejecutar el asistente de implementación de pods y especificar la información requerida del proxy.

Requisitos previos

Antes de ejecutar estas pruebas, compruebe que haya creado una máquina virtual de prueba en la suscripción a Microsoft Azure y que esta tenga una conexión SSH, como se describe en Crear la máquina virtual de prueba en la suscripción a Microsoft Azure y Utilizar SSH para conectarse a la máquina virtual de prueba.

Obtenga las direcciones IP y los nombres de dominio completos (FQDN) para los servidores que son internos de la red que se espera que sean accesibles desde la VNet, como el controlador de dominio de Active Directory. Esta información se utilizará en la prueba de verificación de DNS.

Procedimiento

  1. Compruebe que el DNS esté funcionando en su entorno para resolver los FQDN internos utilizando el comando dlg para consultar un nombre de dominio conocido que sea interno de la VNet en Microsoft Azure.
    En la ventana de la conexión SSH, emita el comando dig para consultar el nombre de dominio de un servidor que sabe que sea interno de la red, como el controlador de dominio de Active Directory. 
    dig internal-domain-name
    Donde internal-domain-name es el nombre de dominio totalmente cualificado de un servidor que sabe es interno de la red.

    dig (Domain Information Groper) es una herramienta de línea de comandos para solucionar problemas de red. Al ejecutar este comando con un nombre de host interno, el resultado verifica que la configuración del DNS pueda resolver las direcciones internas correctamente. Si la configuración del DNS puede resolver el internal-domain-name que se utiliza en el comando, la salida del comando devolverá la dirección IP correcta asociada con ese nombre de dominio.

    Por ejemplo, supongamos que la VNet está configurada con un servidor interno de Active Directory cuyo controlador de dominio de Active Directory tiene una entrada DNS de skylo.local y una dirección IP de 192.168.0.15. Al ejecutar dig skylo.local se debería comprobar si la configuración de DNS de la VNet puede resolver ese nombre de servidor interno skylo.local: 
    testvmadmin@HCS-testingVM:~$ dig skylo.local

; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;skylo.local.                   IN      A

;; ANSWER SECTION:
skylo.local.            600     IN      A       192.168.0.15

;; Query time: 1 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 20:58:01 UTC 2018
;; MSG SIZE  rcvd: 56

testvmadmin@HCS-testingVM:~$
    La prueba es correcta cuando ANSWER SECTION indica que el nombre de host proporcionado se resolvió a la dirección IP que se espera para ese nombre de host.
    Nota: En ocasiones, el DNS no es totalmente fiable y algunas solicitudes resuelven correctamente mientras que otras no. Si la emisión del comando produce un error la primera vez, ejecútelo de diez a veinte iteraciones y vea si obtiene respuestas confiables cada vez.
  2. Compruebe que el DNS esté funcionando en su entorno para resolver nombres de dominio completos externos utilizando el comando dlg para consultar un nombre de dominio externo conocido.
    En la ventana de la conexión SSH, emita el comando dig para consultar un nombre de dominio externo estándar del sector, como vmware.com o microsoft.com. 
    dig external-domain-name
    Donde external-domain-name es un nombre de dominio totalmente cualificado que está fuera de la VNet. Por ejemplo, al ejecutar dig vmware.com se comprueba si la configuración de DNS de la VNet pudo resolver ese nombre externo: 
    testvmadmin@HCS-testingVM:~$ dig vmware.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;vmware.com.                    IN      A

;; ANSWER SECTION:
vmware.com.             150     IN      A       107.154.105.19
vmware.com.             150     IN      A       107.154.106.19

;; Query time: 28 msec
;; SERVER: 192.168.0.15#53(192.168.0.15)
;; WHEN: Mon Mar 26 21:14:29 UTC 2018
;; MSG SIZE  rcvd: 71

testvmadmin@HCS-testingVM:~
    En el ejemplo anterior, ANSWER SECTION indica que el nombre de dominio externo vmware.com se resolvió correctamente a dos direcciones IP.
    Nota: Puede repetir esta prueba usando diversos nombres de dominio externo, como azure.com o microsoft.com, para comprobar que el DNS pueda resolver diferentes nombres externos.
    Si las pruebas de DNS no funcionan, compruebe las configuraciones de red y su servidor DNS. Compruebe que haya agregado su servidor DNS a la VNet.
    Importante: Si detecta que necesita agregar el servidor DNS a la VNet o tiene que cambiar la configuración del servidor DNS de la VNet, debe reiniciar todas las máquinas virtuales que estén conectadas a esa VNet para que estas incorporen el cambio. Si cambia la configuración del servidor DNS de la VNet y no reinicia todas las máquinas virtuales conectadas a esa VNet, los cambios no se propagarán correctamente en la VNet.
  3. Compruebe que los puertos de salida obligatorios estén disponibles mediante el comando netcat.
    Horizon Cloud requiere que algunos puertos salientes estén abiertos, para que el software del pod pueda descargarse de forma segura en su entorno de Microsoft Azure y para que el pod se pueda conectar con el plano de control de Horizon Cloud. Como se describe en Arrendatarios de first-gen - Implementaciones de Horizon Cloud on Microsoft Azure: requisitos de resolución de nombres de host, nombres DNS, los siguientes puertos TCP salientes deben estar abiertos en la subred de administración del pod: el puerto 80, 443 y 11371. Si ejecuta netcat, como se indica en el siguiente comando, puede verificar que esos puertos salientes estén abiertos.
    En la ventana de la conexión SSH, ejecute los siguientes comandos (uno por puerto).
    Nota: El siguiente comando para probar el puerto 11371 especifica packages.microsoft.com para probar la conexión, mientras que las otras dos líneas prueban la conexión saliente con el plano de control de Horizon Cloud. 
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
    Cuando un puerto está abierto correctamente, el comando netcat devuelve la línea succeeded! para su prueba.
    Si los comandos netcat devuelven errores, compruebe las conexiones de red de Microsoft Azure, los grupos de seguridad de red en su suscripción y cualquier servidor de seguridad que pueda tener instalado. Asegúrese de que la configuración de red cumpla los requisitos de DNS, puertos y protocolo que el pod necesita para la implementación, como se describe en Arrendatarios de first-gen - Implementaciones de Horizon Cloud on Microsoft Azure: requisitos de resolución de nombres de host, nombres DNS.

Resultados

Si las pruebas anteriores se realizan correctamente, podrá implementar correctamente el pod.

Nota: Si va a configurar funciones opcionales para su uso con el pod, como la autenticación en dos fases o True SSO con un servidor de autenticación, es posible que se necesiten puertos adicionales para estos fines. Puede utilizar las técnicas de prueba de puertos de salida anteriores para comprobar que estos puertos están abiertos correctamente.

Qué hacer a continuación

Cuando haya completado la prueba, debe eliminar la máquina virtual de prueba y todos los artefactos relacionados, como su disco de máquina virtual, dirección IP, NIC, desde el entorno de Microsoft Azure. Lo ideal es que debería haber creado un grupo de recursos para la máquina virtual de prueba y simplemente elimine ese grupo de recursos para eliminar todos los artefactos de la máquina virtual. Siga los pasos descritos en Eliminar la máquina virtual de prueba después de completar las pruebas.

Importante: Si no elimina todos los artefactos de la máquina virtual de prueba del entorno de Microsoft Azure y conectó previamente dicha máquina a una de las subredes del pod, es posible que, si intenta eliminar este pod más adelante mediante la acción Eliminar correspondiente, el sistema no pueda quitarlo completamente del entorno de Horizon Cloud debido a esos artefactos conectados. De forma predeterminada, cuando se utiliza la acción Eliminar para eliminar un pod, Horizon Cloud elimina los grupos de recursos y las subredes que ha creado para el pod. Microsoft Azure impedirá la eliminación de subredes que aún están en uso. Si los artefactos de la máquina virtual de prueba están conectados a las subredes del pod, no se pueden eliminar esas subredes, y la eliminación del pod quedará incompleta. Para evitar esta situación, asegúrese de que se eliminen todos los artefactos de la máquina virtual de prueba después de que el pod se implemente correctamente.

Eliminar la máquina virtual de prueba después de completar las pruebas

Cuando haya terminado las pruebas para comprobar la configuración de red de Microsoft Azure y ya no necesite la máquina virtual de prueba, debe eliminarla del entorno de Microsoft Azure, como también, debe eliminar todos los artefactos relacionados.

Importante: Si no elimina todos los artefactos de la máquina virtual de prueba del entorno de Microsoft Azure y conectó previamente dicha máquina a una de las subredes del pod, es posible que, si intenta eliminar este pod más adelante mediante la acción Eliminar correspondiente, el sistema no pueda quitarlo completamente del entorno de Horizon Cloud debido a esos artefactos conectados. De forma predeterminada, cuando se utiliza la acción Eliminar para eliminar un pod, Horizon Cloud elimina los grupos de recursos y las subredes que ha creado para el pod. Microsoft Azure impedirá la eliminación de subredes que aún están en uso. Si los artefactos de la máquina virtual de prueba están conectados a las subredes del pod, no se pueden eliminar esas subredes, y la eliminación del pod quedará incompleta. Para evitar esta situación, asegúrese de que se eliminen todos los artefactos de la máquina virtual de prueba después de que el pod se implemente correctamente.

Procedimiento

  1. Inicie sesión en el portal de Microsoft Azure.
  2. Utilice uno de los siguientes métodos para eliminar la máquina virtual de prueba, en función de cómo se haya implementado.
    • Si implementó la máquina virtual de prueba en su propio grupo de recursos y dicho grupo no se usa con ningún otro fin, puede eliminar el grupo de recursos completo.
      Precaución: Para evitar eliminar accidentalmente otros elementos, asegúrese de que el grupo de recursos contenga solo la máquina virtual de prueba y sus objetos asociados, como los adaptadores de red y el disco, antes de eliminar el grupo de recursos.
    • Si necesita eliminar la máquina virtual de prueba sin eliminar un grupo de recursos completo, puede utilizar el cuadro de búsqueda del portal para buscar el nombre de la máquina virtual de prueba. Los resultados de esta búsqueda mostrarán la máquina virtual y todos sus objetos asociados (disco, interfaces de red, dirección IP pública, etc.). A continuación, elimine cada objeto de forma individual.