Per què el túnel dividit no cobreix les actualitzacions de la teva aplicació

Afegiu l’aplicació a la llista d’exclusions del túnel dividit, l’aplicació arriba a internet directament i les actualitzacions segueixen fallant o segueixen arrossegant-se pel túnel. L’exclusió va funcionar. Només va cobrir un procés diferent del que fa la descàrrega, perquè un actualitzador modern poques vegades és el mateix executable que la finestra de l’aplicació.

El mite: excloure l’aplicació exclou el seu trànsit

El túnel dividit per aplicació fa coincidir un procés, un paquet o un camí d’aplicació, segons la plataforma. No fa coincidir una marca, una funció ni una intenció de l’usuari. Quan l’aplicació lliura la descàrrega a un auxiliar, a un servei compartit de la plataforma o a un component del navegador, aquest auxiliar té la seva pròpia identitat i el seu propi camí pel túnel. La llista d’exclusions no té ni idea que els dos processos pertanyen al mateix producte. Només sap quin heu nomenat.

Així, la regla fa exactament el que se li va dir. La suposició sobre qui posseeix la transferència era errònia, i la solució comença per identificar aquest propietari en lloc d’afegir més exclusions.

Troba el propietari de la transferència

A Android, l’actualització es pot obtenir mitjançant un paquet de servei compartit en lloc del paquet de l’aplicació que heu exclòs, i una regla de VPN per aplicació s’aplica al paquet que obre el socket. A Windows, un servei d’actualització pot executar-se sota un camí executable diferent del de l’aplicació, de manera que una regla que coincideix amb el camí de l’aplicació no el detecta. A macOS, un auxiliar privilegiat o un dimoni d’actualització del sistema pot fer la transferència mentre l’aplicació només la sol·licita.

Identifiqueu el propietari a partir d’evidències: la vista d’activitat de xarxa de la plataforma, una captura de paquets filtrada per procés o la documentació del proveïdor que anomena el component d’actualització. Endevinar a partir del nom del procés és com es confonen dos binaris semblants i s’exclou el que no toca.

Els sistemes d’actualització sovint també divideixen la feina. Una petita sol·licitud de metadades comprova una versió, i una descàrrega de paquet molt més gran va a un amfitrió de lliurament de contingut o a un domini diferent. La comprovació de metadades pot tenir èxit a través del túnel mentre la transferència del paquet s’encalla en un amfitrió que el túnel encamina d’una altra manera. Aquesta divisió explica l’informe confús en què es detecten actualitzacions però mai s’instal·len. Proveu la descàrrega del paquet en si, des del mateix dispositiu i la mateixa xarxa, en lloc de provar si l’aplicació s’obre.

La verificació sobreviu a un canvi de ruta

Canviar una ruta no substitueix TLS, la identitat de l’editor ni la verificació de la signatura del paquet. No desactiveu aquestes comprovacions perquè una descàrrega només té èxit després de passar per un avís de certificat inexplicat. Un avís que només apareix al camí exclòs és una troballa, no un obstacle. Investigueu-lo abans d’ampliar l’elusió.

En un dispositiu gestionat, demaneu una excepció admesa en lloc d’afegir una regla àmplia per a cada servei del sistema. Una regla que exclou tots els serveis compartits per arreglar un sol actualitzador amplia l’elusió molt més enllà de la sol·licitud original.

Proveu l’actualització i després documenteu el propietari

Torneu a connectar després del canvi i verifiqueu de nou la regla aplicada, perquè alguns clients reconstrueixen l’encaminament quan el túnel es reconnecta. Feu un cicle complet d’actualització: comprovar, baixar, verificar i instal·lar. Una comprovació correcta demostra la part més petita del camí.

Registreu el propietari de la transferència, els amfitrions de destinació i la ruta prevista al mateix lloc que la regla del túnel dividit. En cas contrari, el proper canvi del mecanisme d’actualització invalidarà silenciosament l’excepció, i qui la hereti no tindrà manera de saber per a quin procés es va escriure la regla.