El túnel dividido sigue excluyendo una app que desinstalaste

La app antigua ya no está, y la lista del túnel dividido todavía tiene una entrada para ella. Nada se rompe de forma visible, y por eso se queda ahí durante meses. Luego alguien instala otro programa en la misma carpeta, o un perfil gestionado restaura la regla en cada reconexión, y el tráfico empieza a tomar una ruta que nadie había planificado. La exclusión sobrevivió al motivo por el que existía.

Limpiar esto tiene que ver sobre todo con la identidad: a qué apunta ahora la regla y quién es dueño de la lista.

El síntoma: una exclusión que no coincide con nada

Una entrada obsoleta es invisible en el uso normal. Se vuelve visible de tres maneras: una aplicación que esperabas que pasara por el túnel va directa, un programa nuevo hereda una excepción antigua, o el cliente se niega a guardar una edición porque el perfil gestionado la sobrescribe. Las tres parecen fallos separados, y las tres son el mismo problema de contabilidad. Cada una es barata de comprobar y cara de diagnosticar mal.

Empieza leyendo la regla, no borrándola.

Averigua qué identifica la regla

Las implementaciones del túnel dividido basan las exclusiones en cosas distintas: una ruta ejecutable, un nombre de paquete, un identificador de paquete o una ruta de red. Una regla basada en ruta apunta a un archivo que puede que ya no exista, o que ahora puede ser otro archivo. Una regla basada en paquete apunta a una identidad que una instalación nueva puede reutilizar. Lee la documentación del cliente para el campo que estás mirando, porque el mismo cuadro de texto significa cosas distintas en distintos productos. La guía de VpnService de Android es la referencia para el caso basado en paquetes.

El nombre mostrado es la parte menos fiable de la entrada, y es la parte que lee la gente.

Las reglas de ruta y las reglas de paquete se comportan de forma distinta

Una regla de ruta que sobrevive a una desinstalación suele quedar inerte, e inerte es el buen resultado. El mal resultado es una ruta que se reutiliza, porque el nuevo ejecutable hereda la excepción en silencio. Las reglas de paquete se comportan de otra manera: un producto puede ignorar un paquete no disponible, rechazarlo o seguir coincidiendo por nombre cuando algo nuevo reclama ese nombre.

No traslades una suposición de un cliente a otro. Comprueba qué hace el tuyo con un destino ausente, idealmente creando la condición a propósito en una máquina de pruebas y observando qué proceso hereda la excepción.

Elimínala a través del propietario

Si la lista viene de un perfil gestionado, editarla localmente es un cambio temporal que se restaurará en la próxima reconexión. Cambia el perfil o pregunta a quien lo posea, y confirma que la edición sobrevive a una reconexión. Si la lista es local, elimina la entrada y comprueba que el cliente reescribió su configuración en lugar de mantener la antigua en memoria.

Una lista vacía no es el objetivo. Lo es una lista cuyas entradas todavía responden a requisitos reales.

Después prueba ambas direcciones

Después de la limpieza, prueba una app que todavía debería estar excluida y una app que ahora debería pasar por el túnel. Confirma el comportamiento de DNS por separado, porque la política del resolutor es un control distinto de la lista de exclusiones. Luego reconecta una vez y vuelve a probar, ya que un perfil restaurado es la forma más habitual en que una limpieza se deshace en silencio.

Mantén un propósito de una línea junto a cada excepción restante. Esa línea es lo que impide que la lista se convierta en un museo, y hace que la próxima limpieza sea un trabajo de cinco minutos.