¿Bloqueará tu interruptor de seguridad la aplicación que excluiste del túnel?
Una aplicación excluida puede ir directa a propósito, mientras que una protegida debe fallar cerrada. Escribe primero la política por aplicación y después comprueba qué aplica el cliente.
Interruptor de seguridad activado, una aplicación excluida deliberadamente del túnel y los dos requisitos ahora se contradicen. Uno dice que nada puede salir excepto por el túnel, el otro dice que este programa debe ir directo. Cada cliente resuelve ese conflicto de forma distinta, y la página de ajustes rara vez explica qué regla gana. Escribe la política por aplicación antes de fiarte de cualquier etiqueta.
Dos políticas, una máquina
Un interruptor de seguridad es una promesa sobre el fallo: cuando el túnel no protege el tráfico, el tráfico se detiene. El túnel dividido es una promesa sobre la selección: estos programas o destinos usan el túnel, y aquellos no. La segunda promesa crea tráfico sobre el que la primera debe decidir. Ninguna promesa es errónea; simplemente las escribieron personas distintas para amenazas distintas.
Hay tres resultados posibles y solo uno es el que pretendía el despliegue. La aplicación excluida puede quedarse directa durante una caída, lo que respeta la división y rompe el interruptor. Puede quedar bloqueada con todo lo demás, lo que respeta el interruptor y rompe la división. O puede bloquearse solo a veces, según cómo evalúe la plataforma la regla después de que desaparezca una interfaz. Ese último caso es el que genera incidencias.
Escribe la lista de aplicaciones antes de la regla
Enumera los programas que deben usar el túnel, los que deben ir directos y los nombres o destinos que nunca deben aparecer en ninguna de las dos listas. Incluye por separado el comportamiento del resolutor y el lado IPv6, porque ambos pueden seguir una política distinta de la del tráfico de páginas.
Las reglas por aplicación suelen coincidir con un ejecutable o un paquete, no con un perfil dentro de él. Un perfil de navegador, una ventana privada y una extensión no llevan identidad de red propia, así que heredan lo que recibió el proceso. Un proceso auxiliar lanzado por ese navegador puede no heredar la misma regla en absoluto.
Hacen falta dos listas, no una: lo que el túnel debe transportar y lo que nunca debe viajar fuera de él por ningún motivo. Una aplicación que aparece en ambas es un conflicto de requisitos y no un detalle de implementación, y hay que resolverlo antes de configurar el cliente.
Qué hace el cliente durante una caída
Algunas implementaciones bloquean las aplicaciones excluidas durante una caída y les devuelven el acceso al reconectar. Otras conservan la ruta directa en todo momento, lo que concuerda con la división y es más débil como propiedad de seguridad. El bloqueo a nivel de plataforma puede anular por completo la selección por aplicación del cliente. Esa diferencia no es cosmética, porque decide si la aplicación excluida es una excepción de política o un agujero.
La VPN siempre activa de Android con la opción de bloquear las conexiones sin VPN es el caso más claro, porque la plataforma impone el bloqueo y no el cliente, y el paquete excluido queda bloqueado con todo lo demás mientras el túnel está caído. Un cliente de escritorio que aplica exclusiones por aplicación dentro de su propio controlador suele dejar el proceso excluido en la interfaz física, porque nunca fue dueño del tráfico de ese proceso. Ambas conductas son defendibles y solo una encaja con un requisito que diga que la aplicación excluida debe seguir siendo utilizable. Pregunta qué componente impone la regla antes de interpretar el resultado.
Lee el comportamiento del sistema operativo que tienes delante y no el ajuste con el mismo nombre en otro sitio. Las API de aplicación difieren, y una casilla puede significar cosas estrictamente distintas en un escritorio y en un teléfono. La versión también importa, porque el control de bloqueo ha cambiado de pantalla entre versiones de Android, y una lista de exclusiones del lado del cliente no es el mismo control que un bloqueo de plataforma.
Tres momentos: túnel activo, túnel caído, reconexión
Usa peticiones inocuas en tres momentos: mientras el túnel funciona, durante el fallo que te importa y después de reconectar. Un solo resultado del navegador no puede establecer el comportamiento de la aplicación excluida.
curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com
La dirección de salida muestra qué camino se tomó, y la prueba explícita de interfaz muestra qué ocurre cuando el túnel es la única salida disponible. Anota el resultado esperado junto a cada línea antes de ejecutar cualquiera de ellas, o la salida se interpretará a posteriori.
Si una aplicación excluida se queda sin conexión, revisa la precedencia de políticas antes de añadir un permiso amplio en el cortafuegos, porque esa corrección destruye la distinción que estabas probando. Si sigue directa, confirma que era la excepción documentada y no un retroceso accidental. Para un requisito estricto de todo el dispositivo, acorta la lista de excepciones hasta que se pueda probar a mano.