Agente Sophos ZTNA: resolução sistemática de problemas

Objetivo e resposta direta

O facto de um recurso ZTNA estar indisponível não significa necessariamente que o agente tenha uma avaria. A instalação, a política, o grupo de utilizadores, o DNS, o fornecedor de identidade, o gateway e a aplicação interna formam uma cadeia. Por isso, o diagnóstico deve começar pelo sintoma visível e alterar apenas a camada para a qual existam indícios.

A verificação fiável mais curta é a seguinte:

Registe o utilizador, o dispositivo, o recurso e a hora do incidente.
Verifique a instalação e o estado local do agente.
Em My Products > ZTNA (navegação completa: Sophos Central > My Products > ZTNA), compare o recurso, o método de acesso e a política.
Em ZTNA > Reports (navegação completa: Sophos Central > My Products > ZTNA > Reports), procure uma autenticação bem-sucedida ou o motivo da recusa do acesso.
Em My Environment > Alerts (navegação completa: Sophos Central > Alerts), procure um evento de instalação, atualização, licenciamento ou conectividade do dispositivo que coincida com a hora em causa.
Verifique o DNS, a identidade, o estado de funcionamento do dispositivo ou o gateway apenas se o sintoma identificado assim o indicar.

Um pedido bem-sucedido no browser não prova que tenha sido utilizado o percurso do agente. Inversamente, o ZTNA User Portal apresenta apenas aplicações sem agente; um recurso baseado em agente não tem de aparecer nesse portal.

Requisitos, licenciamento e funções

Este diagnóstico requer um utilizador afetado e um dispositivo gerido, o FQDN de um recurso afetado e acesso à configuração ZTNA, aos relatórios, à vista do dispositivo e aos alertas do tenant correto. Para testar um recurso baseado em agente, o Agente ZTNA tem de estar atribuído ao dispositivo. Em Devices > Computers ou Servers, uma marca de verificação verde indica que o componente ZTNA está instalado; um sinal de mais indica que ainda pode ser instalado.

As fontes atribuídas não especificam uma licença autónoma nem uma função de administrador concreta para este diagnóstico. Não deduza a existência de permissões mais abrangentes apenas por um menu estar visível. Se não estiver disponível uma vista ou ação necessária, envolva o administrador do tenant em vez de concluir que existe um problema de licenciamento ou de função.

Antes de efetuar qualquer alteração, registe os seguintes dados relativos a um único utilizador e dispositivo afetados:

sistema operativo, rede e hora, incluindo o fuso horário;
FQDN do recurso e método de acesso, Agent ou Agentless;
texto exato do estado ZTNA local e da mensagem do browser;
se outros recursos ZTNA funcionam no mesmo dispositivo;
se o mesmo recurso funciona para o mesmo utilizador noutra rede;
última alteração à política, ao grupo, ao DNS, ao fornecedor de identidade ou ao gateway.

Configuração com valores de exemplo adaptáveis

Não faça alterações generalizadas às definições de produção para realizar um teste limitado. Substitua valores de exemplo como <USER>, <DEVICE>, <RESOURCE-FQDN> e <TEST TIME WITH TIME ZONE> pelos valores de um único caso.

Em ZTNA > Reports, abra o separador Report Generator. Para investigar uma recusa de acesso, selecione o modelo Denied resource access, limite o período em torno de <TEST TIME WITH TIME ZONE> e, se as colunas disponíveis o permitirem, filtre por <USER>, <DEVICE> ou <RESOURCE-FQDN>. Os valores dos filtros com = e != distinguem maiúsculas de minúsculas; ~ utiliza * como caráter universal e não faz essa distinção. Quando existem vários filtros, todos têm de ser satisfeitos. Em seguida, execute o relatório com Create.

Para um início de sessão que deveria ser bem-sucedido, utilize Authenticated users. Este relatório regista os utilizadores autenticados com êxito pelos gateways ZTNA, independentemente do modo de implementação do gateway. Os modelos Gateway bandwidth e Resource bandwidth atribuem tráfego, mas não provam, por si só, que uma determinada tentativa de acesso tenha sido bem-sucedida.

Em My Environment > Alerts, limite o período e o dispositivo de modo a corresponderem ao teste. Um alerta pode agregar vários eventos recorrentes. Abra o respetivo título para ver os eventos associados e todos os detalhes. Enquanto a análise estiver em curso, não feche o alerta apenas para o retirar da lista.

Validação e resultado esperado

Um teste positivo só fica concluído quando todos os elementos seguintes são coerentes entre si:

O agente apresenta o estado esperado para o percurso testado.
<RESOURCE-FQDN> abre com o utilizador, o dispositivo e a rede pretendidos.
O relatório Authenticated users contém a autenticação bem-sucedida no período selecionado.
O relatório Denied resource access não contém uma nova recusa referente ao mesmo teste.
Em My Environment > Alerts, não existe qualquer alerta aberto de instalação, atualização, licenciamento ou conectividade que coincida com a hora do teste e ponha em causa o resultado.

Se o registo esperado não aparecer no relatório, verifique o período e a grafia dos filtros e repita o teste uma vez, alterando apenas uma variável. Se aparecer uma recusa, o respetivo motivo determina a secção a consultar em seguida. Se o segundo teste também não produzir qualquer registo útil, não tente forçar um resultado de «sucesso» através de novas alterações à configuração; preserve os registos e o SDU para encaminhar o caso.

Resolução de problemas por sintoma

Estado «Not configured»

Em Devices > Computers ou Servers, verifique se o ZTNA está instalado no dispositivo. Uma marca de verificação verde confirma que o componente está instalado; um sinal de mais disponibiliza a instalação. A presença do Sophos Endpoint, por si só, não prova que o ZTNA tenha sido atribuído.

Existe uma exceção importante no Windows. Se Don’t intercept on-premises traffic estiver configurado em Global Settings > Products and Services > ZTNA e o agente do Windows detetar a rede interna, interrompe intencionalmente a interceção nessa rede e apresenta Not Configured. Ao mudar para outra rede, é esperado que volte a apresentar Configured. Segundo a Sophos, esta funcionalidade é atualmente específica do Windows; não pressuponha um comportamento equivalente no macOS.

Este comportamento no Windows requer o Sophos Core Agent 2025.2.1.709 ou posterior. No Sophos Fusion (anteriormente designado Sophos Central), abra o dispositivo e confirme a versão instalada do Core Agent no separador Summary antes de diagnosticar a deteção da rede interna. Uma versão anterior não suporta esta exceção nos termos descritos.

Se a exceção não for aplicável, verifique no Sophos Fusion a atribuição de componentes, o estado online e o estado das atualizações. Não comece por reinstalar enquanto não souber se o ZTNA chegou a ser atribuído.

Estado «Zero Trust Network Access: Error»

Este estado indica um problema de ligação. Verifique, pela ordem indicada:

Existe uma política ZTNA e está atribuída ao recurso?
O dispositivo resolve o FQDN do gateway conforme previsto?
O Sophos Fusion apresenta um erro de instalação ou de estado de funcionamento do dispositivo?
No Windows, a configuração do Sophos TAP está presente ou foi alterada por outro software de rede?

A Sophos inclui a desativação do IPv6 como passo de diagnóstico. Não é uma correção a aplicar por defeito: faça-o apenas num dispositivo piloto, depois de registar o estado inicial, e durante um único teste de reprodução. Volte a ativar o IPv6 após o teste. Se o sintoma mudar de forma inequívoca, preserve os carimbos de data/hora e um SDU e investigue o caso com o Suporte da Sophos; não deixe o IPv6 desativado de forma permanente ou generalizada.

Um túnel pode fechar quando está inativo. Consoante a definição central, isso acontece ao fim de 5, 15 ou 30 minutos, ou de uma hora; o valor predefinido é 5 minutos. O túnel é restabelecido quando surge novo tráfego. Por conseguinte, um túnel fechado por inatividade não constitui, por si só, prova de uma falha.

A janela de início de sessão não aparece

Para um recurso baseado em agente, verifique, pela ordem indicada:

O dispositivo consegue aceder ao gateway ZTNA?
O processo do Agente ZTNA está em execução?
Existe, indevidamente, um CNAME público ou interno que encaminhe o FQDN da aplicação para o gateway? Este CNAME não pode existir para aplicações baseadas em agente.
O recurso, o método de acesso e o FQDN coincidem no Sophos Fusion?
Os registos do ZTNA apresentam um erro de SNTP, DNS ou ligação à hora do teste?

Se surgir a janela de início de sessão, mas o utilizador não regressar à aplicação, verifique o URI de redirecionamento do fornecedor de identidade. No Okta, a Groups claim expression também distingue maiúsculas de minúsculas. Reponha os cookies ou as credenciais do browser apenas depois de confirmar que a falha ocorre na própria autenticação.

Um recurso baseado em agente falha após a autenticação ou deixa de funcionar

Se a autenticação for bem-sucedida, mas uma aplicação baseada em agente não abrir, procure erros nos registos de SNTP do endpoint e confirme em heartbeat.xml que o certificado aí registado é atualmente válido. Uma hora incorreta no dispositivo, uma falha na sincronização horária ou um certificado expirado ou ainda não válido podem interromper o percurso autenticado do agente, mesmo quando a política e o DNS parecem corretos. Preserve os registos, o ficheiro e o carimbo de data/hora; não edite o XML nem contorne a validação do certificado.

Se o acesso funcionava e entretanto deixou de funcionar, efetue as mesmas verificações dos registos de SNTP e da validade do certificado em heartbeat.xml e examine o dispositivo no Sophos Fusion. Um estado Endpoint health a vermelho é uma pista de diagnóstico: corrija a causa indicada e volte a testar, em vez de tornar a política ZTNA menos restritiva.

«403 Access Denied / No Access», «Device Health» ou «Policy Off»

O relatório Denied resource access permite determinar a verificação seguinte:

403 Access Denied / No Access: o utilizador não pertence efetivamente a um grupo atribuído ao recurso ou o grupo não tem a segurança ativada no Microsoft Entra ID. Verifique a importação do grupo, o estado de segurança ativada e as permissões de API do fornecedor de identidade. As alterações aos grupos autorizados podem demorar até uma hora a produzir efeitos.
Device Health: o dispositivo não cumpre as condições de estado de funcionamento da política de agente atribuída. Resolva o problema concreto indicado, em vez de tornar a política menos restritiva de forma generalizada.
Policy Off: abra a política afetada em My Products > ZTNA > Policies e verifique Policy is enforced.
Upstream request error for Agentless: o gateway não consegue aceder à aplicação interna, a aplicação está indisponível, o respetivo FQDN/IP é resolvido incorretamente ou a porta configurada está errada. Isto não prova que o agente do endpoint tenha uma avaria.
404 Not Found for Agentless: verifique o CNAME entre a aplicação e o FQDN do gateway. Não aplique esta regra de DNS a recursos baseados em agente.

Se o utilizador tiver acabado de ser adicionado a um grupo, só deve repetir o teste depois de decorrido o intervalo de replicação documentado. Uma janela privada do browser permite excluir um estado de browser desatualizado numa aplicação Web, mas não acelera a replicação de grupos.

Falhas de DNS após a instalação

O adaptador ZTNA TAP pode tornar-se o adaptador predefinido para nslookup. Nesse caso, uma consulta relativa a um destino que não passe pelo gateway ZTNA pode falhar sem que a resolução de nomes tenha falhado em geral. Para permitir a comparação, a documentação da Sophos indica explicitamente o servidor DNS pretendido:

nslookup <FQDN> <DNS-SERVER>

Compare a resposta obtida através do resolvedor empresarial esperado e, depois, o pedido real da aplicação. Não altere por tentativa a ordem dos adaptadores, as métricas nem os endereços dos servidores DNS. Para recursos baseados em agente, confirme também que não existe um CNAME que encaminhe o FQDN da aplicação para o gateway.

O Sophos DNS Protection utiliza um percurso de dados distinto. Se também estiver a ser utilizado, consulte Configurar o Sophos DNS Protection para endpoints quanto a políticas e exclusões; não trate o DNS do ZTNA e o Endpoint DNS Protection como se fossem a mesma funcionalidade.

ZTNA em conjunto com uma VPN ou software de acesso remoto

Não elimine adaptadores TAP, não altere associações nem fixe métricas de rede como solução genérica. Comece por reproduzir o acesso ao mesmo recurso num teste controlado com e sem o outro cliente, registando a hora, a resposta de DNS e o estado ZTNA.

Para o ZTNA 2026.1 com Sophos DNS Protection, a Sophos documenta um método de coexistência específico: ativar o DNS Protection e a opção Retry with system- or application-configured DNS services when DNS Protection returns NXDOMAIN na respetiva política de endpoint. Isto requer a versão, a licença e a configuração do DNS Protection aplicáveis; não é uma solução universal para qualquer produto VPN.

Casos específicos do macOS

No macOS Sequoia, o Chrome pode bloquear aplicações atrás de um on-premises gateway após uma instalação nova apenas do ZTNA, se o browser não tiver acesso à rede local. Exclusivamente para este sintoma, verifique em System Settings > Privacy & Security > Local Network se o Google Chrome tem permissão para encontrar dispositivos locais. O Sophos Cloud Gateway não é afetado por este caso documentado. Daqui não decorre uma recomendação geral de concessão dessa permissão, nem qualquer garantia de «acesso privado» no macOS.

A utilização elevada da CPU após uma implementação por MDM pode ser causada por vários perfis VPN cujos nomes começam por Sophos ZTNA. Em System Settings > VPN, verifique se existem duplicados. Mantenha exatamente um perfil; um perfil instalado por MDM não pode ser removido localmente e, por isso, tem de ser o perfil mantido. Reinicie o Mac e volte a verificar a utilização da CPU e o acesso ZTNA. Esta limpeza aplica-se apenas a este caso confirmado no macOS, não aos adaptadores TAP do Windows.

Se tiver sido possível reproduzir explicitamente o uso de credenciais desatualizadas, os procedimentos de reposição da Sophos só podem ser utilizados para depuração ou demonstrações, e não como método habitual para terminar sessão em produção. No macOS, a ferramenta de diagnóstico do Endpoint disponibiliza ZTNA > Reset; os scripts de cookies do browser ou a remoção manual dos dados de sites do Safari têm de corresponder exatamente ao gateway e ao fornecedor de identidade. No Windows, o procedimento da Sophos exige a desativação de Tamper Protection e a execução, com privilégios elevados, do anexo da base de conhecimento clearcreds.bat. Não utilize scripts de limpeza de terceiros nem invente caminhos de eliminação manual. Os ficheiros originais e as limitações constam de Sophos ZTNA: terminar sessão no agente.

Reversão ou desativação em segurança

As fontes de diagnóstico e de relatórios atribuídas não documentam uma reparação, desinstalação ou reversão genérica do agente. Assim, o ponto em que deve parar em segurança é o seguinte:

Os filtros de teste e o Report Generator não alteram o percurso dos dados; um modelo ou agendamento guardado apenas para diagnóstico pode voltar a ser eliminado em Saved templates ou Scheduled exports.
Após um teste comparativo com IPv6, reponha imediatamente o estado inicial documentado.
Não mantenha como correção uma política temporariamente menos restritiva, um grupo alterado, uma configuração de DNS diferente ou uma verificação de certificado modificada. Se uma dessas alterações tiver sido efetuada fora deste procedimento, reponha o estado anteriormente documentado e volte a testar com o mesmo caso.
Não remova o agente, não elimine adaptadores TAP nem contorne a validação de certificados enquanto não existirem provas da localização da falha. Se não houver um procedimento de reversão documentado, pare e encaminhe o caso com as provas preservadas.

Após cada reversão, o estado do agente, a resposta de DNS, o pedido real ao recurso e o relatório ZTNA aplicável têm de voltar a corresponder ao estado inicial. Caso contrário, não efetue uma segunda alteração.

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

Os relatórios e alertas do ZTNA constituem provas operacionais, não ações de reparação. Para revisões recorrentes, guarde um modelo de relatório filtrado ou agende uma exportação. Os relatórios agendados podem ser gerados diariamente, semanalmente ou mensalmente nos formatos PDF, CSV ou HTML; o Sophos Central admite, no máximo, 200 agendamentos. As exportações geradas manual ou automaticamente são eliminadas ao fim de 90 dias. Se um relatório contiver dados pessoais, prefira uma ligação por e-mail a um ficheiro em anexo, pois a ligação exige o início de sessão no Sophos Central.

Os alertas apresentam a gravidade, o estado, os eventos e o dispositivo. Os eventos recorrentes podem ser agregados num único alerta; um evento posterior pode fechar automaticamente um alerta com o estado Resolved. Durante um incidente, leia sempre os eventos incluídos e os respetivos carimbos de data/hora. Mark as acknowledged retira um alerta da lista, mas não resolve a respetiva causa. Da mesma forma, Mark as resolved não substitui a correção técnica.

Antes de reinstalar, limpar perfis ou efetuar outras alterações à rede, recolha:

dispositivo, utilizador, sistema operativo e componentes efetivamente instalados;
recurso, método de acesso, política e grupo atribuído;
mensagem exata, estado ZTNA local e carimbo de data/hora, incluindo o fuso horário;
resultado obtido com um segundo utilizador, dispositivo ou rede, alterando apenas uma variável de cada vez;
respostas de DNS para os FQDN do recurso e do gateway;
eventos relevantes do Sophos Central e registos de ZTNA, SNTP e instalação;
relatório ZTNA filtrado ou exportação relativa ao período do teste;
um ficheiro SDU atual.

A ajuda e as versões atuais dos componentes têm precedência. Este procedimento não permite tirar conclusões sobre transições históricas do ZTNA, a retirada de direitos de utilização anteriores, prazos de migração, descontinuação ou datas exatas de fim de vida.

Guias relacionados

Para conhecer a arquitetura e as dependências, consulte Configurar o Sophos ZTNA: visão geral e sequência. Este artigo limita-se ao estado do agente e às provas de ligação; a implementação do gateway e uma alegada reparação genérica do agente estão fora do seu âmbito.

Sophos Endpoint: diagnóstico com SDU explica como efetuar a recolha em segurança. Em seguida, abra um caso de suporte na Sophos com as provas preservadas. Não copie credenciais, tokens nem cookies do browser para pedidos de suporte ou anexos desprotegidos.