"O app funciona às vezes" é o chamado que come tardes - e no Zscaler Private Access (), sua investigação é misericordiosamente restrita, porque a arquitetura admite exatamente três famílias de suspeitos. Ou a política recusou o acesso, ou as pernas de entrega estão doentes, ou a última milha connector-a-servidor - alcançabilidade e, esmagadoramente, DNS - está falhando. O ofício é separar as três rápido, porque seus consertos moram em salas diferentes.

Suspeito um: a política disse não

Uma negação de política é uma decisão, e o artigo de segmentos deu sua ordem de depuração: de cima para baixo, primeira correspondência no segmento mais específico - então verifique qual regra de fato correspondeu, se uma regra larga eclipsa a específica que você esperava, e lembre que nenhuma correspondência significa o padrão, e o padrão é negar. Depois lembre que os critérios são conjuntivos: a identidade pode passar enquanto a postura falha, e postura é a clássica geradora de intermitência neste ramo - o dispositivo derivando para dentro e para fora de um perfil produz acesso que funciona na mesa e falha no sofá, o que é arquivado como "instável" até alguém ler as condições. O sintoma distintivo da família de política: a negação é limpa - acesso recusado, consistentemente para a mesma combinação usuário-dispositivo-estado - em vez de lenta ou parcial.

Suspeito dois: as pernas estão doentes

A política disse sim, e nada chegou: agora são as três pernas do transporte - a perna do cliente até o Service Edge, a perna de saída do connector, e o costurado entre elas. O culpado usual da intermitência neste ramo é capacidade e saúde de connector: um grupo de connectors em que um membro está fora ou saturado serve algumas sessões bem e outras mal, o que da cadeira do usuário se lê como aleatoriedade. As regras de operação do artigo de arquitetura viram a checklist: todos os connectors do grupo servidor estão de pé e atualizados, o grupo é de fato o que o Server Group do segmento amarra, e a redundância se sustenta por grupo que serve o segmento, não em algum lugar do organograma.

Suspeito três: a última milha, que geralmente é DNS

A falha mais instrutiva do ZPA é aquela em que tudo acima está verde e o app ainda falha: a política permitiu, o Microtunnel costurou, e o próprio não consegue resolver o nome da aplicação - porque nesta geometria é o connector, não o cliente, que resolve e alcança o servidor. DNS mal configurado do lado do connector produz exatamente o clássico cérebro-dividido: o app funciona para quem está de pé no data center e falha pelo ZPA, e cada verificação tradicional que o cliente roda parece boa porque o cliente nunca foi quem perguntava. A investigação é uma conversa com o resolvedor conduzida do ponto de vista do connector. A mesma gaveta guarda as armadilhas de bypass que o artigo de segmentos documentou: um Bypass Always envenenando um compartilhado, ou um domínio de sobrepondo os domínios de descoberta - ambos se disfarçam de indisponibilidade sendo configuração.

A separação do operador

Rode os três em ordem de custo: a leitura de política é uma consulta de console; saúde das pernas é um dashboard; a verificação de DNS precisa do ponto de vista do connector. Capture o horário exato do usuário que falha e correlacione com mudanças - uma edição de política, uma atualização de connector - antes de acreditar em fantasmas. E guarde a frase de triagem: negação limpa e consistente é política; maldade aleatória é saúde; funciona-por-dentro-falha-através é a última milha do connector.