Túnel dividido versus política da empresa: qual regra vence
Um desenho corporativo pode exigir saída aprovada, DNS gerenciado ou verificações de endpoints. Um desvio local contraria esse desenho mesmo quando faz um único site carregar.
Marcar um aplicativo num cliente de túnel dividido parece uma preferência local, e num dispositivo gerenciado está mais perto de uma mudança de política. A exceção tira o tráfego do caminho aprovado, que pode ser o mesmo por onde passam o DNS gerenciado, a filtragem e o endereço de origem que um serviço reconhece. O cliente não se comporta mal quando desfaz sua edição; a implantação está fazendo o trabalho dela.
Antes de discutir a caixa de seleção, descubra qual propriedade a política existe para proteger.
A propriedade por trás da regra
Algumas implantações roteiam tudo para que todo o tráfego passe por um gateway aprovado. Outras se importam com a resolução de nomes e mantêm as consultas no resolvedor corporativo em vez do da rede local. Outras ainda precisam de um endereço de origem estável para que os serviços internos possam decidir se respondem.
Um quarto grupo impõe a postura do endpoint: estado da criptografia do disco, nível de patches, saúde do agente. Dividir o túnel não muda isso, enquanto um desvio que evita o tráfego do próprio agente pode mudar.
São quatro requisitos diferentes, e cada um é quebrado por uma exceção diferente. Leia o requisito antes de propor a mudança, porque quem o escreveu pode dizer de imediato qual se aplica. Uma mudança que satisfaz o errado não compra nada.
Duas afirmações vale a pena descartar cedo. O túnel completo não dá aos administradores todas as páginas em texto claro, porque a criptografia de aplicações e os controles de endpoint decidem o que é visível. O túnel dividido também não é universalmente inseguro, porque DNS gerenciado, políticas por aplicativo e agentes de endpoint podem valer independentemente da rota.
Execute as verificações em ordem
A sequência abaixo reduz uma exceção à menor coisa que realmente falhou. Pare na primeira verificação que não se sustenta, porque uma correção posterior não compensa uma lacuna anterior.
Pergunte qual tráfego agora perde o gateway aprovado e depois confirme que a resolução de nomes ainda chega ao resolvedor corporativo. Verifique se o aplicativo em questão respeita um interruptor de emergência ou se gastou a tentativa falha numa rota direta. Depois olhe os serviços compartilhados: um visualizador de documentos ou um intermediário de atualizações pode levar a exceção mais longe do que a caixa sugere. Por fim, anote se a política é reaplicada na reconexão, porque esse comportamento decide se alguma mudança local sobrevive.
Cada resposta é um fato, e fatos são o que um pedido de exceção precisa. Uma discussão sobre se a VPN incomoda não é um deles. Escreva as respostas antes de a conversa começar.
Peça uma exceção estreita
Relate o aplicativo, o destino e a operação que falhou, nessa ordem. Um pedido para manter um atualizador no caminho direto é analisável; um pedido para contornar o túnel para todo o navegador não é.
Descreva o que você já tentou e o que os logs mostraram, e encaminhe ao time que é dono do perfil em vez de a quem responde no suporte. Num dispositivo gerenciado, o dono do perfil normalmente pode criar uma exclusão suportada que sobrevive a atualizações, enquanto uma edição local de rota não pode.
Se a resposta for não, trate como uma decisão de projeto e não como um obstáculo a contornar. A próxima revisão é o lugar para reabrir, com a operação falha documentada e a razão de negócio anexada. Contorná-la arrisca mais do que a exceção jamais valeu.
Faça a exceção sobreviver
Depois de uma mudança aprovada, confirme as partes que funcionavam antes, não apenas a parte que estava quebrada. Os nomes internos devem continuar resolvendo pelo resolvedor corporativo, os recursos privados devem continuar respondendo, e a tarefa que antes falhava deve agora concluir.
resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status
O primeiro comando prova que o resolvedor ainda responde a um sufixo interno, e o segundo prova que um pedido chega ao serviço interno a partir da rota atual. Execute-os de novo após reconectar, porque um envio de política pode desfazer em silêncio uma mudança que parecia estável durante o teste. Duas linhas de saída guardadas com o chamado fecham o ciclo. Sem elas, a exceção repousa na memória de alguém sobre uma página que carregou uma vez.
Registre a exceção, seu propósito e os componentes que ela cobre no mesmo lugar que as notas de implantação. Uma exceção não documentada vira o incidente do próximo trimestre, e uma documentada vira prova de que o desenho suporta uma carga de trabalho real.