Executar estes testes para verificar se estas duas áreas relacionadas à rede estão configuradas corretamente: se o DNS pode resolver os endereços interno e externo e se as portas de saída necessárias estão abertas. Execute esses testes usando sua VM de teste.

O pod depende de o DNS resolver os endereços interno e externo. Os dois primeiros teste aqui verificam se o DNS configurado no seu ambiente de rede pode resolver os FQDNs conhecidos para os endereços interno e externo.

Importante: Se você estiver direcionando todo o tráfego para fora por meio de sua rede local e permitir apenas a passagem do tráfego autenticado, mas não tiver fornecido valores para o uso de um proxy no assistente de implantação de pod, embora todos esses testes manuais sejam bem-sucedidos, o tráfego enviado por uma origem não autenticada, o jumpbox, falhará. O sintoma dessa situação é que a implantação do pod fica presa no estado pendente. Se você estiver nessa situação, deverá excluir o pod da página Introdução, executar novamente o assistente de implantação de pod e especificar as informações de proxy necessárias.

Pré-requisitos

Antes de executar esses testes, verifique se você criou uma VM de teste na sua assinatura do Microsoft Azure e tem uma conexão SSH com ela, conforme descrito em Criar a máquina virtual de teste na sua Assinatura do Microsoft Azure e Usar SSH para se conectar à VM de teste.

Obtenha os endereços IP e nomes de domínio totalmente qualificados (FQDNs) para servidores internos à sua rede e que você espera que sejam acessíveis pelo VNet, como seu Controlador de Domínio do Active Directory. Você usará essas informações no teste de verificação de DNS.

Procedimento

  1. Verifique se o DNS está funcionando em seu ambiente para resolver os FQDNs internos usando o comando dlg para consultar um nome de domínio conhecido que é interno para seu VNet no Microsoft Azure.
    Na janela de conexão SSH, emita o comando dig para consultar o nome de domínio de um servidor que você sabe que é interno à sua rede, como seu Controlador de Domínio do Active Directory.
    dig internal-domain-name
    Onde internal-domain-name é o nome de domínio completo de um servidor que você sabe é interno à sua rede.

    dig (Domain Information Groper) é uma ferramenta de linha de comando para solução de problemas de rede. Ao executar este comando usando um nome de host interno, o resultado verifica se a sua configuração de DNS pode resolver os endereços internos corretamente. Se a sua configuração de DNS puder resolver o internal-domain-name usado no comando, a saída do comando retornará o endereço IP correto associado a esse nome de domínio.

    Por exemplo, suponha que o VNet esteja configurado com um servidor interno do Active Directory que possui um Controlador de Domínio do Active Directory com a entrada DNS skylo.local e o endereço IP 192.168.0.15. Emitir dig skylo.local deveria verificar se a configuração de DNS do VNet pode resolver esse nome 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:~$
    O teste é bem-sucedido quando a ANSWER SECTION indica que o nome do host fornecido foi resolvido para o endereço IP que você espera para esse nome de host.
    Observação: Às vezes, o DNS não é 100% confiável, e algumas solicitações são resolvidas corretamente, enquanto outras falham. Se a emissão do comando falhar na primeira vez, execute o comando para dez a vinte iterações e consulte se você obteve respostas confiáveis a cada vez.
  2. Verifique se o DNS está funcionando em seu ambiente para resolver FQDNs externos usando o comando dlg para consultar um nome de domínio externo conhecido.
    Na janela de conexão SSH, emita o comando dig para consultar um nome de domínio externo padrão do setor, como vmware.com ou microsoft.com.
    dig external-domain-name
    Onde external-domain-name é um nome de domínio totalmente qualificado que é externo ao seu VNet. Por exemplo, emitir dig vmware.com verificaria se a configuração de DNS do VNet pôde possível resolver o nome 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:~
    No exemplo acima, a ANSWER SECTION indica que o nome de domínio externo vmware.com foi resolvido corretamente para dois endereços IP.
    Observação: Você pode repetir esse teste usando vários nomes de domínio externos, como azure.com ou microsoft.com, para verificar se o DNS pode resolver nomes externos diferentes.
    Se os testes de DNS não funcionarem, verifique as suas configurações de rede e o servidor DNS. Verifique que você adicionou seu servidor DNS ao seu VNet.
    Importante: Se você achar que precisará adicionar o seu servidor DNS ao seu VNet ou que precisará alterar a configuração do servidor DNS do VNet, deverá reiniciar todas as VMs que estão conectadas a esse VNet para que elas detectem a alteração. Se você alterar a configuração do servidor DNS do VNet e não reiniciar que todas as VMs conectadas a esse VNet, as alterações não serão propagadas corretamente no VNet.
  3. Verifique se as portas de saída necessárias estão disponíveis usando o comando netcat.
    O Horizon Cloud requer que algumas portas de saída sejam abertas, para que o software do pod possa ser baixado com segurança para o seu ambiente do Microsoft Azure e para que o pod possa conectar de volta com a camada de controle do Horizon Cloud. Conforme descrito em Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure, as seguintes portas TCP de saída precisam ser abertas da sub-rede de gerenciamento do pod: portas 80, 443 e 11371. Ao executar o comando netcat, conforme indicado no comando a seguir, você pode verificar se essas portas de saída estão abertas conforme necessário.
    Na janela de conexão SSH, execute os comandos a seguir (um por porta).
    Observação: O comando a seguir para testar a porta 11371 especifica packages.microsoft.com para testar essa conexão, enquanto as duas outras linhas testam a conexão de saída com a camada de controle do 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!
    Quando uma porta é aberta corretamente, o comando netcat retorna a linha succeeded! para seu teste.
    Se os comandos netcat retornarem falhas, verifique suas conexões de rede do Microsoft Azure, seus Grupos de Segurança de Rede na sua assinatura e todos os firewalls que você possa ter em funcionamento. Verifique se a sua configuração de rede atende aos requisitos de DNS, portas e protocolo que o pod precisa para a implantação, conforme descrito em Requisitos de DNS para um pod do Horizon Cloud no Microsoft Azure.

Resultados

Se os testes acima forem bem-sucedidos, você será capaz de implantar com êxito o seu pod.

Observação: Se você estiver configurando recursos opcionais para uso com o seu pod, como a autenticação de dois fatores Radius ou True SSO, portas adicionais poderão ser necessárias para as finalidades acima. Você pode usar as técnicas de teste acima da porta de saída para verificar se essas portas estão abertas corretamente.

O que Fazer Depois

Quando você concluir o teste, deverá excluir a VM de teste e todos os seus artefatos relacionados, como seu disco de VM, endereço IP, NIC, do seu ambiente do Microsoft Azure. Idealmente, você deveria ter criado um grupo de recursos para a VM de teste e poderá simplesmente excluir esse grupo de recursos para excluir todos os artefatos da VM. Siga as etapas em Excluir a VM de teste depois de concluir os testes.

Importante: Se você não excluir todos os artefatos da VM de teste do seu ambiente do Microsoft Azure e tiver conectado a VM a uma das sub-redes do pod, se tentar excluir o pod do ambiente do Horizon Cloud usando a ação Excluir no pod, o sistema poderá não ser capaz de excluir totalmente o pod devido a esses artefatos conectados restantes. Por padrão, quando você usa a ação Excluir para excluir um pod, o Horizon Cloud exclui esses grupos de recursos e sub-redes que ele criou para o pod. O Microsoft Azure impedirá a exclusão de sub-redes que ainda estão em uso. Se os artefatos da sua VM de teste estiverem conectados às sub-redes do pod, essas sub-redes não podem ser excluídas e a exclusão de pod ficará incompleta. Para evitar essa situação, certifique-se de que todos os artefatos da VM de teste sejam excluídos depois de você implantar o pod com êxito.