Túnel dividido fronte á política da empresa: que regra gaña
Un deseño corporativo pode esixir saída aprobada, DNS xestionado ou comprobacións de puntos finais. Unha derivación local contradí ese deseño aínda que faga cargar un só sitio.
Marcar unha aplicación nun cliente de túnel dividido semella unha preferencia local, e nun dispositivo xestionado está máis preto dun cambio de política. A excepción saca o tráfico do camiño aprobado, que pode ser o mesmo polo que viaxan o DNS xestionado, o filtrado e o enderezo de orixe que recoñece un servizo. O cliente non se comporta mal cando desfai a túa edición; o despregamento fai o seu traballo.
Antes de discutir pola caixa, comproba que propiedade existe para protexer a política.
A propiedade detrás da regra
Algúns despregamentos encamiñan todo para que o tráfico pase por unha pasarela aprobada. A outros impórtalles a resolución de nomes e manteñen as consultas no resolutor corporativo en lugar do da rede local. Outros necesitan un enderezo de orixe estable para que os servizos internos poidan decidir se responden.
Un cuarto grupo impón a postura do punto final: estado do cifrado do disco, nivel de parches, saúde do axente. Dividir o túnel non cambia iso, mentres que unha derivación que evita o tráfico propio do axente si pode.
Son catro requisitos distintos e cada un rompe con unha excepción diferente. Le o requisito antes de propoñer o cambio, porque quen o escribiu pode dicirche de inmediato cal se aplica. Un cambio que satisfai o equivocado non compra nada.
Dúas afirmacións convén descartalas axiña. O túnel completo non dá aos administradores todas as páxinas en texto claro, porque o cifrado de aplicacións e os controis de puntos finais deciden que é visible. O túnel dividido tampouco é universalmente inseguro, porque o DNS xestionado, as políticas por aplicación e os axentes de puntos finais poden manterse independentemente da ruta.
Executa as comprobacións en orde
A secuencia seguinte reduce unha excepción ao máis pequeno que realmente fallou. Detente na primeira comprobación que non se cumpra, porque unha corrección posterior non compensa unha carencia anterior.
Pregunta que tráfico perde agora a pasarela aprobada e despois confirma que a resolución de nomes segue chegando ao resolutor corporativo. Comproba se a aplicación en cuestión respecta un interruptor de emerxencia ou se gastou o intento fallido nunha ruta directa. Despois mira os servizos compartidos: un visor de documentos ou un intermediario de actualizacións pode levar a excepción máis lonxe do que suxire a caixa. Por último, anota se a política se volve aplicar ao reconectar, porque ese comportamento decide se sobrevive calquera cambio local.
Cada resposta é un feito, e os feitos son o que necesita unha solicitude de excepción. Unha discusión sobre se a VPN é molesta non é un deles. Escribe as respostas antes de que comece a conversa.
Pide unha excepción estreita
Informa da aplicación, o destino e a operación que fallou, nesa orde. Unha solicitude para manter un actualizador no camiño directo é revisable; unha solicitude para saltar o túnel para todo o navegador non o é.
Describe o que xa probaches e o que mostraron os rexistros, e diríxeo ao equipo que posúe o perfil en lugar de a quen responde na asistencia. Nun dispositivo xestionado, o propietario do perfil adoita poder crear unha exclusión compatible que sobrevive ás actualizacións, mentres que unha edición local da ruta non pode.
Se a resposta é non, trátao como unha decisión de deseño e non como un obstáculo que rodear. A próxima revisión é o lugar para reabrilo, coa operación fallida documentada e a razón de negocio anexa. Rodealo arrisca máis do que a excepción valeu nunca.
Fai que a excepción sexa viable
Tras un cambio aprobado, confirma as partes que funcionaban antes, non só a parte que estaba rota. Os nomes internos deberían seguir resolvéndose mediante o resolutor corporativo, os recursos privados deberían responder e a tarefa que antes fallaba debería completarse agora.
resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status
O primeiro comando demostra que o resolutor segue respondendo a un sufixo interno, e o segundo demostra que unha solicitude chega ao servizo interno desde a ruta actual. Vólveos executar tras reconectar, porque un envío de política pode desfacer en silencio un cambio que parecía estable durante a proba. Dúas liñas de saída gardadas co tique pechan o círculo. Sen elas, a excepción descansa na memoria de alguén sobre unha páxina que se cargou unha vez.
Rexistra a excepción, o seu propósito e os compoñentes que cobre no mesmo lugar que as notas de despregamento. Unha excepción non documentada convértese no incidente do próximo trimestre, e unha documentada convértese en proba de que o deseño soporta unha carga de traballo real.