Cómo el túnel dividido decide qué tráfico usa la VPN

El túnel dividido es una política de enrutamiento expresada como un conjunto de reglas, y el cliente es solo lo que las instala. La separación ocurre en dos lugares: reglas de coincidencia que eligen una ruta para cada paquete, y vínculos que fijan una aplicación a una interfaz diga lo que diga la tabla. En qué mecanismo se apoya su cliente explica la mayoría de las sorpresas que la gente reporta.

Una política que puede formular en una línea es comprobable. Una política descrita como navegación más rápida no lo es, y no le dirá qué regla cambiar cuando una solicitud va por el camino equivocado.

El cliente instala reglas, el núcleo toma la decisión

Cuando el túnel se levanta, el cliente agrega rutas y a menudo reglas de política a la misma tabla que usan sus otras interfaces. Cada paquete llega entonces a una búsqueda que compara su destino con cada prefijo candidato y conserva la coincidencia más específica, mientras la prioridad resuelve empates entre reglas que apuntan a tablas distintas. Nada en esa búsqueda sabe que el paquete vino de una pestaña del navegador y no de una tarea de copia de seguridad. La regla que gana es la que fija la ruta, y puede leerla antes y después del cambio.

Por eso un túnel dividido puede parecer arbitrario. Dos destinos en una misma aplicación pueden tomar rutas distintas solo porque un prefijo es más estrecho que el otro.

La misma elección existe en cada plataforma, aunque los nombres cambian. Windows empuja la decisión a su plataforma de filtros, Android expone una lista de permitidos por aplicación a través de su servicio VPN, y macOS ata el túnel a un dispositivo que aún obedece la tabla de enrutamiento. Las notas de enrutamiento de Microsoft merecen leerse para el caso de Windows, y una guía escrita para una plataforma rara vez se traslada sin cambios a otra.

El vínculo por aplicación y los prefijos de destino son herramientas distintas

Una política de destino pregunta hacia dónde va el paquete y consulta la tabla de rutas o una regla de política. Una política por aplicación pregunta qué programa abrió el socket, y la plataforma mantiene ese programa en la interfaz del túnel incluso cuando una ruta más específica apunta a otro sitio. La segunda es más fuerte porque sobrevive a los cambios de tabla, pero solo cubre los procesos que la plataforma puede atribuir. Un proceso auxiliar, un navegador incrustado o un servicio que abre su propia conexión puede que no hereden el vínculo que usted supuso.

Ninguno de los dos enfoques sobrevive a una política basada en nombres sin ayuda. Las direcciones de los sitios grandes rotan entre redes de contenido, así que fijar un nombre de host a unos pocos prefijos produce una regla que deja de coincidir en silencio. Una política que debe seguir nombres necesita un componente consciente de la resolución en lugar de una ruta estática.

El DNS y el interruptor de seguridad siguen sus propias reglas

La resolución de nombres es una decisión separada del enrutamiento de paquetes, y un túnel dividido normalmente quiere dos resolutores: el de la empresa para nombres internos, el local para todo lo demás. El cliente puede instalar ajustes DNS por interfaz, entregar las consultas a un resolutor intermedio o dejar el valor predeterminado del sistema intacto. Un navegador con su propio resolutor cifrado evita las tres disposiciones. Pruebe una consulta en lugar de suponer que el resolutor siguió la ruta.

Un interruptor de seguridad añade un filtro por encima, y ese filtro no siempre distingue una exclusión deliberada de una fuga accidental. Algunos clientes bloquean todo fuera del túnel mientras otros permiten las exclusiones que la política declara, así que lea qué comportamiento implementa el suyo antes de confiar en cualquiera de los dos.

Compruebe la división desde ambos lados

Pruebe la ruta incluida y la ruta excluida por separado, y juzgue el resultado por el nombre de la interfaz y no por una dirección pública. Estos comandos suponen un host Linux con el dispositivo de túnel ya levantado. Sustituya 203.0.113.10 por un destino que su política enrute hacia dentro, y 198.51.100.25 por uno que envíe hacia fuera.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Lea las dos primeras respuestas juntas, porque la interfaz nombrada en cada una muestra si la división puso ese destino en el túnel. La consulta al resolutor muestra qué servidor respondió al nombre interno, y el último comando demuestra que el dispositivo de túnel puede transportar una solicitud. Un fallo en la segunda línea mientras la primera tiene éxito significa que la política hace exactamente lo que se le dijo.

Repita el conjunto tras una reconexión y tras un cambio de red. La renovación del arrendamiento y la agitación de las interfaces son donde una división deja de coincidir con la intención para la que se construyó, y una salida guardada de cada ejecución hace evidente la deriva.