# Escolhendo como o tráfego chega ao service edge

> Cliente, IPsec, GRE, proxy explícito ou encadeamento de proxy. Cada um muda o que o edge consegue saber, não apenas como os pacotes chegam — e o cliente se desabilita quando encontra um túnel.

Source: https://ronutz.com/pt-BR/learn/netskope-steering-methods  
Updated: 2026-08-14  
Related tools: https://ronutz.com/pt-BR/tools/netskope-steering-explainer, https://ronutz.com/pt-BR/tools/netskope-steering-decision-explainer, https://ronutz.com/pt-BR/tools/sse-architecture-explainer

---

## 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 IPsec** 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 GRE** é 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 SAML 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.