Por que o túnel dividido non cobre as actualizacións da túa aplicación

Engades a aplicación á lista de exclusións do túnel dividido, a aplicación chega a internet directamente e as actualizacións seguen fallando ou seguen arrastrándose polo túnel. A exclusión funcionou. Só cubriu un proceso distinto do que fai a descarga, porque un actualizador moderno raramente é o mesmo executable que a xanela da aplicación.

O mito: excluír a aplicación exclúe o seu tráfico

O túnel dividido por aplicación fai coincidir un proceso, un paquete ou unha ruta de aplicación, segundo a plataforma. Non fai coincidir unha marca, unha función nin unha intención do usuario. Cando a aplicación entrega a descarga a un axudante, a un servizo compartido da plataforma ou a un compoñente do navegador, ese axudante ten a súa propia identidade e a súa propia ruta polo túnel. A lista de exclusións non ten nin idea de que os dous procesos pertencen ao mesmo produto. Só sabe cal nomeaches.

Así que a regra fai exactamente o que se lle dixo. A suposición sobre quen é dono da transferencia era errónea, e a solución comeza por identificar a ese dono en lugar de engadir máis exclusións.

Atopa o dono da transferencia

En Android, a actualización pode obtela un paquete de servizo compartido en lugar do paquete da aplicación que excluíches, e unha regra de VPN por aplicación aplícase ao paquete que abre o socket. En Windows, un servizo de actualización pode executarse baixo unha ruta executable distinta da aplicación, así que unha regra que coincide coa ruta da aplicación non o detecta. En macOS, un axudante privilexiado ou un demonio de actualización do sistema pode realizar a transferencia mentres a aplicación só a solicita.

Identifica o dono a partir de probas: a vista de actividade de rede da plataforma, unha captura de paquetes filtrada por proceso ou a documentación do provedor que nomea o compoñente de actualización. Adiviñar a partir do nome do proceso é como se confunden dous binarios parecidos e se exclúe o equivocado.

Os sistemas de actualización tamén adoitan dividir o traballo. Unha pequena solicitude de metadatos comproba unha versión, e unha descarga de paquete moito maior vai a un host de entrega de contido ou a un dominio distinto. A comprobación de metadatos pode ter éxito a través do túnel mentres a transferencia do paquete se atasca nun host que o túnel encamiña doutro xeito. Esa división explica o informe confuso no que se detectan actualizacións pero nunca se instalan. Proba a descarga do paquete en si, desde o mesmo dispositivo e a mesma rede, en lugar de probar se a aplicación se abre.

A verificación sobrevive a un cambio de ruta

Cambiar unha ruta non substitúe TLS, a identidade do editor nin a verificación da sinatura do paquete. Non desactives esas comprobacións porque unha descarga só funciona despois de pasar un aviso de certificado sen explicación. Un aviso que aparece só na ruta excluída é un achado, non un obstáculo. Investígao antes de ampliar a elusión.

Nun dispositivo xestionado, pide unha excepción admitida en lugar de engadir unha regra ampla para cada servizo do sistema. Unha regra que exclúe todos os servizos compartidos para arranxar un só actualizador amplía a elusión moito máis alá da solicitude orixinal.

Proba a actualización e despois documenta o dono

Volve conectarte despois do cambio e verifica de novo a regra aplicada, porque algúns clientes reconstruen o seu encamiñamento cando o túnel se reconecta. Executa un ciclo completo de actualización: comprobar, descargar, verificar e instalar. Unha comprobación exitosa demostra só a parte máis pequena da ruta.

Rexistra o dono da transferencia, os hosts de destino e a ruta prevista no mesmo lugar que a regra do túnel dividido. Se non, o seguinte cambio do mecanismo de actualización invalidará a excepción en silencio, e quen a herde non terá forma de saber para que proceso se escribiu a regra.