A direção do tráfego decide o que o edge enxerga
Nenhuma política se aplica a tráfego que nunca chega. A direção é a rampa de acesso, e o método escolhido determina não só se o tráfego alcança o serviço, mas o que o serviço sabe sobre ele quando alcança.
Esse é o enquadramento que vale manter. Os cinco métodos não são cinco formas de fazer a mesma coisa.
Os cinco, e o que cada um sabe
O cliente no endpoint é o método recomendado para tráfego de usuário final e o único que carrega identidade do usuário e postura do dispositivo junto com o fluxo. Ele acompanha o usuário para fora da rede corporativa, o que um túnel de site não faz. O custo é ter de implantá-lo e mantê-lo em cada dispositivo.
Um túnel direciona tudo que sai de um site, inclusive os dispositivos que nunca vão rodar um agente — impressoras, appliances, notebooks de terceiros. Ele preserva o endereço privado do usuário, que é o que torna possível política por endereço e log detalhado. Ele conhece o site, não a pessoa.
Um túnel é a mesma direção em nível de site sem o custo da criptografia. Escolha-o em vez do IPsec por questão de vazão, onde o caminho já é confiável, e não por conveniência.
Um proxy explícito aponta o navegador ou o sistema operacional para o serviço. É o método para ambientes legados e regulados e para casos em que não há roteamento por política. Ele direciona o que estiver configurado para usá-lo — uma aplicação que ignora as configurações de proxy simplesmente não é direcionada, e nada anuncia isso.
O encadeamento de proxy encaminha a partir de um proxy que você já opera. É um método de migração: o parque muda sem tocar em todos os endpoints no mesmo dia. O proxy antigo continua no caminho e continua sendo seu para operar.
A interação que surpreende as pessoas
O cliente detecta outros métodos de direção e, por padrão, se desabilita quando encontra IPsec, GRE ou um proxy explícito.
Então "temos o cliente e um túnel" não é automaticamente redundância. É um dos dois, e qual deles depende de uma configuração que a maioria nunca abriu. O cliente pode ser configurado para continuar direcionando — e há um terceiro arranjo que vale conhecer: implantá-lo ao lado do túnel não para direcionar, mas para provisionar certificados e fornecer a identidade do usuário. O túnel carrega o tráfego; o cliente responde quem é o usuário.
O limite rígido
Inspeção TLS e autenticação exigem os certificados raiz e intermediário da Netskope no endpoint.
Um túnel de site carrega tráfego de dispositivos que ninguém gerencia. Se o pacote de certificados não puder ser instalado neles, o tráfego chega e não pode ser descriptografado — a política continua rodando, sobre metadados. Qualquer regra escrita como se o conteúdo estivesse visível não vai fazer o que o autor acredita, e vai parecer correta no console.
Duas distinções que vale manter claras
Um steering bypass e uma regra de não descriptografar não são a mesma coisa. A primeira significa que o tráfego nunca chega ao serviço; a segunda, que ele chega e não é aberto. Aplicações com certificate pinning normalmente precisam da primeira, e confundir as duas produz uma política que parece aplicada e nunca rodou.
Declarar uma porta não padrão como tráfego web a envia ao proxy e a retira da inspeção do cloud firewall. Isso é adequado para tráfego que realmente é web. Para qualquer outra coisa, é uma isenção silenciosa.
E uma pergunta relacionada que isto não responde
Escolher um método é uma decisão de projeto. Descobrir o que acontece com um fluxo específico dada uma configuração de direção já em vigor — modos, exceções, comportamento de fail close — é outra pergunta, e o explicador de decisão de direção deste site é a ferramenta para ela.