Tanto o blueprint de Integrator ("Netskope client deployment") quanto todas as seções de troubleshooting ("client connectivity issues") apontam para a mesma peça: o agente no endpoint. Enxergar esse agente como três problemas separados (software, identidade e túnel) é o que faz esses objetivos deixarem de ser decoreba e passarem a ser raciocínio.
Como levar o software até a máquina: três famílias de instalação
A implantação corporativa acontece de três jeitos bem conhecidos. Push pela ferramenta de gerenciamento: as ferramentas de /UEM (Intune, Jamf e afins) instalam o client em silêncio e em escala, e esse é o padrão no parque corporativo. Conduzida pelo : a instalação é acoplada ao fluxo de identidade, e o enrollment (o registro do client junto ao tenant) acontece no login (single sign-on) do usuário. Por convite: convites por e-mail, um por usuário, para grupos pequenos, pilotos e a cauda longa. O ponto de engenharia por trás das três é que instalar é a metade fácil; o método de instalação é escolhido principalmente pela confiabilidade com que leva ao segundo problema.
Como vincular o client a uma pessoa: enrollment é identidade
Um client recém-instalado não serve para nada enquanto não souber de quem ele é: toda a vantagem sobre os túneis de site é que o tráfego já chega atribuído a um usuário. O enrollment liga o dispositivo a uma identidade, e é por isso que ele depende da infraestrutura de diretório que este site já cobre: usuários provisionados via SCIM ou importação de diretório, autenticados via SSO SAML. As falhas clássicas de implantação estão nessa junção, e não no instalador: o usuário existe no endpoint, mas não no tenant; o UPN que o client vê não bate com a identidade provisionada; a autenticação do enrollment entra em loop. Quando o objetivo de troubleshooting fala em "user provisioning", é dessa junção que ele está falando.
Como controlar o que o client carrega: configuração de steering e comportamento em falha
Depois do enrollment, o client baixa a sua configuração de steering (as regras de direcionamento do tráfego): a declaração, feita no tenant, do que vai pelo túnel (tráfego web, aplicações de nuvem ou todo o tráfego, para cobertura completa de firewall) e do que fica de fora (as aplicações e os destinos que precisam ir direto: coisas que quebram quando passam por proxy e tráfego que já é tratado em outro lugar). Dois comportamentos operacionais fecham o cenário e decidem incidentes de verdade. Primeiro, as exceções são consultadas no próprio dispositivo: um destino excluído do steering nunca chega à nuvem, então nenhuma política do lado da nuvem vai se aplicar a ele, e essa é a primeira pergunta a fazer em metade dos chamados do tipo "a política não está sendo aplicada". Segundo, o comportamento em caso de falha: quando o client não consegue alcançar nenhum ponto de presença () do , a escolha do tenant entre fail-open (o tráfego passa sem inspeção; ganha a disponibilidade) e fail-closed (o tráfego é bloqueado; ganha a segurança) é o checkbox de maior impacto de toda a configuração, e a resposta certa é uma decisão de negócio, não uma decisão técnica.
Como ler um incidente de client
A ordem de diagnóstico que sai do modelo em três partes: o software está instalado e rodando (problema de instalação)? O enrollment foi feito com o usuário esperado (problema de identidade)? O túnel está de pé até um data center próximo, e esse tráfego está dentro ou fora das exceções de steering (problema de túnel)? Os logs do client respondem às três perguntas, e é exatamente por isso que "collect log files used for service requests" aparece no blueprint ao lado dos objetivos de conectividade, e por isso que a visão da arquitetura da plataforma, com o atendimento no PoP mais próximo, é o pano de fundo de toda reclamação de latência.