Túnel dividido por aplicación o por destino: cuál elegir

El túnel dividido por aplicación y por destino no son dos ajustes para la misma tarea. Uno pregunta qué proceso envía un paquete; el otro pregunta hacia dónde va ese paquete. Una regla creada para la primera pregunta falla en silencio cuando el tráfico viene de un proceso auxiliar, y una regla creada para la segunda falla cuando un nombre de host se resuelve en una dirección que nunca incluyó. Elija el objeto que coincide con el requisito y demuéstrelo con dos paquetes de prueba: uno que debe usar el túnel y otro que no debe.

Las dos reglas actúan en capas distintas

Una regla de aplicación se aplica por encima de la capa de red, contra la identidad que el sistema operativo asigna al emisor. En Android es el UID detrás de un paquete, y el servicio VPN decide por UID si el tráfico entra en el túnel. No se consulta nada sobre el destino, así que la aplicación elegida puede alcanzar cualquier cosa y ninguna otra aplicación puede alcanzar la red interna.

Una regla de destino se aplica sobre el propio paquete. La interfaz del túnel posee un conjunto de prefijos, la tabla de rutas envía allí el tráfico coincidente y el proceso emisor es irrelevante. Por eso una regla de destino cubre un servicio, una impresora o una tarea por lotes que nadie recordó incluir, y por eso no puede expresarse como este programa exacto en una plataforma cuyo cliente nunca mira el proceso.

Las reglas de aplicación encajan con clientes móviles y agentes gestionados

Android expone la elección directamente: VpnService.Builder.addAllowedApplication() y addDisallowedApplication() toman nombres de paquete y aplican la decisión por UID, como se describe en la guía para desarrolladores de VPN de Android. iOS tiene un equivalente mediante reglas VPN por aplicación basadas en identificadores de paquete, normalmente entregadas por un perfil MDM en lugar de escribirse a mano.

Los clientes de escritorio son el punto débil. La mayoría de los clientes VPN de Windows y macOS enrutan por destino y no ofrecen ningún selector por proceso, porque el controlador del túnel ve paquetes, no procesos. Si su plan depende de tunelizar una aplicación en un portátil, compruebe las capacidades reales del cliente antes de diseñar alrededor de ello; quizá esté eligiendo entre una lista de destinos y una segunda máquina.

Un corolario que la gente pasa por alto: no puede imitar una regla de aplicación con rutas en esas plataformas. Añadir una ruta de host para el servidor de la aplicación tuneliza el tráfico de todos hacia ese servidor, incluidos el navegador y el actualizador.

Las reglas de destino encajan con listas de subredes y alcance de sitios

WireGuard hace explícito el modelo. AllowedIPs es enrutamiento por clave criptográfica: un paquete interno cuyo destino cae dentro de la lista de un par se cifra hacia ese par, y todo lo demás sale sin cifrar por la ruta normal. No hay ningún proceso que nombrar ni ambigüedad sobre lo que se incluye.

OpenVPN llega al mismo sitio mediante la tabla de rutas empujada. route-nopull impide que el servidor dicte rutas, y después una route 10.20.0.0 255.255.0.0 vpn_gateway del lado del cliente cubre exactamente el prefijo de la oficina. IPv6 es una declaración aparte en cada uno de estos clientes, y olvidarla es la forma más habitual de filtrar alrededor de un split IPv4 que parece correcto.

Un nombre de host no es una ruta. Si el perfil ofrece un campo de dominio, trátelo como un nombre que el cliente resuelve una vez, no como un rango de direcciones permanente; las redes de distribución de contenido y los balanceadores de carga entregarán direcciones distintas mañana.

Dónde fallan ambos modelos: auxiliares, servicios compartidos, resolutores

Los procesos auxiliares rompen las reglas de aplicación de una forma que parece un fallo del servidor. El actualizador de un navegador, un informador de fallos, un servicio de sincronización que se ejecuta como SYSTEM y un WebView incrustado en otro paquete son identidades separadas, así que tunelizar el navegador puede dejar la petición real fuera del túnel. Lo contrario es igual de confuso: una aplicación excluida que llama a una biblioteca compartida dentro de un proceso tunelizado sigue teniendo su tráfico dentro del túnel.

Las reglas de destino fallan en servicios compartidos y en nombres. Los recursos compartidos de archivos, las impresoras, el DNS interno y el servidor de licencias viven en direcciones, así que un túnel de una sola aplicación da acceso al navegador mientras la unidad mapeada queda muerta. Esa diferencia de cobertura no es un error de ninguno de los dos modelos, pero es la razón por la que un túnel de una sola aplicación produce tan a menudo que la VPN está activa y el recurso compartido ha desaparecido.

Los resolutores atraviesan ambos. Si el cliente configura servidores DNS internos pero el sistema operativo usa DNS sobre HTTPS hacia un resolutor público, la respuesta llega de fuera del túnel y la regla de destino puede no coincidir nunca. Compruebe qué resolutor respondió realmente antes de concluir que la regla es incorrecta, y confirme en el lado del cliente si instaló el resolutor del túnel. Un split que deja el DNS fuera del túnel parece perfecto en la tabla de rutas y aun así falla en todos los nombres internos.

Procedimiento: elegir, aplicar, verificar

Empiece por el requisito, no por el menú. Si el objetivo es que solo esta aplicación use el túnel, necesita reglas de aplicación y una plataforma que las soporte. Si el objetivo es que estas redes sean accesibles a través del túnel, necesita prefijos. Si la respuesta es ambas cosas, impleméntelas como dos controles separados y anote cuál posee cada fallo.

Aplique la forma más estrecha que pueda expresar y luego verifique preguntando a la tabla de rutas en lugar de al icono de estado del cliente:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Las dos primeras líneas nombran la interfaz que usaría un destino real; wg show imprime la lista de prefijos configurada; en Windows, Find-NetRoute responde a la misma pregunta que responderá la pila cuando se envíe el paquete. Si la interfaz es el túnel, la regla ha coincidido.

Después pruebe un segundo paquete que debería quedar excluido, desde otra aplicación, hacia el mismo destino. Anote en el tique la versión del cliente, el tipo de regla, la lista de prefijos o de paquetes y los dos resultados observados. Ese par de resultados es lo que dice al siguiente ingeniero si la política está mal configurada o si el tráfico nunca le perteneció.