Planear, implementar e operar o Sophos ZTNA Gateway

Um Sophos ZTNA Gateway liga utilizadores autorizados a aplicações internas. Existem três formas suportadas de o implementar: uma VM de gateway local em VMware ESXi ou Microsoft Hyper-V, uma VM Sophos Cloud Gateway num destes hipervisores ou um Sophos Cloud Gateway numa Sophos Firewall gerida centralmente. Este guia acompanha o processo desde a escolha até à aceitação e ao recuo seguro. Para decidir previamente entre ZTNA e acesso remoto clássico, consulte Sophos Connect ou SSL VPN: qual a solução de acesso remoto adequada? e Zero Trust explicado de forma simples: ZTNA em vez de VPN clássico.

A interface atual chama-se Sophos Fusion; textos de ajuda e algumas imagens mais antigos ainda usam Sophos Central. Em caso de divergência com uma imagem, prevalecem os caminhos e nomes de campos atuais indicados aqui por extenso.

Objetivo e resposta direta

Escolha o tipo de gateway pelo percurso dos dados e pela responsabilidade operacional, não pelo número de cliques:

Uma VM pode ser implementada com uma interface ou duas interfaces. Com uma interface, a interface externa transporta o tráfego de entrada e saída, minimizando as alterações à infraestrutura. Com duas interfaces, separam-se as interfaces externa e interna, são necessárias duas placas de rede e, eventualmente, rotas estáticas; segundo o fabricante, esta variante oferece a melhor segurança e o melhor débito. O guia separado Publicar um servidor com DNAT em Sophos Firewall explica a função de firewall subjacente; os requisitos de portas específicos de ZTNA encontram-se abaixo.

Requisitos, licença e funções

Licença e funções administrativas

• É necessária a licença adequada para as funcionalidades ZTNA. As notas de versão do gateway assinalam expressamente as funcionalidades dependentes de licença.
• O Sophos Fusion Firewall Management exige uma subscrição paga além da licença base da firewall.
• Para registar uma firewall no Sophos Fusion, é necessário um Central Super Admin. Em alternativa, este administrador pode gerar um OTP a partir do número de série da firewall e entregá-lo ao administrador da firewall; o OTP é válido durante 14 dias.
• Os grupos de utilizadores atribuídos têm de estar sincronizados no Sophos Fusion. Os serviços de diretório suportados são Microsoft Entra ID ou Active Directory. Como fornecedores de identidade, estão documentados Microsoft Entra ID, Okta e Active Directory local.
• Os grupos do Entra ID têm de ter a segurança ativada. Nos grupos criados diretamente no Entra ID, isso acontece automaticamente; os grupos importados do AD ou criados no portal Microsoft 365 podem não ter esta definição.

A documentação do gateway analisada não especifica uma função administrativa ZTNA mais granular. Se a conta não mostrar os menus ou as ações descritos, não amplie as permissões por tentativa e erro: peça a um administrador autorizado do Sophos Fusion que verifique a atribuição de funções específica do tenant.

Certificado

O gateway exige um certificado wildcard. São suportados certificados da Let’s Encrypt ou de uma autoridade de certificação fidedigna:

• RSA com pelo menos 2048 bits;
• ECDSA, mas não com P-384 nem P-521.

Na implementação em VM, é suportado um único certificado wildcard. Tenha o certificado e a chave privada disponíveis. Pode carregá-los nos detalhes do gateway, em Zertifikat; em alternativa, o Sophos Fusion pode gerar aí um certificado Let’s Encrypt.

O procedimento de obtenção encontra-se em Criar um certificado wildcard Let’s Encrypt. Para certificados geridos diretamente na Sophos Firewall, consulte o procedimento separado Gerir certificados Let’s Encrypt na Sophos Firewall.

Host, hora e capacidade

Recomendam-se SSDs para um desempenho de E/S do disco mais estável. A data e a hora do host têm de estar corretas; o fuso horário tem de ser UTC. O gateway usa a hora do host e pode não funcionar corretamente se esta estiver errada.

Rede, IPv4 e destinos permitidos

• Não utilize 10.42.0.0/16, 10.43.0.0/16 nem 10.108.0.0/16 para o gateway. Estas redes estão reservadas a serviços internos.
• IPv6 não é suportado para gateways. Neste cenário, não atribua endereços IPv6 por DHCP ao gateway nem aos endpoints. Nos endpoints já configurados, é necessário desativar IPv6 manualmente.
• Utilize um endereço IPv4 estático ou uma reserva DHCP. O gateway não consegue lidar com uma alteração posterior do seu endereço IP.
• Se os utilizadores acederem a recursos ZTNA a partir da mesma rede do gateway, uma regra SNAT do tipo MASQ evita o encaminhamento assimétrico.
• Se houver vários nós de gateway, todos têm de estar na mesma sub-rede e apresentar uma latência muito baixa entre si.

Para um gateway local atrás de uma firewall, os seguintes destinos têm de estar acessíveis, normalmente por TCP 443:

• sophos.jfrog.io
• jfrog-prod-use1-shared-virginia-main.s3.amazonaws.com
• *.amazonaws.com
• production.cloudflare.docker.com
• *.docker.io
• *.sophos.com
• login.microsoftonline.com
• graph.microsoft.com
• sentry.io
• *.okta.com, se o fornecedor de identidade for Okta
• wsserver-<Gateway-FQDN>
• o FQDN do gateway configurado nas definições do gateway

Além disso, ztna.apu.sophos.com requer TCP 22. Se uma firewall a montante desencriptar TLS, exclua wsserver-<Gateway-FQDN> dessa desencriptação.

O ZTNA controla aplicações web e aplicações locais. As aplicações locais exigem o agente ZTNA. Não são suportadas aplicações com atribuição dinâmica de portas ou um número muito elevado de portas, como alguns produtos VoIP antigos. O agente está documentado para Windows 10 1803 ou posterior e macOS Big Sur 11 ou posterior.

Configuração com valores de exemplo adaptáveis

Utilize os seus próprios valores. Os nomes seguintes servem apenas para mostrar a correspondência:

Caminhos atuais na interface

Os textos de ajuda atuais em alemão indicam estes caminhos e ações:

• Meine Produkte > ZTNA > Gateways e depois Gateway hinzufügen
• Meine Produkte > ZTNA > Einstellungen > Domänen
• Geräte > Installer

1. Implementar a imagem da VM

Para ESXi:

1. Abra Geräte > Installer, procure Zero Trust Network Access e transfira a imagem do gateway.
2. Aceite o contrato de licença e, se aplicável, os formulários de conformidade de exportação.
3. Implemente a OVA no vSphere através de OVF-Vorlage bereitstellen.
4. Desative o arranque automático. A VM não pode arrancar sem a ISO gerada mais adiante.

Para Hyper-V:

1. Abra Geräte > Installer > Zero Trust Network Access e transfira a Gateway-VM-Image für Hyper-V.
2. Extraia o ficheiro VHDX. Cada VHDX só pode ser usado numa VM; faça cópias para as restantes VMs.
3. Crie uma VM de geração 1 com pelo menos 4096 MB de memória de arranque e dois processadores virtuais. Associe-lhe o VHDX existente.
4. Para uma implementação com duas interfaces, adicione um segundo adaptador de rede. Se usar VLANs, atribua os respetivos IDs de VLAN.

2A. Criar um gateway local

1. Abra Meine Produkte > ZTNA > Gateways > Gateway hinzufügen.
2. Em Gateway-Modus, selecione Lokal.
3. Introduza o Gateway-Name, o Gateway-FQDN e a Domäne für Ressourcen.
4. Em Plattformtyp, selecione VMware ESXi ou Hyper-V, conforme o host.
5. Em Bereitstellungsmodus, selecione Einarmig ou Zweiarmig.
6. Configure as interfaces. Com DHCP, é obrigatória uma reserva. Com Statische IP, indique o endereço IP, a sub-rede e o servidor DNS. Se uma implementação com duas interfaces tiver de alcançar aplicações em várias redes internas, configure Statische Routen.
7. Carregue o certificado wildcard.
8. Clique em Speichern und Datei erstellen. O estado inicial é Warten auf Bereitstellung; é gerada a ISO de arranque específica.
9. Na firewall, abra apenas TCP 80 e 443 para tráfego de entrada, crie DNAT para ambas as portas com destino ao IP externo do gateway ou à VIP do cluster e bloqueie todas as outras portas de entrada. Não utilize um proxy inverso.

2B. Criar um Sophos Cloud Gateway como VM

1. Comece por validar o domínio em Meine Produkte > ZTNA > Einstellungen > Domänen > Domäne hinzufügen.
2. O Sophos Fusion gera um CNAME, por exemplo 5ccdee2b04764c75ac252a0f91f161b7.cert.prod.ztna.access.sophos.com. Publique no seu fornecedor de DNS exatamente o valor gerado para o seu tenant.
3. Aguarde a propagação do DNS e clique em Validieren, em Einstellungen > Domänen. Só avance quando o estado for validiert.
4. Clique em Gateway hinzufügen, selecione Sophos Cloud em Gateway-Modus e introduza o Gateway-Name e o Gateway-FQDN. O FQDN do gateway tem de coincidir com o valor indicado no registo da aplicação ZTNA.
5. Selecione a Domäne validada, o Plattformtyp adequado, o Identitätsanbieter e, em Points of Presence, a região mais próxima do centro de dados.
6. Selecione Einarmig ou Zweiarmig, configure as interfaces com endereços reservados ou estáticos e, se necessário, rotas estáticas. Carregue o certificado wildcard.
7. Clique em Speichern und Datei erstellen. Copie o domínio de alias gerado na caixa de diálogo Gateway hinzugefügt e publique-o no DNS público como CNAME do FQDN do gateway.
8. Abra apenas TCP 443 para tráfego de saída na interface externa. Neste modelo, não se configura a publicação da VM por DNAT de entrada.

Desde o ZTNA 2.1, está configurado por predefinição um ponto de acesso secundário próximo do PoP primário. Pode desativá-lo em Einstellungen. Ainda assim, escolha um PoP primário próximo do centro de dados.

2C. Criar um Sophos Cloud Gateway em Sophos Firewall

1. Confirme que utiliza SFOS 19.5 MR3 ou superior e que a firewall é gerida centralmente no Sophos Fusion. Se ainda não estiver registada, utilize Register na firewall com as credenciais de Super Admin ou com o OTP gerado pelo Super Admin.
2. Valide o domínio como em 2B.
3. Abra Meine Produkte > ZTNA > Gateways > Gateway hinzufügen e selecione Gateway-Modus: Sophos Cloud.
4. Introduza o Gateway-Name e o Gateway-FQDN, selecione a Domäne validada e defina Plattformtyp como Firewall.
5. Em Firewall, selecione o dispositivo SFOS. A lista apresenta apenas firewalls geridas centralmente a partir da versão 19.5 MR3. Num par HA, pode selecionar a firewall ativa; assim, o tráfego e os serviços podem ser assumidos após um failover.
6. Selecione Identitätsanbieter e Points of Presence, carregue o certificado e clique em Speichern. O gateway deverá ficar ativo após cerca de cinco minutos.
7. Adicione ao fornecedor de identidade o URL de redirecionamento específico https://<externer-Gateway-FQDN>/ztna-oauth2/callback.

Limitações desta variante:

• Numa implementação HA ativo-ativo, o portal de administração web da firewall não é acessível por ZTNA.
• O portal do utilizador e o portal VPN da firewall não são suportados através do gateway ZTNA.
• Nos restantes casos, o portal de administração web pode ser criado como recurso do tipo Webadmin-Portal. No acesso sem agente, o domínio de alias gerado é publicado como CNAME público; no acesso com agente, este interceta o FQDN externo.

3. Opcionalmente, criar um cluster de VMs

Crie o cluster antes de transferir as ISOs de arranque:

1. Abra o novo gateway e clique em Instanzen hinzufügen/bearbeiten > Eine weitere Instanz hinzufügen. A formação do cluster é ativada automaticamente.
2. Introduza um IP virtual de cluster ainda não utilizado, na mesma gama de IP das instâncias. Numa implementação com duas interfaces e balanceador de carga externo, deixe a VIP externa do cluster em branco.
3. Introduza o nome da VM e o IP da interface; numa implementação com duas interfaces, indique os IPs interno e externo.
4. Repita o processo até ter pelo menos três instâncias. São suportadas entre três e nove instâncias, sempre em número ímpar.
5. Configure o DNAT de um gateway local para a VIP externa do cluster. Pelo menos metade dos nós tem de permanecer ativa.

4. Associar a ISO de arranque e aprovar o registo

Cada ISO está associada de forma única a um gateway ou instância e não pode ser reutilizada.

• ESXi: monte a ISO na unidade de CD/DVD e selecione Verbinden e Beim Einschalten verbinden. Pode remover um dispositivo série existente.
• Hyper-V: nas definições da VM, selecione IDE Controller 1 > Image-Datei na unidade de DVD e monte a ISO.
• Só depois inicie a VM. A ISO tem de permanecer associada mesmo após um arranque bem-sucedido.
• Abra os detalhes do gateway. O estado passa de Warten auf Bereitstellung para Warte auf Genehmigung ou Warten auf Gateway-Genehmigung.
• Clique em Genehmigen. Num cluster, aprove apenas a primeira instância; as seguintes são geridas posteriormente.
• A aprovação pode demorar até dez minutos. Confirme o estado final específico da plataforma: local em ESXi Verbunden, local em Hyper-V Aktiv, Sophos Cloud em ESXi Aktiv e Verbunden, Sophos Cloud em Hyper-V Aktiv.

Verificar corretamente o DNS e o percurso dos dados

Os servidores DNS públicos e privados desempenham funções diferentes:

Gateway local

• Com agente: O agente interceta o pedido para a aplicação privada e atribui-lhe um endereço da gama 100.64.x.x. Para estabelecer o túnel, resolve o FQDN do gateway através de um registo A público para o IP do gateway. Em seguida, o gateway resolve o FQDN da aplicação através do servidor DNS privado.
• Sem agente: Um CNAME público da aplicação aponta para o FQDN do gateway; o respetivo registo A público aponta para o IP do gateway. O gateway consulta o servidor DNS privado para obter o destino interno da aplicação.

Sophos Cloud Gateway

• Com agente: O DNS público resolve a aplicação privada para o domínio de alias associado. Este encaminha o tráfego pelo PoP da Sophos Cloud até ao gateway. Depois, o gateway resolve o destino interno através do DNS privado.
• Sem agente: O CNAME público do recurso aponta para o domínio de alias gerado pela Sophos. Para cada novo recurso sem agente, o gateway inicia um novo túnel TCP 443 para o PoP. O PoP associa o pedido ao gateway através do alias.

A ligação entre o agente e o gateway ou PoP utiliza TLS mútuo. Estão documentados TLS 1.2 e posterior e protocolos de cifragem com comprimentos de chave até 256 bits.

O agente ZTNA altera o adaptador TAP predefinido. Por isso, o nslookup pode aparentar falhar para nomes fora do ZTNA. Indique explicitamente o servidor DNS efetivamente responsável:

nslookup <FQDN> <DNS-Server>

Validação e resultado esperado

Não aceite a implementação apenas porque o estado do gateway está a verde. Utilize um utilizador de teste com acesso limitado e exatamente um recurso de teste.

1. Gestão: Em Meine Produkte > ZTNA > Gateways, o gateway está Aktiv ou Verbunden. Em Gateway-Details, confirme a versão do software e, no caso de clusters, todos os nós.
2. DNS público: Para o gateway local, o registo A do gateway e, se aplicável, o CNAME do recurso devolvem o IP público previsto. Para o Cloud Gateway, os CNAMEs de validação do domínio, do gateway e dos recursos correspondem exatamente aos valores gerados pela Sophos.
3. DNS privado: O gateway consegue resolver o FQDN do recurso interno para o IP do servidor interno.
4. Certificado: O FQDN, o âmbito do wildcard, a cadeia, o prazo de validade e a chave privada são adequados. O browser ou o agente não apresentam avisos de confiança.
5. Rede: No gateway local, TCP 80 e 443 atingem as regras DNAT previstas; as outras portas de entrada estão bloqueadas. No Cloud Gateway, o túnel TCP 443 de saída funciona sem publicação de entrada.
6. Acesso: O utilizador-piloto autorizado acede apenas à aplicação atribuída. Um utilizador de teste não autorizado não consegue aceder.
7. Aplicação: Verifique não apenas o início de sessão, mas também uma transação real e limitada. O caminho de retorno funciona e a aplicação vê a origem de ligação esperada.
8. Estabilidade: Teste a partir do exterior e, se estiver previsto, da mesma rede do gateway. O segundo teste confirma, em particular, o MASQ e o caminho de retorno.
9. Cluster: Não pare nenhum nó fora de um teste de manutenção e failover aprovado. Num teste planeado, pelo menos metade das instâncias permanece ativa e os pedidos são encaminhados pelos restantes nós.

Se o resultado esperado não for obtido, avance para o sintoma correspondente abaixo. Não altere simultaneamente o DNS, o certificado, o NAT e a política.

Para analisar separadamente a camada de firewall, consulte Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture e Compreender o NAT na Sophos Firewall.

Resolução de problemas por sintoma

O gateway permanece em «Warten auf Bereitstellung» ou não alcança o Sophos Fusion

1. Confirme que a ISO única está associada à VM correta e que Beim Einschalten verbinden está ativado.
2. Verifique a hora do host e o fuso horário UTC.
3. Verifique o IP estático ou a reserva DHCP, o DNS e os destinos permitidos; ztna.apu.sophos.com requer TCP 22.
4. Verifique a exceção à desencriptação TLS para wsserver-<Gateway-FQDN>.
5. Execute o diagnóstico da VM no vSphere ou no Hyper-V Manager.

O estado aguarda aprovação

Abra os detalhes do gateway e clique em Genehmigen. Aguarde até dez minutos. Num cluster, aprove apenas a primeira instância. Se o estado não mudar, verifique primeiro a conectividade e a hora, em vez de criar novas instâncias.

O gateway deixa de funcionar após uma alteração de DHCP ou da rede

O gateway não consegue processar uma alteração do seu endereço IP. Reponha a atribuição original e configure uma reserva DHCP ou um endereço estático. Em seguida, verifique o DNS, o DNAT e, nos clusters, os destinos da VIP. Uma alteração planeada de IP não é uma simples alteração em funcionamento e tem de ser tratada como uma nova implementação.

O início de sessão funciona, mas o recurso não

1. Resolva especificamente o FQDN do recurso no servidor DNS privado.
2. Verifique a rota e a permissão na firewall entre o gateway e a porta de destino documentada.
3. Numa implementação com duas interfaces, verifique as rotas estáticas para outras redes internas.
4. Se o acesso vier da mesma rede do gateway, verifique a regra MASQ e o encaminhamento assimétrico.
5. Verifique se a aplicação utiliza portas dinâmicas ou um número muito elevado de portas; estas aplicações não são suportadas.

Falha o acesso externo a um gateway local

Verifique o registo A público, TCP 80 e 443, ambas as regras DNAT e o respetivo IP de destino ou VIP do cluster. Confirme que não existe um proxy inverso à frente do gateway. As outras portas de entrada devem permanecer bloqueadas.

O Cloud Gateway ou um recurso sem agente não está acessível

Verifique pela seguinte ordem:

1. estado do domínio validiert;
2. CNAME do gateway e CNAME do recurso face aos domínios de alias gerados no Sophos Fusion;
3. TCP 443 de saída do gateway para o PoP;
4. resolução DNS privada do gateway para a aplicação;
5. região PoP correta e, para gateways na firewall, o URL de redirecionamento OAuth2 específico.

nslookup devolve resultados errados após a instalação do agente

O agente define o adaptador TAP de ZTNA como predefinido. Repita a consulta indicando explicitamente o servidor DNS. Uma falha através do adaptador TAP não demonstra que o servidor DNS habitual desconhece o nome.

Erros de certificado

Verifique o âmbito do wildcard, a cadeia completa, a chave privada e o algoritmo. ECDSA com P-384/P-521 e RSA com menos de 2048 bits não são suportados. Compare o FQDN do gateway, o domínio dos recursos e os nomes do certificado antes de carregar um novo certificado.

Pacote de diagnóstico para o Sophos Support

Para gateways VM em ESXi ou Hyper-V:

1. Abra Gateway-Details > Fehlerbehebungsprotokolle.
2. Clique em Protokolle generieren. A geração pode demorar alguns minutos.
3. Transfira a nova entrada na coluna Fehlerbehebungsprotokoll. Expira após uma hora.
4. Se necessário, ative nos detalhes do gateway o acesso temporário para suporte e envie o token apresentado exclusivamente ao Sophos Support.

Esta funcionalidade de registos não se aplica ao gateway integrado em Sophos Firewall.

Recuo seguro ou desativação

Distinga entre uma alteração de configuração, uma atualização de gateway VM, uma mudança de firmware da firewall e a eliminação definitiva. Os procedimentos de recuo não são iguais.

Antes de qualquer alteração

• Registe o modo do gateway, FQDN, IPs, VIP do cluster, plataforma, versão, certificado, CNAMEs e registos A públicos, DNAT/SNAT, rotas estáticas, recursos atribuídos e grupo-piloto.
• Identifique os recursos e utilizadores que dependem do gateway e combine uma janela de manutenção.
• No piloto, altere apenas uma camada de cada vez. Registe os últimos valores de DNS e firewall que funcionaram.

Mover recursos para um gateway na firewall

Para a migração documentada de um gateway existente para um gateway na firewall:

1. Configure completamente o gateway na firewall.
2. Adicione o novo URL de redirecionamento OAuth2 ao fornecedor de identidade.
3. Abra Ressourcen und Zugriff, selecione o recurso e defina Gateway para o gateway na firewall.
4. Para acesso sem agente, publique o novo domínio de alias da firewall como CNAME público.
5. Valide com um utilizador de acesso limitado. Só remova o valor DNS antigo ou o gateway antigo após um teste bem-sucedido da aplicação.

Eliminar o gateway

A opção Gateway löschen está disponível nos detalhes do gateway. Contudo, as fontes associadas não descrevem nem a recuperação de um gateway eliminado nem uma reversão automática e transacionalmente segura do DNS, NAT, recursos e certificados. Por isso:

1. Não use a eliminação como primeiro passo de rollback.
2. Mova ou desative primeiro os recursos dependentes na janela de alteração acordada e confirme que já não passa acesso de produção pelo gateway.
3. Depois, remova os registos DNS públicos e as regras de firewall obsoletos com base na lista previamente elaborada.
4. Só elimine o gateway após a aprovação dos responsáveis pela aplicação e pela rede.
5. Se as dependências ou o método de recuperação não forem claros, pare antes de Gateway löschen e contacte o Sophos Support.

Recuo após atualizações

As instruções analisadas não descrevem um downgrade para atualizações do gateway VM. Se uma atualização falhar, não tente repor a imagem por um método não documentado; gere os registos, mantenha o acesso através da instância não alterada ou do cluster e escale o caso para o Sophos Support.

Para um gateway integrado em Sophos Firewall, aplica-se o procedimento documentado de recuo de firmware:

1. Confirme uma subscrição de suporte válida e faça uma cópia de segurança da configuração da firewall.
2. Antes da mudança, confirme que o número de gateways configurados é suportado pela versão de destino; os gateways excedentários têm de ser eliminados antes da mudança de firmware.
3. Planeie a mudança fora das horas de maior utilização. A firewall termina as sessões e reinicia.
4. Em Backup and firmware > Firmware, pode carregar uma versão compatível e iniciá-la com Upload and boot, ou arrancar uma imagem já inativa através de Boot firmware image.
5. Os firmwares ativo e anterior encontram-se em partições separadas, cada um com a sua configuração. Por isso, um rollback para o firmware anterior também repõe a configuração no estado anterior correspondente.
6. Após o reinício, inicie sessão e verifique o firmware ativo no canto superior esquerdo do Control Center; depois, verifique o estado do gateway, o DNS e o acesso-piloto.

Operação, revisão e ciclo de vida

Atualizar o gateway VM

Em Gateways, uma marca de verificação verde junto ao número da versão indica que está disponível uma versão da VM. Clique no número da versão, selecione a versão de destino e agende a atualização ou escolha Jetzt. Se for necessário reiniciar, a interface apresenta um aviso; planeie o reinício numa janela de manutenção. Esta função aplica-se apenas a gateways ESXi e Hyper-V. Um gateway na firewall é atualizado através do firmware SFOS.

As notas de versão consultadas incluem o ZTNA 2.2 de 13 de janeiro de 2026 para ESXi e Hyper-V, tanto na implementação local como na Sophos Cloud, e classificam a atualização como obrigatória devido a novas capacidades necessárias. Antes da janela de manutenção, confirme sempre a versão de destino oferecida no Sophos Fusion e as notas de versão atuais; não deduza desta referência histórica nem uma data de EOL nem a versão de destino atual.

O histórico de versões também refere um tempo limite de inatividade configurável para os túneis entre agente e gateway e a desativação do Resource Connection Pooling a partir da versão 2.1.2. Para a versão 2.2, documenta correções para ligações intermitentes de recursos com agente através de um gateway local, um estado Updating que permanecia bloqueado após atualizações de imagem, mensagens de diagnóstico enganadoras relativas aos pods do cluster e uma condição de corrida em pods Kubernetes. Utilize este histórico para avaliar alterações e problemas, não para substituir a vista atual dos detalhes do gateway.

Revisão periódica

Verifique, pelo menos, segundo a sua periodicidade de manutenção:

• o estado do gateway e dos nós, bem como a versão instalada e a oferecida;
• o prazo de validade do certificado e a cadeia completa;
• os CNAMEs públicos de validação de domínio, gateway e recursos;
• a resolução DNS privada e as rotas, regras DNAT, SNAT e de firewall ainda necessárias;
• a região PoP, o PoP secundário e a latência real do Cloud Gateway;
• os grupos de utilizadores sincronizados e com segurança ativada, e o fornecedor de identidade;
• as atribuições de recursos ao gateway e os gateways que já não são necessários;
• os procedimentos de diagnóstico e suporte, as janelas de manutenção e as pessoas responsáveis.

Não publique afirmações sobre períodos de transição ou migração, descontinuação ou EOL sem uma comunicação de produto atual e acessível. As fontes disponíveis fundamentam a operação e o estado das versões, mas não essas datas de ciclo de vida.

Guias relacionados já existentes

Este guia termina deliberadamente nos limites do gateway. A configuração completa do serviço de diretório e do fornecedor de identidade, a instalação ou remoção do agente ZTNA, o diagnóstico de problemas específicos do agente, as regras de acesso a recursos e os desenhos especiais com vários controladores de domínio pertencem aos respetivos guias existentes. Os fundamentos sobre Zero Trust, acesso remoto, certificados, DNAT e diagnóstico de firewall ligados acima complementam o procedimento do gateway sem duplicar esses processos separados.