Para um uso bem-sucedido de ponta-a-ponta dos recursos do serviço, você deve garantir que os nomes DNS (Domain Name Service) descritos neste artigo de documentação sejam resolvíveis e acessíveis pelas sub-redes de gerenciamento e de tenants usando-se as portas e os protocolos específicos, conforme indicado nas tabelas deste artigo. O processo de implantação do pod que instancia um pod baseado em gerenciador de pods em uma assinatura do Microsoft Azure requer que os dispositivos relacionados ao implantador tenham acesso aos nomes DNS específicos na VNet selecionada. Em seguida, após o pod ser instanciado com êxito na assinatura com os respectivos dispositivos relacionados ao pod funcionando, várias operações de serviço diárias exigem acesso à rede a nomes DNS específicos, bem como o processo de atualização do pod para atualizar o software do pod quando a VMware disponibilizar o novo software para você. Este artigo descreve esses requisitos de DNS.

Alguns pontos principais

Sobre esses nomes DNS necessários
O implantador de pod do Horizon Cloud que automatiza o processo para instanciar pods baseados em gerenciador de pods e os gateways associados em suas assinaturas do Microsoft Azure requer acesso à rede a endereços DNS específicos por meio das VNets dessas assinaturas. Para o implantador de pod iniciar com êxito os componentes do pod na sua assinatura, você deve configurar os firewalls de modo que permitam que os dispositivos relacionados ao implantador de chaves tenham o acesso à rede necessário para acessar esses endereços DNS. O propósito de cada endereço DNS é indicado nas tabelas a seguir. Além de permitir a comunicação de rede com esses endereços DNS, sua configuração de DNS deve resolver nomes específicos, conforme descrito neste artigo. Quando você escolhe a opção de implantar o gateway externo na própria VNet separada da VNet do gerenciador de pods, essa sub-rede da VNet deve atender aos mesmos requisitos de DNS que a sub-rede de gerenciamento da VNet do gerenciador de pods.

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.

Além do implantador de pod e seus fluxos de trabalho, vários recursos de serviço exigem acesso a endereços DNS específicos para esses recursos funcionarem de ponta a ponta. Esses nomes DNS também são fornecidos nas tabelas a seguir.

Alguns desses nomes DNS têm um elemento regional para eles.

A ativação de Monitoramento de Infraestrutura do Horizon em um pod instanciará automaticamente o Dispositivo virtual do Horizon Edge na VNet e na sub-rede de gerenciamento do gerenciador de pods. O Dispositivo virtual do Horizon Edge tem os próprios requisitos de nome DNS. Portanto, antes de ativar o Monitoramento de Infraestrutura do Horizon em um pod, certifique-se de atender aos requisitos de DNS do Dispositivo virtual do Horizon Edge conforme indicado nas tabelas a seguir.

Sobre portas e protocolos após a implantação de um pod, para operações contínuas relacionadas ao serviço
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.

Nomes DNS da camada de controle regional

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
Europe-3 cloud-de.horizon.vmware.com

Para os endereços DNS regionais listados nas tabelas a seguir para o Dispositivo virtual do Horizon Edge, esses endereços usam as mesmas regiões que os nomes DNS da camada de controle regional.

Requisitos do DNS para o processo de implantação de pod principal, atualizações de pod, ativação de vários recursos de serviço e operações em andamento

Para um uso bem-sucedido de ponta-a-ponta dos recursos do serviço, você deve garantir que os nomes DNS a seguir sejam resolvíveis e acessíveis pelas sub-redes de gerenciamento e de tenants usando as portas e os protocolos específicos, conforme indicado nas seguintes tabelas deste artigo. Alguns dos recursos de serviço que exigem a capacidade de alcançar nomes DNS específicos são:

  • O implantador de pod que implanta automaticamente um pod do Horizon baseado no gerenciador de pods em sua assinatura do Microsoft Azure
  • O recurso de atualização do pod, que atualiza o software do pod para uma versão de software mais recente
  • O processo de importação de imagem que usa o assistente Importar do Marketplace
  • Os recursos relacionados ao agente, como a atualização automatizada do agente (AAU)
  • Universal Broker
  • Monitoramento de Infraestrutura do Horizon e seu Dispositivo virtual do Horizon Edge
  • Recursos relacionados ao Serviço de Gerenciamento de Nuvem (CMS)
Principalmente para implantação de pod, atualizações de pod e ao ativar o Monitoramento de Infraestrutura do Horizon em um pod
Você deve garantir que os seguintes nomes DNS sejam resolvíveis e acessíveis pela sub-redes do tenant e de gerenciamento usando as portas e os protocolos específicos, conforme indicado nas tabelas a seguir. Os dispositivos usados nesses fluxos de trabalho usam portas de saída específicas para baixar com segurança o software de que esses processos precisam para o seu ambiente do Microsoft Azure. Esses nomes DNS também são usados para que os dispositivos relacionados ao fluxo de trabalho apropriados possam se comunicar com a camada de controle de nuvem.

Para novas implantações de pod, você deve configurar as regras do firewall de rede, do grupo de segurança de rede (NSG) e os servidores proxy, de forma que os principais dispositivos relacionados à implantação tenham 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á.

Ativar o Monitoramento de Infraestrutura do Horizon em um pod instanciará o Dispositivo virtual do Horizon Edge na mesma VNet e sub-rede de gerenciamento que os dispositivos do gerenciador de pods desse pod. Você deve garantir a configuração do firewall de rede, das regras de NSG e dos servidores proxy permitam que oDispositivo virtual do Horizon Edge entre em contato com os endereços DNS nas portas necessárias. Caso contrário, a implantação desse dispositivo falhará.

Quando você estiver usando o recurso para implantar o gateway externo na própria VNet
A sub-rede de gerenciamento nessa VNet deve 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ê está implantando o pod com um gateway externo, um gateway interno ou ambos
Você deve 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.

Requisitos de DNS para implantação de novo pod, atualizações de pod e operações de serviço que se aplicam em todo o tenant

A tabela a seguir descreve os requisitos de DNS para uma nova implantação de pod, atualizações de pod e operações de serviço aplicáveis no âmbito do tenant. Para a ativação do Monitoramento de Infraestrutura do Horizon e requisitos de DNS do Dispositivo virtual do Horizon Edge, consulte a seção seguinte. Como o recurso do Monitoramento de Infraestrutura do Horizon é ativado por pod, seus requisitos de DNS garantem a própria tabela descritiva.

Atenção: A partir do início de 2021, como resultado de um upgrade das instâncias regionais da camada de controle do serviço, o nome DNS d1mes20qfad06k.cloudfront.net não é mais necessário para nenhuma das instâncias regionais da camada de controle. Todas as instâncias da camada de controle regional agora usam o nome DNS hydra-softwarelib-cdn.azureedge.net. O conteúdo da tabela a seguir está alinhado com essa realidade atual.
Tabela 2. Requisitos de DNS para implantação de novo pod, atualizações de pod e operações de serviço que se aplicam em todo o tenant
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 Implantações e integração ao Horizon Cloud para pods do Horizon e Microsoft Azure.
  • 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 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
  • Alemanha: cloud-de.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 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.)
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 esm.ubuntu.com 80 TCP Servidor de pacote de software do Ubuntu. Usado VMs baseadas em Linux do pod para rastrear atualizações de segurança para CVEs (Vulnerabilidades e Exposições Comuns) altas e críticas no sistema operacional base Ubuntu e na infraestrutura de dimensionamento horizontal.
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 Implantações e integração ao Horizon Cloud para pods do Horizon e Microsoft Azure.
  • 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 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
  • Alemanha: connector-azure-de.vmwarehorizon.com
Gerenciamento Dependendo de qual camada de controle regional se aplica à sua conta do Horizon Cloud:
  • América do Norte: kinesis.us-east-1.amazonaws.com
  • Europa, Alemanha: kinesis.eu-central-1.amazonaws.com
  • Austrália: kinesis.ap-southeast-2.amazonaws.com
  • Japão: kinesis.ap-northeast-1.amazonaws.com
  • Reino Unido: kinesis.eu-west-2.amazonaws.com
443 TCP Cloud Monitoring Service (CMS)
Locatário 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.

Requisitos de DNS do Dispositivo virtual do Horizon Edge

Ativar o Monitoramento de Infraestrutura do Horizon em um pod instanciará o Dispositivo virtual do Horizon Edgebaseado no Linux na sua assinatura do Microsoft Azure. O Dispositivo virtual do Horizon Edge é implantado na assinatura do pod com uma NIC na sub-rede de gerenciamento do pod: a mesma sub-rede de gerenciamento que os dispositivos do gerenciador de pods desse pod. Na tabela a seguir, os fins listados estão no contexto desse dispositivo virtual.

Observação: Não há nomes DNS com uk nessa tabela, como há na tabela anterior. Como afirmado nas Notas da versão, esse Monitoramento de Infraestrutura do Horizon está em Disponibilidade Limitada no momento.
Tabela 3. Requisitos de DNS do Monitoramento de Infraestrutura do Horizon
Origem da sub-rede Destino (nome DNS) Porta/Protocolo Finalidade
Gerenciamento
  • azure.archive.ubuntu.com
  • archive.ubuntu.com
  • changelogs.ubuntu.com
  • security.ubuntu.com
80 e 443/TCP Servidor de pacote de software do Ubuntu. Usado pelo dispositivo baseado em Linux para atualizações do sistema operacional Ubuntu.
Gerenciamento esm.ubuntu.com 80 / TCP Servidor de pacote de software do Ubuntu. Usado pelo dispositivo baseado em Linux para rastrear atualizações de segurança para CVEs (Vulnerabilidades e Exposições Comuns) altas e críticas no sistema operacional base Ubuntu e na infraestrutura de dimensionamento horizontal.
Gerenciamento
  • *.blob.core.windows.net
  • horizonedgeprod.azurecr.io
443/TCP Usado para acesso programático ao Armazenamento de Blob do Azure.

Usado para baixar as imagens do Docker dos endereços DNS necessários para o módulo do dispositivo.

Gerenciamento

*.azure-devices.net ou um dos nomes específicos da região abaixo, dependendo de qual camada de controle regional se aplica à sua conta de tenant:

América do Norte:

  • edgehubprodna.azure-devices.net

Europa:

  • edgehubprodeu.azure-devices.net

Austrália:

  • edgehubprodap.azure-devices.net

Japão:

  • edgehubprodjp.azure-devices.net
443/TCP Usado para conectar o dispositivo à camada de controle do Horizon Cloud, para baixar configurações do módulo do dispositivo e para atualizar o status de tempo de execução do módulo do dispositivo.
Gerenciamento
  • *.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 Usado para baixar binários do Docker e do Kubernetes necessários para o dispositivo.
Gerenciamento Dependendo de qual camada de controle regional se aplica à sua conta do tenant:

América do Norte:

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

Europa:

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

Austrália:

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

Japão:

  • kinesis.ap-northeast-1.amazonaws.com
  • sauron-jp.horizon.vmware.com
443/TCP Usado para enviar os dados de monitoramento de pod coletados pelo dispositivo à camada de controle do Horizon Cloud.

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

Conforme descrito em Requisitos de máquina virtual do Microsoft Azure para um pod do Horizon Cloud, uma 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 em Requisitos de máquina virtual do Microsoft Azure para um pod 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.