Para o processo de implantação do pod implantar o pod com êxito no Microsoft Azure, você deve configurar seus firewalls para permitir que o gerenciador de pods ativo acesse os endereços do Serviço de Nome de Domínio (DNS) necessários. Além disso, o DNS deve resolver nomes específicos, conforme descrito neste tópico. Além da implantação principal do pod, quando você estiver implantando o gateway externo na própria VNet, a sub-rede da VNet deverá atender aos mesmos requisitos de DNS que a sub-rede de gerenciamento da VNet de pod separada, conforme descrito neste tópico.

Importante:

O processo de implantação de pod usa uma VM jumpbox. Essa VM jumpbox tem requisitos de protocolo e porta para o processo de implantação de pod, bem como para definir as configurações das VMs do Unified Access Gateway do pod ao implantar uma configuração do Unified Access Gateway para o pod. Consulte Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods.

Implantar o gateway externo na própria VNet também usa a própria VM jumpbox, separada da do pod. Essa VM jumpbox tem os próprios requisitos de protocolo e portas para o processo de implantação de gateway. Consulte Quando o gateway externo é implantado na própria VNet: portas e protocolos exigidos pela jumpbox da configuração do gateway externo durante implantações e atualizações de gateway.

Depois que o pod for implantado com êxito, portas e protocolos específicos serão necessários para operações contínuas do Horizon Cloud. As portas e os protocolos específicos necessários dependem do fato de o pod estar na versão de manifesto para a versão de setembro de 2019 ou em uma versão anterior do manifesto.

Requisitos do DNS para o processo de implantação de pod principal, atualizações de pod e operações em andamento

Você deve garantir que os seguintes nomes DNS sejam resolvidos e acessíveis pela sub-redes do tenant e de gerenciamento usando as portas e os protocolos específicos, conforme indicado na tabela a seguir. O Horizon Cloud usa as portas de saída específicas para baixar com segurança o software do pod para seu ambiente do Microsoft Azure e para que o pod possa se conectar de volta à camada de controle da nuvem. Você deve configurar as regras do firewall de rede, do grupo de segurança de rede (NSG) e os servidores proxy, de forma que o gerenciador de pods ativo tenha a capacidade de entrar em contato com os endereços DNS nas portas necessárias. Caso contrário, o processo de implantação do pod falhará.

Importante:
  • Quando você estiver usando o recurso para implantar o gateway externo na própria VNet, a sub-rede de gerenciamento nessa VNet deverá atender aos mesmos requisitos de DNS conforme indicado na tabela abaixo para a sub-rede de gerenciamento na VNet do pod. A sub-rede de back-end da VNet e a sub-rede de zona desmilitarizada do gateway externo não têm requisitos de DNS específicos.
  • Quando você estiver implantando o pod com um gateway externo, um gateway interno ou ambos, deverá carregar um certificado que o implantador de pod configurará nessas configurações de gateway. Se o certificado ou os certificados que você fornecer para essa finalidade usarem as CRLs (listas de certificados revogados) ou as configurações de OCSP (protocolo de status de certificados on-line) que se referem a nomes DNS específicos, você deverá garantir que o acesso à internet de saída na VNet para esses nomes DNS seja resolvível e acessível. Durante a configuração do certificado fornecido na configuração do gateway do Unified Access Gateway, o software do Unified Access Gateway consultará esses nomes DNS para verificar o status de revogação do certificado. Se esses nomes DNS não estiverem acessíveis, a implantação do pod falhará durante a fase de Conexão. Esses nomes são altamente dependentes da autoridade de certificação que você usou para obter os certificados e, portanto, não estão no controle da VMware.

O email Bem-vindo(a) ao Horizon Service indicará a instância da camada de controle regional na qual sua conta de tenant foi criada. Devido a um problema conhecido que existia quando o e-mail de boas-vindas foi enviado para você, o e-mail que você recebeu pode exibir os nomes das cadeias de caracteres do sistema usados para as regiões em vez de nomes amigáveis. Se você vir um nome de cadeia de caracteres do sistema no seu email de boas-vindas, poderá usar a tabela a seguir para relacionar o que é mostrado no seu email com os nomes DNS da camada de controle regional.

Tabela 1. Regiões no seu e-mail de boas-vindas mapeadas para nomes DNS da camada de controle regional
Seu email de boas-vindas diz Nome DNS regional
USA cloud.horizon.vmware.com
EU_CENTRAL_1 ou Europe cloud-eu-central-1.horizon.vmware.com
AP_SOUTHEAST_2 ou Australia cloud-ap-southeast-2.horizon.vmware.com
PROD1_NORTHCENTRALUS2_CP1 ou USA-2 cloud-us-2.horizon.vmware.com
PROD1_NORTHEUROPE_CP1 ou Europe-2 cloud-eu-2.horizon.vmware.com
PROD1_AUSTRALIAEAST_CP1 ou Australia-2 cloud-ap-2.horizon.vmware.com
Japan cloud-jp.horizon.vmware.com
UK cloud-uk.horizon.vmware.com
Tabela 2. Requisitos de DNS de operações e de implantação do pod
Origem da sub-rede Destino (nome DNS) Porta Protocolo Finalidade
Gerenciamento Um dos seguintes nomes, dependendo de qual instância da camada de controle regional está especificada em sua conta de tenant do Horizon Cloud. A instância regional é definida quando a conta é criada, conforme descrito em Como fazer a integração ao Horizon Cloud for Microsoft Azure, ao Horizon no Local e ao Horizon no 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
  • cloud-uk.horizon.vmware.com
443 TCP Instância da camada de controle 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
  • Ásia-Pacífico: cloud-ap-southeast-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com
  • Japão: cloud-jp.horizon.vmware.com
  • Reino Unido: cloud-uk.horizon.vmware.com
Gerenciamento softwareupdate.vmware.com 443 TCP Servidor de pacote de software da VMware. Usado para baixar atualizações do software relacionadas ao agente usado em operações relacionadas à imagem do sistema.
Gerenciamento Um dos seguintes nomes, dependendo de qual dos nomes DNS regionais se aplica à sua conta.
  • d1mes20qfad06k.cloudfront.net
  • hydra-softwarelib-cdn.azureedge.net
443 TCP Servidor de distribuição de conteúdo do Horizon Cloud. Na sub-rede gerenciamento, este site é usado para baixar os VHDs (discos virtuais) para as VMs do gerenciador de pod e do Unified Access Gateway. Também usado para o VHD da VM do conector de gateway, no caso em que o gateway externo está na própria VNet.)

d1mes20qfad06k.cloudfront.net corresponde a instâncias regionais 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 às instâncias regionais de cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com, cloud-jp.horizon.vmware.com, cloud-uk.horizon.vmware.com

Gerenciamento packages.microsoft.com 443 e 11371 TCP Servidor de pacote de software da Microsoft. Usado para baixar com segurança o software Interface de Linha de Comando (CLI) do Microsoft Azure.
Gerenciamento azure.archive.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas em Linux relacionadas ao pod para atualizações do sistema operacional Ubuntu.
Gerenciamento api.snapcraft.io 443 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para atualizações do sistema operacional Ubuntu.
Gerenciamento archive.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para atualizações do sistema operacional Ubuntu.
Gerenciamento changelogs.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para rastreamento das atualizações do sistema operacional Ubuntu.
Gerenciamento security.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado por VMs baseadas no Linux do pod para rastreamento das atualizações do sistema operacional Ubuntu relacionadas à segurança.
Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você está implantando seu pod:
  • Microsoft Azure (global): login.microsoftonline.com
  • Microsoft Azure Alemanha: login.microsoftonline.de
  • Microsoft Azure China: login.chinacloudapi.cn
  • Governo dos EUA do Microsoft Azure: login.microsoftonline.us
443 TCP Esse endereço da Web é geralmente usado pelos aplicativos para autenticação em serviços do Microsoft Azure. Para obter algumas descrições na documentação do Microsoft Azure, consulte Fluxo do código de autorização OAuth 2.0 , Azure Active Directory v2.0 e o protocolo OpenID Connect e Nuvens nacionais . O tópico Nuvens nacionais descreve como existem diferentes endpoints de autenticação do Azure AD para cada nuvem nacional do Microsoft Azure.
Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você está implantando seu pod:
  • Microsoft Azure (global): management.azure.com
  • Microsoft Azure Alemanha: management.microsoftazure.de
  • Microsoft Azure China: management.chinacloudapi.cn
  • Microsoft Azure Governo dos EUA: management.usgovcloudapi.net
443 TCP Usado para solicitações de API de pod aos endpoints do Gerenciador de Recurso do Microsoft Azure para usar os serviços do Gerenciador de Recurso do Microsoft Azure. O Microsoft Azure Resource Manager fornece uma camada de gerenciamento consistente para realizar tarefas por meio do Azure PowerShell, da CLI do Azure, do portal do Azure, da REST API e dos SDKs de cliente.
Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você está implantando seu pod:
  • Microsoft Azure (global): graph.windows.net
  • Microsoft Azure Alemanha: graph.cloudapi.de
  • Microsoft Azure China: graph.chinacloudapi.cn
  • Microsoft Azure Governo dos EUA: graph.windows.net
443 TCP Acesso à API do Graph do Azure Active Directory (Azure AD), que é usada para acesso programático do pod ao Azure Active Directory (Azure AD) por meio de endpoints da REST API OData.
Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você implantou seu pod:
  • Microsoft Azure (global): *.blob.core.windows.net
  • Microsoft Azure Alemanha: *.blob.core.cloudapi.de
  • Microsoft Azure China: *.blob.core.chinacloudapi.cn
  • Microsoft Azure Governo dos EUA: *.blob.core.usgovcloudapi.net
443 TCP Usado para acesso programático do pod ao Armazenamento de Blobs do Azure. O Armazenamento de Blobs do Azure é um serviço para armazenar grandes quantidades de dados de objetos não estruturados, como texto ou dados binários.
Gerenciamento Um dos seguintes, dependendo da nuvem do Microsoft Azure na qual você implantou seu pod:
  • Microsoft Azure (global): *.vault.azure.net
  • Microsoft Azure Alemanha: *.vault.microsoftazure.de
  • Microsoft Azure China: *.vault.azure.cn
  • Microsoft Azure Governo dos EUA: *.vault.usgovcloudapi.net
443 TCP Usado para a capacidade do pod de trabalhar programaticamente com o serviço de nuvem Cofre de Chaves do Azure. O Cofre de Chaves do Azure é um serviço de nuvem que fornece um armazenamento seguro para segredos.
Gerenciamento Se o seu firewall ou grupo de segurança de rede (NSG) oferecer suporte ao uso de tags de serviço, será uma das seguintes:
  • Etiqueta de serviço global do SQL do Azure: Sql
  • Etiqueta de serviço SQL específica à região para a região do Azure onde o pod é implantado: Sql.região, por exemplo, Sql.WestUS.

Se o seu firewall ou grupo de segurança de rede (NSG) não oferecer suporte ao uso de tags de serviço, você poderá usar o nome do host da base de dados. Esse nome segue o padrão *.postgres.database.azure.com.

5432 TCP Usado para comunicação do pod com o servidor do Banco de Dados do Microsoft Azure para PostgreSQL. A partir da versão de setembro de 2019, os pods recém-implantados após essa data de lançamento e os pods atualizados para a versão de manifesto dessa versão são configurados com um servidor do Banco de Dados do Microsoft Azure para PostgreSQL.

Para obter informações sobre as tags de serviço em grupos de segurança, consulte o tópico de documentação do Microsoft Azure em Tags de Serviço.

Gerenciamento Um dos seguintes nomes, dependendo de qual instância da camada de controle regional está especificada em sua conta de tenant do Horizon Cloud. A instância regional é definida quando a conta é criada, conforme descrito em Como fazer a integração ao Horizon Cloud for Microsoft Azure, ao Horizon no Local e ao Horizon no VMware Cloud on AWS.
  • 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
443 TCP Instância regional do serviço Universal Broker
  • Estados Unidos: connector-azure-us.vmwarehorizon.com
  • Europa: connector-azure-eu.vmwarehorizon.com
  • Austrália: connector-azure-aus.vmwarehorizon.com
  • Japão: connector-azure-jp.vmwarehorizon.com
  • Reino Unido: connector-azure-uk.vmwarehorizon.com
Locatário Um dos seguintes nomes, dependendo de qual dos nomes DNS regionais se aplica à sua conta.
  • d1mes20qfad06k.cloudfront.net
  • hydra-softwarelib-cdn.azureedge.net
443 TCP Servidor de distribuição de conteúdo do Horizon Cloud. Na sub-rede do locatário, este site é usado pelo processo de Importação de Imagem automatizado do sistema para baixar o instalador para o software relacionado ao agente.

d1mes20qfad06k.cloudfront.net corresponde a instâncias regionais 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 às instâncias regionais de cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com, cloud-jp.horizon.vmware.com, cloud-uk.horizon.vmware.com

Locatário Dependendo da camada de controle regional especificada em sua conta do Horizon Cloud:

América do 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

Austrália:

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

Japão:

  • kinesis.ap-northeast-1.amazonaws.com
  • query-prod-ap-northeast-1.cms.vmware.com

Reino Unido:

  • kinesis.eu-west-2.amazonaws.com
  • query-prod-eu-west-2.cms.vmware.com
443 TCP Cloud Monitoring Service (CMS)

Portas e protocolos exigidos pela jumpbox do pod durante implantações de pods e atualizações de pods

Conforme descrito no Guia de implantação do Horizon Cloud, a VM jumpbox é usada na criação inicial de um pod e durante atualizações de software subsequentes no ambiente do pod. Depois que um pod é criado, a VM jumpbox é excluída. Em seguida, quando um pod estiver sendo atualizado, a VM jumpbox é recriada para executar esse processo de atualização e é excluída quando a atualização é concluída. Essas atualizações incluem quando um pod é editado para adicionar uma configuração do Unified Access Gateway.

Observação: Um pod já implantado no Microsoft Azure na versão de setembro de 2019 ou que é atualizado para ela e tem alta disponibilidade habilitada terá duas VMs de gerenciador. Os parágrafos a seguir usam a palavra VMs no plural para indicar que a VM jumpbox deve se comunicar com todas as VMs de gerenciador do pod, tenha o pod apenas uma ou duas.

Durante esses processos, essa VM jumpbox se comunica com:

  • As VMs de gerenciador do pod usando SSH para a porta 22 das VMs de gerenciador. Como resultado, durante o processo de implantação do pod e o processo de atualização do pod, o requisito de comunicação entre a VM jumpbox e a porta 22 das VMs do gerenciador deve ser atendido. A porta 22 das VMs do gerenciador de pods deve ser permitida entre a VM jumpbox como uma origem e as VMs do gerenciador de pods como um destino.
  • As VMs do Unified Access Gateway usando HTTPS para a porta 9443 dessas VMs, no caso em que um pod é implantado com uma configuração do Unified Access Gateway ou editado para adicionar uma. Como resultado, durante o processo de implantação do pod e o processo de atualização do pod, quando a configuração do pod inclui Unified Access Gateway, o requisito de comunicação entre a VM jumpbox e a porta 9443 das VMs do Unified Access Gateway deve ser atendido. A porta 9443 das VMs do Unified Access Gateway deve ser permitida entre a VM jumpbox como uma origem e as VMs do Unified Access Gateway como um destino.

Como são atribuídos endereços IP dinamicamente a essas VMs, as regras de rede para permitir essa comunicação devem usar:

  • O CIDR de sub-rede de gerenciamento como a origem e o destino, com a porta de destino 22, a porta de origem qualquer uma e o TCP de protocolo.
  • O CIDR de sub-rede de gerenciamento como a origem e o destino, com a porta de destino 9443, a porta de origem qualquer uma e o TCP de protocolo, quando uma configuração do Unified Access Gateway está envolvida.
Observação: As operações do pod em andamento não exigem disponibilidade da porta 22 nas VMs de gerenciador do pod. No entanto, se você fizer uma solicitação de suporte à VMware e à equipe de suporte determinar que a maneira de depurar essa solicitação é implantar uma VM jumpbox para comunicação SSH com as VMs do gerenciador do seu pod, será necessário atender a esse requisito de porta durante o tempo em que a equipe de suporte da VMware precisar da porta para depurar seu problema. A equipe de suporte da VMware informará sobre quaisquer requisitos, conforme apropriado para qualquer situação de suporte.

Quando o gateway externo é implantado na própria VNet: portas e protocolos exigidos pela jumpbox da configuração do gateway externo durante implantações e atualizações de gateway

Conforme descrito no Guia de implantação do Horizon Cloud, uma VM jumpbox é usada na criação inicial de um gateway externo na própria VNet e durante atualizações de software subsequentes nesse gateway. Quando o gateway externo for criado na própria VNet, a VM jumpbox será excluída. Em seguida, quando um gateway externo estiver sendo atualizado, a VM jumpbox será recriada para executar esse processo de atualização e será excluída quando a atualização for concluída. Essas atualizações incluem quando um pod é editado para adicionar um gateway externo na própria VNet.

Durante esses processos, essa VM jumpbox se comunica com:

  • Durante esses processos, essa VM jumpbox se comunica com a VM do conector do gateway usando o SSH para a porta 22 da VM do conector. Como resultado, durante o processo de implantação do gateway e o processo de atualização, o requisito de comunicação entre a VM jumpbox e a porta 22 das VMs do conector deve ser atendido. A porta 22 das VMs do conector deve ser permitida entre a VM jumpbox como uma origem e as VMs do conector como um destino.
  • As VMs do Unified Access Gateway usando HTTPS para a porta 9443 dessas VMs. Como resultado, durante o processo de implantação do pod e o processo de atualização do pod, quando a configuração do pod inclui Unified Access Gateway, o requisito de comunicação entre a VM jumpbox e a porta 9443 das VMs do Unified Access Gateway deve ser atendido. A porta 9443 das VMs do Unified Access Gateway deve ser permitida entre a VM jumpbox como uma origem e as VMs do Unified Access Gateway como um destino.

Como são atribuídos endereços IP dinamicamente a essas VMs, as regras de rede para permitir essa comunicação devem usar:

  • O CIDR de sub-rede de gerenciamento como a origem e o destino, com a porta de destino 22, a porta de origem qualquer uma e o TCP de protocolo.
  • O CIDR de sub-rede de gerenciamento como a origem e o destino, com a porta de destino 9443, a porta de origem qualquer uma e o TCP de protocolo.
Observação: As operações do pod em andamento não exigem disponibilidade da porta 22 na VM do conector do gateway. No entanto, se você fizer uma solicitação de suporte à VMware e à equipe de suporte determinar que a maneira de depurar essa solicitação é implantar uma VM jumpbox para comunicação SSH com a VM do conector desse gateway, será necessário atender a esse requisito de porta durante o tempo em que a equipe de suporte da VMware precisar da porta para depurar seu problema. A equipe de suporte da VMware informará sobre quaisquer requisitos, conforme apropriado para qualquer situação de suporte.