Túnel dividido frente a la política de la empresa: qué regla gana

Marcar una aplicación en un cliente de túnel dividido parece una preferencia local, y en un dispositivo gestionado se acerca más a un cambio de política. La excepción saca el tráfico del camino aprobado, que puede ser el mismo por el que viajan el DNS gestionado, el filtrado y la dirección de origen que un servicio reconoce. El cliente no se comporta mal cuando revierte tu edición; el despliegue hace su trabajo.

Antes de discutir por la casilla, averigua qué propiedad existe para proteger la política.

La propiedad detrás de la regla

Algunos despliegues lo enrutan todo para que el tráfico pase por una puerta de enlace aprobada. A otros les importa la resolución de nombres y mantienen las consultas en el resolutor corporativo en lugar del de la red local. Otros necesitan una dirección de origen estable para que los servicios internos puedan decidir si responden siquiera.

Un cuarto grupo impone la postura del punto final: estado del cifrado del disco, nivel de parches, salud del agente. Dividir el túnel no cambia eso, mientras que un bypass que evita el tráfico propio del agente sí puede.

Son cuatro requisitos distintos y cada uno lo rompe una excepción diferente. Lee el requisito antes de proponer el cambio, porque quien lo escribió puede decirte de inmediato cuál se aplica. Un cambio que satisface el equivocado no compra nada.

Dos afirmaciones conviene descartarlas pronto. El túnel completo no da a los administradores todas las páginas en texto claro, porque el cifrado de aplicaciones y los controles de punto final deciden qué es visible. El túnel dividido tampoco es universalmente inseguro, porque el DNS gestionado, las políticas por aplicación y los agentes de punto final pueden mantenerse con independencia de la ruta.

Ejecuta las comprobaciones en orden

La secuencia siguiente reduce una excepción a lo más pequeño que realmente falló. Detente en la primera comprobación que no se cumpla, porque una corrección posterior no compensa una carencia anterior.

Pregunta qué tráfico pierde ahora la puerta de enlace aprobada y luego confirma que la resolución de nombres sigue llegando al resolutor corporativo. Comprueba si la aplicación en cuestión respeta un interruptor de emergencia o si gastó el intento fallido en una ruta directa. Después mira los servicios compartidos: un visor de documentos o un intermediario de actualizaciones puede llevar la excepción más lejos de lo que sugiere la casilla. Por último, anota si la política se vuelve a aplicar al reconectar, porque ese comportamiento decide si sobrevive cualquier cambio local.

Cada respuesta es un hecho, y los hechos son lo que necesita una solicitud de excepción. Una discusión sobre si la VPN es molesta no es uno de ellos. Escribe las respuestas antes de que empiece la conversación.

Pide una excepción estrecha

Informa de la aplicación, el destino y la operación que falló, en ese orden. Una solicitud para mantener un actualizador en el camino directo es revisable; una solicitud para saltarse el túnel para todo el navegador no lo es.

Describe lo que ya probaste y lo que mostraron los registros, y dirígelo al equipo que posee el perfil en lugar de a quien responde en el servicio de ayuda. En un dispositivo gestionado, el propietario del perfil suele poder crear una exclusión compatible que sobrevive a las actualizaciones, mientras que una edición local de la ruta no puede.

Si la respuesta es no, trátalo como una decisión de diseño y no como un obstáculo que rodear. La próxima revisión es el lugar para reabrirlo, con la operación fallida documentada y la razón de negocio adjunta. Rodearlo arriesga más de lo que la excepción valió nunca.

Haz que la excepción sea viable

Tras un cambio aprobado, confirma las partes que funcionaban antes, no solo la parte que estaba rota. Los nombres internos deberían seguir resolviéndose mediante el resolutor corporativo, los recursos privados deberían seguir respondiendo y la tarea que antes fallaba debería completarse ahora.

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

El primer comando demuestra que el resolutor sigue respondiendo a un sufijo interno, y el segundo demuestra que una solicitud llega al servicio interno desde la ruta actual. Vuelve a ejecutarlos tras reconectar, porque un envío de política puede deshacer en silencio un cambio que parecía estable durante la prueba. Dos líneas de salida guardadas con el tique cierran el círculo. Sin ellas, la excepción descansa en la memoria de alguien sobre una página que se cargó una vez.

Registra la excepción, su propósito y los componentes que cubre en el mismo lugar que las notas de despliegue. Una excepción no documentada se convierte en el incidente del próximo trimestre, y una documentada se convierte en prueba de que el diseño soporta una carga de trabajo real.