Esta página é uma referência para todas as possíveis portas e protocolos usadas para comunicação em uma implantação típica do Horizon Cloud Service on Microsoft Azure de primeira geração. Use estas tabelas para garantir que sua configuração de rede e firewalls permitam o tráfego de comunicação necessário para uma implantação bem-sucedida de pod e as operações diárias.

Sobre esta página

Importante: Essas informações aplicam-se apenas quando você tem acesso a um ambiente de tenant de primeira geração na camada de controle de primeira geração. Conforme descrito em KB-92424, a camada de controle de primeira geração atingiu o fim da disponibilidade (EOA). Consulte esse artigo para obter detalhes.
Observação: Conforme descrito no artigo 93762 da Base de Dados de Conhecimento da VMware, o recurso Horizon Infrastructure Monitoring foi descontinuado e os tenants de primeira geração não podem mais ativar nem usar esse recurso. A partir de outubro de 2023, as informações de portas e protocolos relacionadas a esse recurso preterido foram removidas desta página.

Em parte, as portas e os protocolos específicos necessários para a sua implantação específica dependerão dos recursos selecionados para uso na sua implantação do Horizon Cloud Service on Microsoft Azure. Se você planeja não usar um componente ou protocolo específico, seu tráfego de comunicação necessário não será necessário para sua finalidade, e você poderá ignorar as portas associadas a esse componente. Por exemplo, se os usuários finais usarem apenas o protocolo de exibição Blast Extreme, permitir as portas PCoIP não será um requisito.

Importante: Além das portas e protocolos descritos aqui, o tráfego de rede para implantações de pods e operações diárias tem requisitos de nome de host específicos.

O tráfego de rede deve atingir nomes de host específicos. Se a implantação estiver configurada para usar um proxy, espera-se que alguns serviços de rede usem o proxy que outros serviços de rede sejam diretos. Para obter detalhes sobre o tráfego de rede para nomes de host, consulte Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS.

Para obter informações sobre outras portas compatíveis com produtos VMware, acesse VMware Ports and Protocols.

Como parte do processo de implantação de pod, o implantador cria grupos de segurança de rede (NSGs) nas interfaces de rede (NICs) em todas as VMs implantadas. Para obter detalhes sobre as regras definidas nesses NSGs, consulte Regras de Grupo de Segurança de Rede Padrão para as VMs em um Pod do Horizon Cloud.

Portas e protocolos exigidos pelos principais componentes do pod para operações contínuas

Além dos requisitos de DNS, as portas e os protocolos nas tabelas a seguir são necessários para que o pod funcione adequadamente para operações em andamento após a implantação. Algumas dessas tabelas também listam portas e protocolos necessários para cenários específicos ou quando você tiver ativado recursos específicos no pod.

No portal do Microsoft Azure, as VMs do gerenciador de pods têm nomes que contêm uma parte como vmw-hcs-podID, em que podID é o UUID do pod, e uma parte de node.

Observação: A partir da versão de serviço v2204, novas implantações do Horizon Cloud Service on Microsoft Azure são implantadas com alta disponibilidade configurada por padrão. A implantação tem duas VMs de gerenciador de pods. Nas tabelas abaixo, onde quer que você veja a frase VM do gerenciador de pods, esse termo se aplica a ambas as VMs do gerenciador de pods, a menos que indicado de outra forma.

O uso pelo sistema de um balanceador de carga do Microsoft Azure com as VMs do gerenciador de pods começou a partir do manifesto 1600, na versão de serviço de setembro de 2019. Portanto, todos os pods implantados a partir do manifesto 1600 em diante têm um balanceador de carga do Microsoft Azure do pod. Os pods que foram implantados antes do manifesto 1600 e posteriormente atualizados para manifestos posteriores também têm um balanceador de carga do Microsoft Azure do pod. As linhas da tabela que mencionam o balanceador de carga do pod se aplicam a todos esses pods.

Tabela 1. Portas e Protocolos das Operações do Pod
Origem Destino Portas Protocolo Finalidade
VM do gerenciador de pods A outra VM do gerenciador de pods 4101 TCP Esse tráfego é o roteamento do JMS entre as VMs do gerenciador de pods.
VM do gerenciador de pods VMs do Unified Access Gateway 9443 HTTPS Essa porta é usada pela VM do gerenciador de pod na sub-rede de gerenciamento para definir as configurações na configuração do Unified Access Gateway do pod. Esse requisito de porta é aplicável quando se implanta inicialmente um pod com uma configuração do Unified Access Gateway e quando se edita um pod para adicionar uma configuração do Unified Access Gateway ou atualizar as definições para essa configuração do Unified Access Gateway.
Balanceador de carga do Microsoft Azure do pod VM do gerenciador de pods 8080 HTTP Verificações de integridade das VMs no pool de back-end do balanceador de carga.

Para pods implantados antes da versão v2204 em que a alternância de alta disponibilidade não esteja definida e a alta disponibilidade ainda não tenha sido adicionada, o balanceador de carga tem uma VM do gerenciador de pods que é seu pool de back-end para verificação.

VM do gerenciador de pods Controlador de domínio 389 TCP

UDP

Registrar seu tenant do Horizon Cloud com um Active Directory é um requisito. O fluxo de trabalho Registrar Domínio do AD do console deve ser executado após a integração do primeiro pod.

Essa porta é necessária para serviços LDAP quando o LDAP será especificado nesse fluxo de trabalho. O LDAP é o padrão para a maioria dos tenants.

O destino é o servidor que contém uma função de controlador de domínio na configuração do Active Directory.

VM do gerenciador de pods Catálogo global 3268 TCP Registrar seu tenant do Horizon Cloud com um Active Directory é um requisito. O fluxo de trabalho Registrar Domínio do AD do console deve ser executado após a integração do primeiro pod.

Essa porta é necessária para serviços LDAP quando o LDAP será o protocolo especificado nesse fluxo de trabalho. O LDAP é o padrão para a maioria dos tenants.

O destino é o servidor que contém a função de catálogo global na configuração do Active Directory.

VM do gerenciador de pods Controlador de domínio 88 TCP

UDP

Serviços do Kerberos. O destino é o servidor que contém uma função de controlador de domínio em uma configuração de domínio do Active Directory. Registrar o pod com um Active Directory é um requisito.
VM do gerenciador de pods Controlador de domínio 636, 3269 TCP Registrar seu tenant do Horizon Cloud com um Active Directory é um requisito. O fluxo de trabalho Registrar Domínio do AD do console deve ser executado após a integração do primeiro pod.

Essas portas são necessárias para serviços LDAP sobre SSL (LDAPS) somente quando o LDAPS será o protocolo especificado na configuração para esse AD registrado. O LDAPS só poderá ser especificado para o AD registrado quando o tenant estiver ativado para usar o recurso LDAPS do serviço. Caso contrário, o LDAP é o requisito por padrão.

VM do gerenciador de pods Servidor DNS 53 TCP

UDP

Serviços DNS.
VM do gerenciador de pods Servidor NTP 123 UDP Serviços NTP. Servidor que fornece a sincronização de horário do NTP.
VM do gerenciador de pods Servidor de Registro do True SSO 32111 TCP Servidor de Registro do True SSO. Obrigatório se você estiver usando o True SSO com seus pods do Horizon.

32111 é a porta padrão usada na instalação do Servidor de Registro. Esse número de porta pode ser configurado durante o processo de instalação do Servidor de Registro de acordo com seus requisitos.

Consulte também a seção True SSO, Gerenciamento de certificados e implantações do Horizon Cloud on Microsoft Azure neste tópico.

VM do gerenciador de pods Serviço Workspace ONE Access 443 HTTPS
Observação: Essa linha é aplicável a ambientes com uma configuração do agente de pod único. Essas informações não são para ambientes com uma configuração do Universal Broker. Em um ambiente configurado com o agente de pod único, o Workspace ONE Access Connector se comunica com um pod para obter os direitos do usuário final (as atribuições).
Opcional se você não estiver integrando o Workspace ONE Access ao pod. Em um ambiente configurado com o agente de pod único, essa conexão é usada para criar uma relação de confiança entre o pod e o serviço Workspace ONE Access, em que o Workspace ONE Access Connector é sincronizado com o pod. Verifique se o pod pode acessar o ambiente do Workspace ONE Access que você está usando na porta 443. Quando você estiver usando o serviço de nuvem do Workspace ONE Access, consulte também a lista de endereços IP do Workspace ONE Access aos quais o Workspace ONE Access Conector e o pod devem ter acesso no artigo 2149884 da Base de Dados de Conhecimento da VMware.

Requisitos de protocolos e portas da VM do conector do gateway

Esta tabela se aplica à VM do conector do gateway usada quando você implantou o gateway externo em uma VNet separada. Além dos requisitos de DNS, as portas e os protocolos na tabela a seguir são necessários para que o gateway externo funcione adequadamente para operações em andamento após a implantação.

Na tabela abaixo, o termo VM do conector refere-se à VM do conector do gateway que gerencia a conexão entre o plano de gerenciamento de nuvem e o gateway externo. No portal do Microsoft Azure, parte do nome dessa VM é vmw-hcs-ID, em que ID é a ID do implantador do gateway, e outra parte é node.

Tabela 2. Portas e Protocolos das Operações do Pod
Origem Destino Portas Protocolo Finalidade
VM do conector Servidor DNS 53 TCP

UDP

Serviços DNS.
VM do conector Servidor NTP 123 UDP Serviços NTP. Servidor que fornece a sincronização de horário do NTP.

Requisitos de portas e protocolos da VM do Unified Access Gateway

Além dos requisitos de protocolos e portas principais acima e do DNS, as portas e os protocolos nas tabelas a seguir se relacionam aos gateways que você configurou no pod para funcionar corretamente para operações contínuas após a implantação.

Para conexões que usam um pod habilitado à alta disponibilidade configurado com as instâncias do Unified Access Gateway, o tráfego deve ser permitido nas instâncias do Unified Access Gateway do pod para destinos, conforme listado na tabela abaixo. Durante a implantação do pod, um Grupo de Segurança de Rede (NSG) é criado no ambiente do Microsoft Azure para uso pelas instâncias do Unified Access Gateway do pod.

Tabela 3. Requisitos de porta para o tráfego proveniente das instâncias do Unified Access Gateway do pod
Origem Destino Porta Protocolo Finalidade
Unified Access Gateway Balanceador de carga do Microsoft Azure do pod 8443 TCP Tráfego de autenticação de login. O tráfego das instâncias do Unified Access Gateway chega às VMs do gerenciador de pods por meio do balanceador de carga do pod.
Unified Access Gateway Servidor NTP 123 UDP Serviços NTP. Servidor que fornece a sincronização de horário do NTP.

Quando seu tenant estiver configurado para usar o Universal Broker, verifique se estes pontos foram atendidos:

  • A configuração externa do Unified Access Gateway deve ter conectividade com servidores NTP da sub-rede DMZ.
  • As configurações internas do Unified Access Gateway devem ter conectividade com servidores NTP da sub-rede do tenant.

O motivo é que, se o serviço detectar que há um desvio de tempo entre os dispositivos do Unified Access Gateway e o servidor NTP do Universal Broker que está executando o UTC (Tempo Universal Coordenado), um email será enviado a você para solicitar que você resolva o desvio de tempo. Os desvios de tempo entre o Universal Broker e os dispositivos Unified Access Gateway podem resultar em falhas nas conexões do usuário final. Quando suas configurações internas do Unified Access Gateway não estão conectadas a um servidor NTP da sub-rede de tenant, é mais provável que elas sofram esses desvios de tempo, pois sem um servidor NTP, esses dispositivos do Unified Access Gateway dependerão do tempo da VM subjacente.

Se o servidor NTP que você deseja usar for um servidor NTP interno e não tiver permissão para se comunicar pela interface DMZ, abra um SR para que a equipe do VMware Horizon Cloud Service possa ajudar na adição de rotas à configuração do Unified Access Gateway após a implantação, para que o O Unified Access Gateway possa se comunicar com seu servidor NTP. A equipe do VMware Horizon Cloud Service tem chamadas de API a fim de adicionar as rotas para você.

Dica: Quando seu tenant está configurado para usar a intermediação de pod único, os pontos acima são considerados práticas recomendadas, pois no cenário do agente de pod único, o desvio de tempo com os dispositivos Unified Access Gateway não afeta as conexões do usuário final.
Unified Access Gateway Horizon Agent nas VMs RDSH de farm ou área de trabalho 4172 TCP

UDP

PCoIP
Unified Access Gateway Horizon Agent nas VMs RDSH de farm ou área de trabalho 22443 TCP

UDP

Blast Extreme

Por padrão, quando Blast Extreme é usado, o tráfego de redirecionamento de unidade do cliente (CDR) e o tráfego USB são encapsulados por lado nesta porta. Se você preferir, o tráfego de CDR pode ser separado na porta TCP 9427 e o tráfego de redirecionamento USB pode ser separado na porta TCP 32111.

Unified Access Gateway Horizon Agent nas VMs RDSH de farm ou área de trabalho 9427 TCP Opcional para o tráfego de redirecionamento de unidade do cliente (CDR) e de redirecionamento de multimídia (MMR).
Unified Access Gateway Horizon Agent nas VMs RDSH de farm ou área de trabalho 32111 TCP Opcional para o tráfego de redirecionamento USB.
Unified Access Gateway Sua instância do RADIUS 1812 UDP Ao usar a autenticação de dois fatores RADIUS com essa configuração do Unified Access Gateway. O valor padrão para RADIUS é mostrado aqui.
Unified Access Gateway Seu servidor RSA SecurID Authentication Manager 5555 TCP Ao usar a autenticação de dois fatores RSA SecurID com essa configuração do Unified Access Gateway. Aqui é mostrado o valor padrão usado para a porta de comunicação para agentes de API de Autenticação RSA SecurID para autenticação de agente.

Portas e protocolos exigidos pelo Universal Broker

Para oferecer suporte ao uso do Universal Broker para a intermediação de atribuições de usuários finais a partir de um pod, você deve configurar a porta 443 conforme descrito na tabela a seguir. O gerenciador de pods ativo estabelece uma conexão de WebSocket persistente com o serviço do Universal Broker por meio da porta 443 e recebe solicitações de conexão do serviço do Universal Broker por meio de uma porta selecionada aleatoriamente.

Tabela 4. Requisitos de porta para o Universal Broker
Origem Porta de origem Destino Porta de destino Protocolo Finalidade
Gerenciador de pods ativo Selecionado aleatoriamente de portas disponíveis Serviço Universal Broker 443 Primeiro HTTPS; depois WebSocket Usado para estabelecer uma conexão persistente do WebSocket com o serviço do Universal Broker

Requisitos de protocolos e portas de tráfego de conexão do usuário final

Para se conectar aos aplicativos remotos e áreas de trabalho virtuais provisionados pelo pod dos seus dispositivos, seus usuários finais usam um VMware Horizon Client instalado compatível ou seu navegador (conhecido como cliente do Horizon HTML Access). As portas que devem ser abertas para o tráfego dos clientes dos usuários finais alcançar suas áreas de trabalho virtuais provisionadas por pod e aplicativos remotos dependem da escolha que você fizer sobre como seus usuários finais se conectarão:

Quando você escolhe a opção de implantador de ter uma configuração de gateway externo na própria VNet do pod
O implantador implanta instâncias do Unified Access Gateway no ambiente do Microsoft Azure, juntamente com um recurso do balanceador de carga do Microsoft Azure para essas instâncias nesse pool de backend do balanceador de carga. Esse balanceador de carga se comunica com os NICs dessas instâncias na sub-rede DMZ e está configurado como um balanceador de carga público no Microsoft Azure. O diagrama Ilustração da Arquitetura do Horizon Cloud Pod em que o pod tem configurações do gateway externo e interno, o gateway externo implantado na mesma VNet que o pod, três NICs nas VMs de gateway externo, duas NICs nas VMs de gateway interno e um IP público ativado para o balanceador de carga do gateway externo descreve o local desse balanceador de carga público e das instâncias do Unified Access Gateway.Quando seu pod tem essa configuração, o tráfego dos seus usuários finais na Internet vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de carga usando as portas e os protocolos listados abaixo. Após a implantação, o balanceador de carga do gateway externo estará localizado no grupo de recursos denominado vmw-hcs-podID-uag, em que podID é o UUID do pod.
Quando você escolhe a opção do implantador de configuração interna do Unified Access Gateway
Uma configuração de gateway interno é implantada na própria VNet do pod por padrão. O implantador implanta instâncias do Unified Access Gateway no ambiente do Microsoft Azure, juntamente com um recurso do balanceador de carga do Microsoft Azure para essas instâncias nesse pool de backend. Esse balanceador de carga se comunica com as NICs dessas instâncias na sub-rede do tenant e está configurado como um balanceador de carga interno no Microsoft Azure. O diagrama Ilustração da Arquitetura do Horizon Cloud Pod em que o pod tem configurações do gateway externo e interno, o gateway externo implantado na mesma VNet que o pod, três NICs nas VMs de gateway externo, duas NICs nas VMs de gateway interno e um IP público ativado para o balanceador de carga do gateway externo descreve o local desse balanceador de carga interno e das instâncias do Unified Access Gateway. Quando seu pod tem essa configuração, o tráfego dos seus usuários finais em sua rede corporativa vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de carga usando as portas e os protocolos listados abaixo. Após a implantação, o balanceador de carga do gateway interno estará localizado no grupo de recursos denominado vmw-hcs-podID-uag-internal, em que podID é o UUID do pod.
Quando você escolhe as opções do implantador de configuração de gateway externo na própria VNet e não nos pods, ou a opção de usar a própria assinatura (que é um subcaso especial de uso da própria VNet, pois as VNets não abrangem as assinaturas)
O implantador implanta instâncias do Unified Access Gateway no ambiente do Microsoft Azure, juntamente com um recurso do balanceador de carga do Microsoft Azure para essas instâncias nesse pool de backend do balanceador de carga. Esse balanceador de carga se comunica com os NICs dessas instâncias na sub-rede DMZ e está configurado como um balanceador de carga público no Microsoft Azure. O diagrama Ilustração dos elementos de arquitetura do gateway externo quando o gateway externo é implantado na própria VNet, separado da do pod descreve o local desse balanceador de carga público e das instâncias do Unified Access Gateway na própria VNet do gateway.Quando seu pod tem essa configuração, o tráfego dos seus usuários finais na Internet vai para esse balanceador de carga, que distribui as solicitações para as instâncias do Unified Access Gateway. Para essa configuração, você deve garantir que essas conexões de usuários finais possam chegar ao balanceador de carga usando as portas e os protocolos listados abaixo. Após a implantação, o balanceador de carga do gateway externo estará localizado no grupo de recursos chamado vmw-hcs-ID-uag, em que ID é o valor exibido no campo ID do Implantador da página de detalhes do pod. Conforme descrito no Guia de Administração, você acessa a página de detalhes do pod pela página Capacidade do console.
Quando você não tem configurações do Unified Access Gateway no pod
Observação: Para ambientes de produção em que o tenant está configurado para usar a intermediação de pod único, a prática recomendada para conexões de usuário final internas é usar uma configuração de gateway do Unified Access Gateway interno no pod. Essas conexões iriam para essa configuração de gateway no cenário de intermediação de pod único.
Em uma configuração em que você tem a intermediação de pod único e o Workspace ONE Access integrado ao pod, normalmente os usuários finais são conectados por meio do Workspace ONE Access. Nesse cenário, você deve configurar o Workspace ONE Access e o Workspace ONE Access Connector apontando diretamente para o pod. Os usuários finais estão se conectando aos recursos provisionados pelo pod usando o Workspace ONE Access. Para essa configuração, você carrega um certificado SSL para as VMs do gerenciador de pods usando a página de resumo do pod no console, conforme descrito no Guia de Administração do VMware Horizon Cloud Service. Depois, conclua as etapas para integrar o Workspace ONE Access ao pod.
Tabela 5. Portas e protocolos de conexões externas de usuários finais quando a configuração do pod tem instâncias externas do Unified Access Gateway
Origem Destino Porta Protocolo Finalidade
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 443 TCP Tráfego de autenticação de login. Também pode executar o tráfego de redirecionamento de unidade do cliente (CDR), redirecionamento USB, de redirecionamento de multimídia (MMR) e de RDP encapsulado.

O SSL (acesso HTTPS) está ativado por padrão para conexões de clientes. A porta 80 (acesso HTTP) pode ser usada em alguns casos.

Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 4172 TCP

UDP

PCoIP por meio do Gateway Seguro PCoIP no Unified Access Gateway
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 8443 ou 443, dependendo do que está definido na sua implantação TCP Blast Extreme por meio do Gateway Seguro do Blast no Unified Access Gateway para o tráfego de dados do Horizon Client. Para um pod do Horizon Cloud, essa porta é selecionada usando o menu Porta TCP Blast Extreme no assistente de implantação. Certifique-se de que a sua rede permita aos clientes o acesso de saída para o que você especificou no gateway externo. Essa URL é usada pelos clientes para estabelecer a sessão do Horizon Blast para as instâncias do Unified Access Gateway, por meio do balanceador de carga que fica na frente dessas instâncias.

Na versão de serviço de outubro de 2021, para novas implantações de uma configuração de gateway, o implantador fornece a capacidade de selecionar 8443 ou 443 para a porta TCP Blast Extreme que o implantador definirá na configuração do Unified Access Gateway correspondente. Anteriormente, o implantador configurava 443 por padrão sem fornecer uma opção. Se a sua configuração de gateway foi implantada antes da data da versão de serviço de outubro de 2021, essa configuração normalmente tem a porta 443 definida no campo URL Externa do Blast nas suas configurações de administração do Unified Access Gateway.

Observação: A porta 8443 é preferida porque é mais eficiente, fornece melhor desempenho e usa menos recursos nas instâncias do Unified Access Gateway. A porta 443 é menos eficiente e tem menor desempenho. Usar a porta 443 resultará no congestionamento da CPU nas instâncias. A porta 443 seria usada na sua implantação somente se a sua organização tivesse definido restrições do lado do cliente, por exemplo, a sua organização só permite a saída 443 e não a 8443.
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 443 UDP Blast Extreme por meio do Unified Access Gateway para tráfego de dados.
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 8443 UDP Blast Extreme por meio do Gateway do Blast Secure no Unified Access Gateway para tráfego de dados (transporte adaptativo).
Navegador Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 443 TCP Tráfego de autenticação de login. Também pode executar o tráfego de redirecionamento de unidade do cliente (CDR), redirecionamento USB, de redirecionamento de multimídia (MMR) e de RDP encapsulado.

O SSL (acesso HTTPS) está ativado por padrão para conexões de clientes. A porta 80 (acesso HTTP) pode ser usada em alguns casos.

Navegador Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 8443 ou 443, dependendo do que foi definido na sua implantação TCP Blast Extreme por meio do Gateway Seguro do Blast no Unified Access Gateway para o tráfego de dados do cliente do Horizon HTML Access (cliente web). Para um pod do Horizon Cloud, essa porta é selecionada usando o menu Porta TCP Blast Extreme no assistente de implantação. Certifique-se de que a sua rede permita aos clientes o acesso de saída para o que você especificou no gateway externo. Essa URL é usada pelo cliente do Horizon HTML Access no navegador para estabelecer a sessão do Horizon Blast com as instâncias do Unified Access Gateway, por meio do balanceador de carga que fica na frente dessas instâncias.

Na versão de serviço de outubro de 2021, para novas implantações de uma configuração de gateway, o implantador fornece a capacidade de selecionar 8443 ou 443 para a porta TCP Blast Extreme que o implantador definirá na configuração do Unified Access Gateway correspondente. Anteriormente, o implantador configurava 443 por padrão sem fornecer uma opção. Se a sua configuração de gateway foi implantada antes da data da versão de serviço de outubro de 2021, essa configuração normalmente tem a porta 443 definida no campo URL Externa do Blast nas suas configurações de administração do Unified Access Gateway.

Observação: A porta 8443 é preferida porque é mais eficiente, fornece melhor desempenho e usa menos recursos nas instâncias do Unified Access Gateway. A porta 443 é menos eficiente e tem menor desempenho. Usar a porta 443 resultará no congestionamento da CPU nas instâncias. A porta 443 seria usada na sua implantação somente se a sua organização tivesse definido restrições do lado do cliente, por exemplo, a sua organização só permite a saída 443 e não a 8443.
Tabela 6. Portas e protocolos de conexões internas de usuários finais quando a configuração do pod tem instâncias internas do Unified Access Gateway
Origem Destino Porta Protocolo Finalidade
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 443 TCP Tráfego de autenticação de login. Também pode executar o tráfego de redirecionamento de unidade do cliente (CDR), redirecionamento USB, de redirecionamento de multimídia (MMR) e de RDP encapsulado.

O SSL (acesso HTTPS) está ativado por padrão para conexões de clientes. A porta 80 (acesso HTTP) pode ser usada em alguns casos. Consulte o tópico Entendendo o que é o redirecionamento de conteúdo da URL no Guia de administração do VMware Horizon Cloud Service.

Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 4172 TCP

UDP

PCoIP por meio do Gateway Seguro PCoIP no Unified Access Gateway
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 8443 ou 443, dependendo do que foi definido na sua implantação TCP Blast Extreme por meio do Gateway Seguro do Blast no Unified Access Gateway para o tráfego de dados do Horizon Client. Para um pod do Horizon Cloud, essa porta é selecionada usando o menu Porta TCP Blast Extreme no assistente de implantação. Certifique-se de que a sua rede permita aos clientes o acesso de saída para o que você especificou no gateway externo. Essa URL é usada pelos clientes para estabelecer a sessão do Horizon Blast para as instâncias do Unified Access Gateway, por meio do balanceador de carga que fica na frente dessas instâncias.

Na versão de serviço de outubro de 2021, para novas implantações de uma configuração de gateway, o implantador fornece a capacidade de selecionar 8443 ou 443 para a porta TCP Blast Extreme que o implantador definirá na configuração do Unified Access Gateway correspondente. Anteriormente, o implantador configurava 443 por padrão sem fornecer uma opção. Se a sua configuração de gateway foi implantada antes da data da versão de serviço de outubro de 2021, essa configuração normalmente tem a porta 443 definida no campo URL Externa do Blast nas suas configurações de administração do Unified Access Gateway.

Observação: A porta 8443 é preferida porque é mais eficiente, fornece melhor desempenho e usa menos recursos nas instâncias do Unified Access Gateway. A porta 443 é menos eficiente e tem menor desempenho. Usar a porta 443 resultará no congestionamento da CPU nas instâncias. A porta 443 seria usada na sua implantação somente se a sua organização tivesse definido restrições do lado do cliente, por exemplo, a sua organização só permite a saída 443 e não a 8443.
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 443 UDP Blast Extreme por meio do Unified Access Gateway para tráfego de dados.
Horizon Client Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 8443 UDP Blast Extreme por meio do Gateway do Blast Secure no Unified Access Gateway para tráfego de dados (transporte adaptativo).
Navegador Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 443 TCP Tráfego de autenticação de login. Também pode executar o tráfego de redirecionamento de unidade do cliente (CDR), redirecionamento USB, de redirecionamento de multimídia (MMR) e de RDP encapsulado.

O SSL (acesso HTTPS) está ativado por padrão para conexões de clientes. A porta 80 (acesso HTTP) pode ser usada em alguns casos.

Navegador Balanceador de carga do Microsoft Azure para essas instâncias do Unified Access Gateway 8443 ou 443, dependendo do que foi definido na sua implantação TCP Blast Extreme por meio do Gateway Seguro do Blast no Unified Access Gateway para o tráfego de dados do cliente do Horizon HTML Access (cliente web). Para um pod do Horizon Cloud, essa porta é selecionada usando o menu Porta TCP Blast Extreme no assistente de implantação. Certifique-se de que a sua rede permita aos clientes o acesso de saída para o que você especificou no gateway externo. Essa URL é usada pelo cliente do Horizon HTML Access no navegador para estabelecer a sessão do Horizon Blast com as instâncias do Unified Access Gateway, por meio do balanceador de carga que fica na frente dessas instâncias.

Na versão de serviço de outubro de 2021, para novas implantações de uma configuração de gateway, o implantador fornece a capacidade de selecionar 8443 ou 443 para a porta TCP Blast Extreme que o implantador definirá na configuração do Unified Access Gateway correspondente. Anteriormente, o implantador configurava 443 por padrão sem fornecer uma opção. Se a sua configuração de gateway foi implantada antes da data da versão de serviço de outubro de 2021, essa configuração normalmente tem a porta 443 definida no campo URL Externa do Blast nas suas configurações de administração do Unified Access Gateway.

Observação: A porta 8443 é preferida porque é mais eficiente, fornece melhor desempenho e usa menos recursos nas instâncias do Unified Access Gateway. A porta 443 é menos eficiente e tem menor desempenho. Usar a porta 443 resultará no congestionamento da CPU nas instâncias. A porta 443 seria usada na sua implantação somente se a sua organização tivesse definido restrições do lado do cliente, por exemplo, a sua organização só permite a saída 443 e não a 8443.
Tabela 7. Portas e protocolos de conexões de usuário final interno ao usar conexões diretas, como sobre VPN
Origem Destino Porta Protocolo Finalidade
Horizon Client Balanceador de carga do Microsoft Azure do pod 443 TCP Tráfego de autenticação de login. O tráfego dos clientes chega às VMs do gerenciador de pods por meio do balanceador de carga do pod.
Horizon Client Horizon Agent nas VMs RDSH de farm ou área de trabalho 4172 TCP

UDP

PCoIP
Horizon Client Horizon Agent nas VMs RDSH de farm ou área de trabalho 22443 TCP

UDP

Blast Extreme
Horizon Client Horizon Agent nas VMs RDSH de farm ou área de trabalho 32111 TCP Redirecionamento USB
Horizon Client Horizon Agent nas VMs RDSH de farm ou área de trabalho 9427 TCP Redirecionamento de unidade do cliente (CDR) e redirecionamento de multimídia (MMR)
Navegador Horizon Agent nas VMs RDSH de farm ou área de trabalho 443 TCP HTML Access

Requisitos de portas e protocolos para o tráfego de agentes instalados na VM base, nas VMs de área de trabalho VDI e nas VMs RDSH de farm

As portas a seguir devem permitir o tráfego entre o software relacionado ao agente instalado nas VMs base, nas VMs de área de trabalho e nas VMs RDSH do farm e as VMs do gerenciador de pods.

Origem Destino Porta Protocolo Finalidade
Horizon Agent na VM base importada, nas golden images, nas VMs de área de trabalho e de RDSH do farm VM do gerenciador de pods 4001 TCP O Java Message Service (JMS, não SSL), usado pelo agente na VM para se comunicar com o pod como parte da verificação de impressão digital do certificado e da troca para proteger uma conexão SSL com o pod. Depois que as chaves são negociadas e trocadas entre a VM e o gerenciador de pods, o agente usa a porta 4002 para criar uma conexão SSL segura. Por exemplo, a ação Redefinir o Emparelhamento do Agente na página VMs Importadas requer a comunicação pela porta 4001 para o fluxo de trabalho de emparelhamento do agente entre a VM base importada e o pod.
Observação: Ambas as portas 4001 e 4002 são necessárias para operações de estado estável. Há ocasiões em que o agente pode precisar de uma nova chave com o pod, portanto a porta 4001 deve ser mantida aberta.
Horizon Agent na VM base importada, nas golden images, nas VMs de área de trabalho e nas VMs RDSH do farm VM do gerenciador de pods 4002 TCP O Java Message Service (JMS, SSL) usado pelo agente nessas VMs para se comunicar com o pod usando uma conexão SSL segura.
Horizon Agent nas VMs de área de trabalho ou de RDSH de farm Nome do host scapi.vmware.com do VMware Cloud Services 443 TCP Usado para o programa VMware Service Usage Data. Saída da sub-rede do tenant, tráfego do Horizon Agent enviado para o nome do host scapi.vmware.com do VMware Cloud Services.
Agente do FlexEngine (o agente do VMware Dynamic Environment Manager) nas VMs de área de trabalho ou RDSH de farm Esses compartilhamentos de arquivos que você configura para uso pelo agente do FlexEngine que é executado nas VMs de área de trabalho ou RDSH de farm 445 TCP O acesso do agente do FlexEngine a seus compartilhamentos de arquivos SMB, se você estiver usando recursos do VMware Dynamic Environment Manager.

Portas e protocolos exigidos pelos recursos do App Volumes

Conforme declarado em Aplicativos do App Volumes para Horizon Cloud on Microsoft Azure: visão geral e pré-requisitos, para dar suporte ao uso dos recursos do App Volumes que são compatíveis para uso com um pod do Horizon Cloud, você deve configurar a porta 445 para o tráfego de protocolo TCP na sub-rede do tenant do pod. A porta 445 é a porta SMB padrão para acessar um compartilhamento de arquivos SMB no Microsoft Windows. Os AppStacks são armazenados em um compartilhamento de arquivos SMB localizado no mesmo grupo de recursos referente às VMs do gerenciador de pods.

Além disso, conforme descrito em Tenants de primeira geração: Implantações do Horizon Cloud on Microsoft Azure: requisitos de resolução de nomes de host e nomes DNS, quando o Azure Cloud provisiona esse compartilhamento de arquivos SMB, o Azure Cloud atribui um nome de domínio completo (FQDN) no padrão *.file.core.windows.net, em que * é o nome gerado pelo Azure da conta de armazenamento do compartilhamento de arquivos SMB. Esse FQDN deve ser resolvido pelo seu servidor DNS para que o App Volumes possa acessar e montar esses compartilhamentos de arquivos e recuperar os AppStacks. Você deve garantir que o seu servidor DNS resolva esse FQDN em todos os momentos para os processos do App Volumes Manager que são executados dentro das instâncias do gerenciador de pods e para o App Volumes Agent que é executado nos desktops do VDI.

Importante: Se pretende integrar seu pod do Horizon Cloud e o NSX Cloud versão 3.1.1 e posterior e deseja usar atribuições do App Volumes, você deve abrir manualmente essa porta 445/TCP para a sub-rede de tenant do pod nas regras do NSX Firewall depois de implantar o PCG do NSX e antes de criar sua primeira atribuição do App Volumes usando esse pod.
Tabela 8. Requisitos de porta para o App Volumes
Origem Destino Porta Protocolo Finalidade
App Volumes Agent na VM base importada, nas golden images, nas VMs de área de trabalho e nas VMs RDSH do farm Compartilhamento de arquivos SMB no grupo de recursos do gerenciador de pods 445 TCP Na sub-rede de tenant do pod, para acesso aos App Volumes AppStacks armazenados no compartilhamento de arquivos SMB.

Integração com o Workspace ONE Assist for Horizon - DNS, Portas e Requisitos de Protocolo

Workspace ONE Assist for Horizon é um produto na linha de produtos do Workspace ONE UEM. A partir da versão Horizon Cloud de agosto de 2021, quando requisitos específicos forem atendidos, você poderá integrar o uso desse produto a áreas de trabalho VDI provisionadas por meio dos pods de seu tenant do Horizon Cloud. Para obter detalhes completos sobre os requisitos, consulte o guia do VMware Workspace ONE Assist for Horizon localizado na área de Documentação do VMware Workspace ONE Assist.

O uso dos recursos de assistência requer comunicação de saída entre as VMs de área de trabalho VDI e o servidor Workspace ONE Assist que oferece suporte à integração com seu tenant Horizon Cloud.

Requisitos de DNS
Verifique se o nome DNS de seu servidor Workspace ONE Assist é solucionável e acessível pelas sub-redes de tenant do pod nas quais as VMs de área de trabalho VDI residirão. O guia do VMware Workspace ONE Assist for Horizon mencionado anteriormente fornece os nomes DNS dos servidores do Workspace ONE Assist.
Requisitos de Portas e Protocolos
O tráfego de saída que usa a porta 443, TCP e HTTPS deve ser permitido das VMs de área de trabalho VDI nas quais o aplicativo Workspace ONE Assist for Horizon está instalado.

Quando necessário para uma solicitação de suporte ativo, portas e protocolos de jumpbox temporários

Se você fizer uma solicitação de suporte à VMware e a equipe de suporte determinar que a maneira de se usar essa solicitação é implantar uma VM de jumpbox temporária para comunicação SSH com os dispositivos gerenciados pela VMware, essa jumpbox exigirá as portas e os protocolos descritos aqui.

Uma permissão será solicitada a você para uma implantação de jumpbox relacionada ao suporte. A equipe de suporte da VMware informará você sobre os requisitos de comunicação, conforme apropriado para qualquer situação de suporte.

Essa VM de jumpbox relacionada ao suporte foi projetada para se comunicar como uma origem dos destinos a seguir.

  • A porta 22 das VMs do gerenciador de pods do pod usando SSH e a porta 22.
  • A porta 9443 das VMs do Unified Access Gateway usando HTTPS.
  • A porta 22 da VM do conector do gateway usando SSH em uma implantação em que o gateway externo é implantado na própria VNet.

A natureza da solicitação de suporte e dos dispositivos usados na implantação determinam quais dispositivos ou dispositivos gerenciados pela VMware específicos devem ser permitidos como o destino para a comunicação.

Tabela 9. Portas e protocolos de jumpbox relacionados ao suporte
Origem Destino Portas Protocolo Finalidade
VM de jumpbox
  • VMs do gerenciador de pods
  • VM do conector do gateway
22 SSH O Suporte da VMware exige essa comunicação com um ou mais dos dispositivos listados para atender à sua solicitação de suporte, a VM de jumpbox se comunicará pela sub-rede de gerenciamento com a porta 22 no dispositivo de destino.
VM de jumpbox VMs do Unified Access Gateway 9443 HTTPS Se o Suporte da VMware exigir essa comunicação para atender à sua solicitação de suporte, a VM de jumpbox se comunicará pela sub-rede de gerenciamento para definir as configurações na configuração de extensões do Unified Access Gateway.

Como essas VMs recebem endereços IP dinamicamente, as seguintes regras de rede podem fornecer as comunicações descritas. Todas as atividades de solicitação de suporte, sempre procure orientação e supervisão do Suporte da VMware para requisitos para a implementação de jumpbox relacionada ao suporte.

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

True SSO, Gerenciamento de certificados e implantações do Horizon Cloud on Microsoft Azure

As VMs de área de trabalho provisionadas pelo pod do Horizon Cloud não se comunicam diretamente com o Servidor de Registro. A VM do gerenciador de pods ativo da implantação do Horizon Cloud on Microsoft Azure retransmite as solicitações de certificado para o Servidor de Registro. Quando o certificado é obtido, o Horizon Agent nas VMs de área de trabalho usa esse certificado para executar a operação de Logon de Certificado em nome do usuário da área de trabalho.

A arquitetura de request-response é a mesma para uma VM de gerenciador de pods de uma implantação do Horizon Cloud on Microsoft Azure e do Horizon Connection Server de uma implantação do Horizon. Em uma implantação do Horizon Cloud on Microsoft Azure, as VMs do gerenciador de pods têm conexões com as VMs de área de trabalho na sub-rede da VM primária (também chamada de sub-rede do tenant) e em quaisquer sub-redes de VM adicionais que o administrador VDI possa ter adicionado usando o fluxo de trabalho Editar Pod.

Duas classes de certificado serão validadas por vários componentes: certificados de usuário e certificados de canal. O True SSO adiciona um certificado de usuário que é validado pelo servidor de autenticação. Neste caso de uma implantação do Horizon Cloud on Microsoft Azure, esse servidor de autenticação é um servidor Microsoft Active Directory. Como a arquitetura da Microsoft determina quais números de porta podem ser usados para esta validação de certificado, uma grande variedade de números de porta pode ser usada para essa validação, pois as portas fazem parte da arquitetura da Microsoft e não são específicas para a própria implantação do Horizon Cloud on Microsoft Azure.

Usando o True SSO em uma implantação do Horizon Cloud on Microsoft Azure, o Horizon Agent gera uma CSR e a envia para a VM do gerenciador de pods ativo da implantação por meio do canal de comunicação já em vigor entre essa VM do gerenciador de pods e esse Horizon Agent. A VM do gerenciador de pods retransmite a solicitação para o Servidor de Registro por meio de um canal TCP criptografado por SSL seguro (porta 32111 ou a porta configurada pelo cliente na instalação do Servidor de Registro). O Servidor de Registro gera uma solicitação do CMC, anexa a CSR e o nome de usuário conforme fornecido pelo Gerenciador de Pods, assina o CMC usando o Certificado do Agente de Inscrição e o envia à Autoridade de Certificação usando o protocolo MS-DCOM (RPC).

O Horizon Agent recebe o certificado, serializa-o como uma credencial de login e o envia para o processo de login do Windows. O componente do Windows LSASS recebe o certificado, o valida (verifica se ele é válido e confiável e se a máquina local contém a chave privada do certificado) e a envia para um Controlador de Domínio (DC). O DC pode optar por verificar a CRL conforme especificado no certificado do usuário.

Diagramas de rede visualmente ricos

Para obter uma representação visualmente rica das relações entre estes componentes, portas e protocolos, consulte os diagramas de rede e as descrições da VMware Digital Workspace Tech Zone em https://techzone.vmware.com/resource/vmware-horizon-cloud-service-microsoft-azure-network-ports-diagrams.