Túnel completo frente a túnel dividido: las cuatro diferencias
La etiqueta decide por dónde sale el resto del tráfico de un portátil, no lo rápido que es. Compare la salida, la carga, el DNS y el comportamiento ante fallos antes de elegir.
Las etiquetas de túnel describen hacia dónde va el resto del tráfico de un portátil, no lo rápido que va. Con un túnel completo, las peticiones públicas atraviesan la puerta de enlace VPN antes de salir a internet. Con un túnel dividido, los destinos privados usan el túnel y todo lo demás toma la ruta local. Ambos llegan a la aplicación interna, así que la prueba de alcance que la gente hace primero no dice nada sobre qué política está desplegada.
Pruebe la salida en su lugar: qué dirección informa una página de eco pública y qué resolutor respondió.
Mito: el túnel dividido es solo la opción más rápida
El túnel dividido se vende a menudo como una función de rendimiento, y puede serlo, pero eso es un efecto secundario y no la definición. La definición es una decisión de enrutamiento sobre qué destinos entran en el túnel. La diferencia de velocidad aparece solo cuando la ruta directa es realmente mejor que el rodeo por la oficina. Con un enlace doméstico congestionado y una puerta poco cargada, el túnel completo puede ser el más rápido de los dos.
Así que el planteamiento honesto trata de la propiedad y el control de la ruta, con el rendimiento como algo que se mide después. Una política elegida por velocidad que mueve en silencio su DNS y su salida pública se eligió por el motivo equivocado.
Qué cambia en realidad: la salida
Con un túnel completo, un sitio web público ve la dirección de salida de la oficina y el filtrado de la oficina ve la petición. Con un túnel dividido, el mismo sitio ve la dirección doméstica del usuario y la oficina no ve nada. Son modelos de visibilidad distintos y ninguno es automáticamente más seguro. La pregunta útil es cuál puede operar realmente la organización.
Compruébelo directamente en lugar de confiar en una insignia de Conectado. El eco de dirección pública muestra la salida, y una prueba de resolutor muestra de quién era el DNS que respondió.
| Question | Full tunnel | Split tunnel |
|---|---|---|
| Public exit address | Office egress | Local connection |
| Gateway load | All covered traffic | Private destinations only |
| Office visibility | Requests and destinations | Private resource access only |
Qué debe soportar entonces la puerta de enlace
Una puerta de enlace que transporta videollamadas, descargas y aplicaciones privadas necesita capacidad para una carga de trabajo muy distinta a la de una que solo transporta peticiones internas. La conexión a internet del sitio transporta tanto la llegada del usuario como la salida pública posterior, así que dos enlaces pueden saturarse a la vez.
La salida local elimina esa carga y el rodeo, y no garantiza una mejor experiencia, porque la ruta directa también puede estar congestionada. Compare la aplicación real en lugar de tratar una etiqueta de enrutamiento como una medición de rendimiento.
Existen excepciones bajo un túnel completo
Una ruta predeterminada no es un inventario de cada paquete. Rutas más específicas, permisos de red local, exclusiones de aplicaciones y reglas IPv6 separadas mueven todas tráfico, y por eso una política descrita como túnel completo todavía puede filtrar. La documentación de enrutamiento del sistema operativo marca esa distinción para los valores predeterminados de túnel forzado, y la lista de excepciones del cliente es donde suele vivir la fuga. Verifique el comportamiento, no la intención.
IPv6 merece una mirada propia, porque un túnel que solo transporta IPv4 deja toda una pila fuera de la política.
El DNS es una política aparte
Los nombres internos necesitan un resolutor que los conozca, y ese resolutor puede ser accesible solo a través del túnel. Un navegador con su propio DNS cifrado puede saltarse por completo el resolutor del sistema, lo que produce una división en la que los nombres internos fallan y los públicos funcionan, o al revés.
Decida adónde deben ir las consultas y luego haga que el cliente y el navegador coincidan. La navegación pública exitosa nunca prueba la resolución de nombres internos, así que es la evidencia equivocada cuando un sitio de intranet desaparece.
Escriba la política de fallos y luego pruébela
Decida qué ocurre cuando el túnel se cae: bloquear todo, bloquear solo los recursos privados o permitir conexiones directas. La reconexión automática no responde a esa pregunta, y un interruptor de seguridad que solo cubre la interfaz del túnel puede dejar que las aplicaciones excluidas hablen libremente. Pruebe una desconexión real y un cambio de red, y luego lea el estado del cliente, porque la documentación describe el comportamiento previsto y no el instalado.
Anote las rutas privadas, la salida pública, los servidores DNS, las excepciones locales y el comportamiento ante fallos en una nota breve. Esa nota es lo que hace la política verificable para alguien que no la escribió.