Por qué el túnel dividido no cubre las actualizaciones de tu app

Añades la aplicación a la lista de exclusiones del túnel dividido, la app llega a internet directamente y las actualizaciones siguen fallando o siguen arrastrándose por el túnel. La exclusión funcionó. Solo cubrió un proceso distinto del que hace la descarga, porque un actualizador moderno rara vez es el mismo ejecutable que la ventana de la aplicación.

El mito: excluir la app excluye su tráfico

El túnel dividido por aplicación hace coincidir un proceso, un paquete o una ruta de aplicación, según la plataforma. No hace coincidir una marca, una función ni una intención del usuario. Cuando la aplicación entrega la descarga a un auxiliar, a un servicio compartido de la plataforma o a un componente del navegador, ese auxiliar tiene su propia identidad y su propia ruta por el túnel. La lista de exclusiones no tiene ni idea de que los dos procesos pertenecen al mismo producto. Solo sabe cuál nombraste.

Así que la regla hace exactamente lo que se le dijo. La suposición sobre quién es dueño de la transferencia era errónea, y la solución empieza por identificar a ese dueño en lugar de añadir más exclusiones.

Encuentra al dueño de la transferencia

En Android, la actualización puede obtenerla un paquete de servicio compartido en lugar del paquete de la app que excluiste, y una regla de VPN por aplicación se aplica al paquete que abre el socket. En Windows, un servicio de actualización puede ejecutarse bajo una ruta ejecutable distinta de la aplicación, así que una regla que coincide con la ruta de la app no lo detecta. En macOS, un auxiliar privilegiado o un demonio de actualización del sistema puede realizar la transferencia mientras la app solo la solicita.

Identifica al dueño a partir de pruebas: la vista de actividad de red de la plataforma, una captura de paquetes filtrada por proceso o la documentación del proveedor que nombra el componente de actualización. Adivinar a partir del nombre del proceso es como se confunden dos binarios parecidos y se excluye el equivocado.

Los sistemas de actualización también suelen dividir el trabajo. Una pequeña solicitud de metadatos comprueba una versión, y una descarga de paquete mucho mayor va a un host de entrega de contenido o a un dominio distinto. La comprobación de metadatos puede salir bien a través del túnel mientras la transferencia del paquete se atasca en un host que el túnel enruta de otra manera. Esa división explica el informe confuso en el que se detectan actualizaciones pero nunca se instalan. Prueba la descarga del paquete en sí, desde el mismo dispositivo y la misma red, en lugar de probar si la aplicación se abre.

La verificación sobrevive a un cambio de ruta

Cambiar una ruta no sustituye TLS, la identidad del editor ni la verificación de la firma del paquete. No desactives esas comprobaciones porque una descarga solo funciona después de pasar un aviso de certificado sin explicación. Un aviso que aparece solo en la ruta excluida es un hallazgo, no un obstáculo. Investígalo antes de ampliar la elusión.

En un dispositivo gestionado, pide una excepción admitida en lugar de añadir una regla amplia para cada servicio del sistema. Una regla que excluye todos los servicios compartidos para arreglar un solo actualizador amplía la elusión mucho más allá de la solicitud original.

Prueba la actualización y luego documenta al dueño

Vuelve a conectarte después del cambio y verifica de nuevo la regla aplicada, porque algunos clientes reconstruyen su enrutamiento cuando el túnel se reconecta. Ejecuta un ciclo completo de actualización: comprobar, descargar, verificar e instalar. Una comprobación exitosa demuestra solo la parte más pequeña de la ruta.

Registra al dueño de la transferencia, los hosts de destino y la ruta prevista en el mismo lugar que la regla del túnel dividido. De lo contrario, el siguiente cambio del mecanismo de actualización invalidará la excepción en silencio, y quien la herede no tendrá forma de saber para qué proceso se escribió la regla.