Qué es el split tunneling — cómo funciona realmente el enrutamiento VPN por aplicación

En pocas palabras: una VPN estándar enruta el 100 % del tráfico de tu dispositivo a través del túnel cifrado. El split tunneling rompe esa regla a propósito. Tú eliges qué aplicaciones o qué destinos evitan el túnel y salen directamente por tu conexión normal. Suena simple, y en concepto lo es — pero la implementación práctica varía significativamente entre sistemas operativos, y las concesiones de privacidad son fáciles de pasar por alto. Una aplicación de streaming enrutada fuera del túnel sigue viendo tu IP real. Una aplicación bancaria enrutada fuera del túnel sigue comunicándose con tu banco a través de tu red doméstica — lo cual está bien, hasta que esa misma aplicación también realiza una consulta DNS que se filtra a través del bypass y expone un dominio diferente que no tenías intención de revelar.

Qué hace realmente el túnel VPN (el punto de partida)

Antes de poder entender qué se está dividiendo, necesitas tener claro qué hace el túnel completo. Un cliente VPN que se ejecuta en tu dispositivo crea una interfaz de red virtual — en Linux generalmente se llama tun0 o wg0, en macOS es utun, en iOS y Android el sistema operativo la gestiona a través de una API de extensión por aplicación. La tabla de enrutamiento del sistema operativo se modifica para que la ruta predeterminada — la regla que dice «envía los paquetes sin otra ruta coincidente a esta pasarela» — apunte a esa interfaz virtual en lugar de a tu interfaz física de Wi-Fi o celular.

A partir de ese momento, cada paquete que genera tu dispositivo es cifrado por el cliente VPN, envuelto en una nueva cabecera IP que apunta al servidor VPN, y enviado por la interfaz física como un flujo homogéneo único. El servidor VPN descifra el paquete, lo reenvía a su destino real en la internet pública, recibe la respuesta, la cifra de nuevo y la devuelve. Tu ISP solo ve el flujo cifrado dirigido a una única IP. Los sitios web de destino ven la IP del servidor VPN, no la tuya.

Ese es el comportamiento predeterminado. El split tunneling interviene en este modelo añadiendo rutas más específicas a la tabla de enrutamiento — reglas que dicen «para el tráfico dirigido a este destino» o «para el tráfico generado por esta aplicación, ignora la ruta predeterminada del túnel y usa la interfaz física directamente».

Qué cambia el split tunneling

Conceptualmente, el split tunneling introduce una bifurcación en tu flujo de red. Algunos paquetes pasan por el túnel cifrado; otros salen por la interfaz directa. La decisión la toma el cliente VPN según las reglas que configures. Hay tres categorías comunes de reglas de división:

• Por aplicación — «Envía todo el tráfico de Netflix fuera del túnel; tunel el resto.» Se implementa etiquetando los paquetes con el UID o PID del proceso de origen y tomando decisiones de enrutamiento por etiqueta.
• Por destino — «Envía el tráfico a 10.0.0.0/8 fuera del túnel para que pueda acceder a mi NAS doméstico; tunel el resto.» Se implementa exclusivamente con entradas en la tabla de enrutamiento — la forma más simple.
• Por URL o dominio — «Envía el tráfico a *.bank.com fuera del túnel.» Esto es frágil porque la capa de enrutamiento del sistema operativo no conoce dominios de forma nativa; requiere que el cliente VPN intercepte el DNS y reescriba las respuestas, o que mantenga una lista de IPs permitidas de forma dinámica que siga las resoluciones DNS. Los proveedores lo implementan de forma inconsistente.

Esta es la imagen arquitectónica, simplificada:

Túnel completo (sin división):
  [App A] -> [App B] -> [App C]
        \        |        /
         [Interfaz VPN virtual]
                 |
         [Túnel cifrado]
                 |
         [Servidor VPN] -> internet

Split tunnel (por aplicación, App C excluida):
  [App A] -> [App B]        [App C]
        \        /               \
   [Interfaz VPN virtual]   [Wi-Fi físico]
              |                    |
       [Túnel cifrado]     [Internet sin cifrar]
              |                    |
        [Servidor VPN]       directo al destino

La «división» es el punto de divergencia dentro de tu sistema operativo — la elección entre la interfaz virtual y la interfaz física se realiza antes del cifrado, por lo que un paquete que evita el túnel nunca fue cifrado en primer lugar. No hay paso de descifrado; simplemente sale de tu dispositivo tal cual.

Split tunneling inverso — lista de exclusión vs lista de inclusión

Las configuraciones de split tunneling vienen en dos variantes que parecen simétricas pero tienen un comportamiento de fallo predeterminado muy diferente:

• Modo lista de exclusión (el valor predeterminado habitual) — «Tunel todo excepto las aplicaciones/destinos de esta lista.» El valor predeterminado es protegido; solo las excepciones específicas se filtran. Si olvidas añadir una aplicación a la lista, permanece protegida.
• Modo lista de inclusión (también llamado split tunneling inverso) — «Tunel solo las aplicaciones/destinos de esta lista; el resto va directo.» El valor predeterminado es desprotegido; solo las aplicaciones específicas están tuneadas. Si olvidas añadir una aplicación a la lista, se filtra.

El modo lista de inclusión es la opción correcta para «quiero que solo mi navegador use la VPN, el resto puede usar mi conexión normal». El modo lista de exclusión es el adecuado para «quiero que la mayoría de las cosas estén protegidas, pero algunas aplicaciones específicas necesitan la red real». La mayoría de los usuarios domésticos quieren el modo lista de exclusión. Los equipos de operaciones y DevOps a veces prefieren el modo lista de inclusión porque intentan exponer servicios específicos a través del túnel sin interrumpir el resto del sistema.

El modo de fallo para el modo lista de inclusión es grave: si añades una nueva aplicación y olvidas incluirla en la lista, el tráfico de esa aplicación se filtra. El modo de fallo para el modo lista de exclusión es más leve: las aplicaciones olvidadas permanecen protegidas — simplemente tendrás problemas de compatibilidad molestos cuando una aplicación de streaming o bancaria falla porque detecta la IP de la VPN.

Cuándo usar split tunneling — cinco escenarios concretos

El split tunneling tiene usos legítimos reales. Estas son las situaciones en las que es la herramienta adecuada:

1. Servicios de streaming que detectan y bloquean los endpoints de VPN

Netflix, Disney+, Hulu y la mayoría de las emisoras regionales mantienen grandes listas de IPs conocidas de datacenters VPN y se niegan a transmitir cuando detectan una. Puedes desactivar la VPN (perdiendo toda la protección) o dividir en túnel la aplicación de streaming para que vea tu IP real mientras todo lo demás permanece protegido.

2. Aplicaciones bancarias y financieras con detección de fraude basada en ubicación

Los bancos frecuentemente tratan un cambio repentino de IP a un datacenter VPN como una señal de fraude — activarán autenticación adicional, retendrán transacciones o bloquearán brevemente la cuenta. Dividir la aplicación del banco fuera del túnel mantiene tu relación de IP real con el banco de forma consistente. Esto es una solución de usabilidad, no una mejora de seguridad — la conexión del banco ya está cifrada con TLS, por lo que la VPN nunca añadía mucha seguridad a esa sesión específica.

3. Recursos de red local (NAS, impresora, domótica)

Cuando la VPN captura todo el tráfico, tu dispositivo ya no puede acceder a la impresora en 192.168.1.50 porque esa IP no es accesible a través del túnel VPN. El split tunneling basado en destino (excluyendo 192.168.0.0/16 y 10.0.0.0/8) restaura el acceso local sin desactivar la VPN para internet público. Muchos clientes VPN hacen esto automáticamente de forma predeterminada; algunos no.

4. Aplicaciones sensibles a la latencia

Los juegos en línea competitivos, las videoconferencias en directo y las llamadas de voz sufren cuando se introduce latencia adicional al enrutar a través de un servidor VPN en una región lejana. Dividir esas aplicaciones específicas fuera del túnel puede recuperar la latencia mientras mantiene todo lo demás cifrado. La concesión: esas aplicaciones ahora son identificables para tu ISP y visibles para los observadores de red.

5. VPN de trabajo junto a VPN personales

Si tu empleador requiere una VPN corporativa para acceder a recursos internos, y quieres que el tráfico personal pase por una VPN diferente (orientada a la privacidad), el split tunneling en la VPN corporativa — enviando solo los rangos de IP corporativos a través de ella — deja el resto de tu tráfico disponible para la VPN personal. Esta es una configuración para usuarios avanzados, pero es una forma limpia de mantener separado el tráfico laboral del personal.

Cuándo NO usar split tunneling — las trampas de privacidad

El split tunneling hace que tu comportamiento de red sea más complejo, y el comportamiento de red complejo se filtra de formas no obvias. Los modos de fallo más comunes:

Fugas de DNS a través de la ruta de bypass

Incluso cuando el tráfico TCP de una aplicación se enruta fuera del túnel, sus consultas DNS pueden seguir configuradas para usar el resolvedor DNS de la VPN — o peor aún, pueden recurrir al resolvedor DNS del ISP si el cliente VPN no gestiona el DNS del sistema con cuidado. El resultado: una aplicación que debería ser invisible para tu ISP se vuelve parcialmente visible. El ISP ve la consulta DNS para banking.example.com aunque la posterior conexión TCP haya pasado por otro camino. Tenemos un análisis más detallado de cómo encaja el cifrado DNS en nuestra guía de DNS-over-HTTPS.

Confusión entre aplicación y dominio

El split tunneling por aplicación enruta por identidad de proceso, pero las aplicaciones modernas realizan conexiones a muchos dominios. Tu «aplicación de streaming» probablemente carga anuncios, telemetría, APIs de recomendaciones y endpoints de analíticas de docenas de dominios diferentes — algunos de los cuales son compartidos con aplicaciones que sí quieres tuneadas. Excluir la aplicación completa significa excluir todas esas conexiones. El split tunneling por dominio tiene el problema opuesto: una sola aplicación podría cargar el mismo dominio CDN tanto para el vídeo de streaming (que quieres sin protección) como para contenido que preferirías no revelar.

Fugas de IPv6

Muchas implementaciones de split tunneling fueron diseñadas cuando IPv4 era la única preocupación de enrutamiento. Si tu red tiene conectividad IPv6 y las reglas de split tunneling no incluyen explícitamente rutas IPv6, los paquetes que deberían estar tuneados pueden salir por IPv6 fuera del túnel. Esta es una de las fugas de VPN más comunes en 2026 y casi siempre está causada por una configuración incompleta de las reglas de split tunneling. Compruébalo con un test de fugas IPv6 después de activar el split tunneling.

Interacciones con el kill switch

Un kill switch está diseñado para bloquear todo el tráfico si la VPN cae, de modo que nada se filtre desprotegido. Con el split tunneling activado, la lógica del kill switch se complica — el kill switch aún debería permitir que las aplicaciones con split tunneling se comuniquen, pero solo esas, y solo cuando la propia VPN también esté caída. Muchos clientes VPN tienen errores por los que el kill switch falla al bloquear las aplicaciones tuneadas cuando la VPN cae, o bloquea incorrectamente las aplicaciones con split tunneling que deberían seguir funcionando. Prueba la combinación explícitamente.

Comparación de modos de split tunneling

Cómo funciona el split tunneling en cada sistema operativo

iOS — limitado e indirecto

iOS no expone una API de split tunneling real a las aplicaciones VPN de terceros. El framework NetworkExtension permite configurar una VPN de forma global (todo el tráfico) o por aplicación (solo las aplicaciones registradas explícitamente por un perfil MDM). El enrutamiento por aplicación real requiere NEAppProxyProvider de Apple con un perfil de configuración distribuido por MDM — es decir, un escenario de dispositivo gestionado. Las aplicaciones VPN de consumidor en iOS que anuncian «split tunneling» normalmente implementan exclusiones basadas en destino (p. ej., excluir rangos de IP específicos del túnel) o usan la API de reglas bajo demanda para activar condicionalmente la VPN según el SSID de Wi-Fi o la coincidencia de dominio. El split tunneling por aplicación para usuarios domésticos de iOS realmente no está disponible.

Android — soporte de primera clase

La API VpnService de Android admite el enrutamiento por aplicación de forma nativa. El cliente VPN puede llamar a addAllowedApplication() o addDisallowedApplication() para especificar qué aplicaciones pasan por el túnel. El sistema operativo gestiona el enrutamiento por aplicación de forma transparente — el cliente VPN no necesita hacer etiquetado a nivel de paquete. Android también admite la configuración del sistema «VPN siempre activa» con la opción «Bloquear conexiones sin VPN», que combina el comportamiento del kill switch con la configuración por aplicación: las aplicaciones tuneadas pasan por el túnel, las no tuneadas van directas, y si la VPN cae, las aplicaciones tuneadas se bloquean.

macOS — la implementación varía

macOS admite split tunneling a través de varios mecanismos: el framework NetworkExtension (similar a iOS, con más flexibilidad), filtros de paquetes configurados mediante reglas pf, o manipulación de la tabla de enrutamiento por clientes VPN que se ejecutan con privilegios elevados. El split tunneling por aplicación en macOS es viable, pero requiere que el cliente VPN consulte al núcleo los mapeos de socket a proceso. La división basada en destino es sencilla y confiable.

Windows — la plataforma más común para split tunneling

Los clientes VPN de Windows han usado split tunneling durante más de una década. La Windows Filtering Platform (WFP) proporciona la inspección de paquetes a nivel de núcleo y la API de decisión de enrutamiento en la que se enganchan los clientes VPN. El split tunneling por aplicación en Windows está bien soportado y ampliamente desplegado. La mayoría de las implementaciones VPN empresariales usan split tunneling de Windows para garantizar que el tráfico corporativo pase por el túnel corporativo mientras el tráfico de internet general va directo — en parte por rendimiento, en parte para reducir la carga en los concentradores VPN corporativos.

Errores comunes al configurar split tunneling

Observar cómo la gente configura mal el split tunneling revela algunos patrones recurrentes. Si lo configuras, comprueba que no incurres en ninguno de estos:

• No comprobar fugas de DNS después de activarlo. Realiza un test de fugas (dnsleaktest.com o similar) después de cada cambio de configuración. Si ves el resolvedor DNS de tu ISP listado para una aplicación que debería estar tuneada, el bypass está filtrando DNS.
• Olvidar que los navegadores son especiales. Un navegador que ejecuta una aplicación web de streaming enruta tanto el vídeo de streaming como tus otras pestañas a través del mismo proceso. Excluir el navegador excluye toda tu navegación. Usa un perfil de navegador separado o una aplicación diferente para el caso de streaming.
• No gestionar IPv6. Desactiva IPv6 completamente si tu cliente VPN no lo gestiona explícitamente. La tasa de fugas por reglas de split tunneling IPv6 olvidadas es alta.
• Usar reglas basadas en dominio para decisiones críticas de seguridad. El split tunneling basado en dominio está bien para ajustes de usabilidad. No es suficientemente confiable para imponer «esta aplicación sensible siempre debe pasar por la VPN» — para eso, usa reglas basadas en aplicación con la aplicación explícitamente tuneada, idealmente en modo lista de inclusión.
• No revisar las reglas trimestralmente. Las aplicaciones se añaden y eliminan; las nuevas aplicaciones del mismo editor no heredan nada de las anteriores. Audita periódicamente tu conjunto de reglas de split tunneling.

El veredicto honesto sobre el split tunneling

El split tunneling es genuinamente útil para problemas específicos — aplicaciones de streaming que detectan VPN, aplicaciones bancarias que marcan los inicios de sesión VPN, acceso a red local — y tiene una larga historia de implementación legítima en entornos empresariales. Para los usuarios domésticos, el enfoque honesto es que es una herramienta de usabilidad primero y una herramienta de privacidad segundo. Cada regla de split tunneling debilita el modelo de protección de alguna manera específica, y la concesión de seguridad solo vale la pena cuando la protección no hubiera ayudado de todas formas a ese tráfico (p. ej., una sesión bancaria que ya está cifrada con TLS y va a un único destino conocido).

Si tu modelo de amenaza es «quiero una VPN en redes Wi-Fi públicas hostiles para que el operador de la red local no pueda observar mi tráfico», un túnel completo es la respuesta correcta. No actives split tunneling solo porque el cliente VPN lo ofrezca — cada exclusión es un agujero. Si tu modelo de amenaza es «quiero que la mayor parte del tráfico esté protegido pero algunas aplicaciones específicas necesitan la red real», el split tunneling es la herramienta adecuada, pero configúralo con cuidado, comprueba las fugas de DNS e IPv6 posteriormente, y revisa las reglas periódicamente. La referencia técnica en la documentación de inicio rápido de WireGuard muestra cómo funcionan las decisiones de enrutamiento subyacentes a nivel de protocolo.

Casper's Cloak usa una arquitectura de túnel completo de forma predeterminada porque el modelo de amenaza contra el que protegemos — redes hostiles, vigilancia del ISP, rastreo publicitario — se beneficia del modelo más simple de «tuneliza todo». A esto añadimos filtrado de rastreadores en la capa DNS y detección de amenazas con IA para destinos maliciosos conocidos, de modo que el túnel completo también realiza filtrado activo — no solo enrutamiento. Para los casos excepcionales de streaming y banca, lo más adecuado suele ser desconectarse brevemente en lugar de mantener un conjunto permanente de exclusiones de split tunneling que acabarás olvidando.