Pourquoi le tunneling divisé ne couvre pas les mises à jour de votre application

Vous ajoutez l’application à la liste d’exclusions du tunneling divisé, l’application atteint internet directement, et les mises à jour échouent toujours ou continuent de ramper dans le tunnel. L’exclusion a fonctionné. Elle a simplement couvert un autre processus que celui qui effectue le téléchargement, car un programme de mise à jour moderne est rarement le même exécutable que la fenêtre de l’application.

Le mythe : exclure l’application exclut son trafic

Le tunneling divisé par application associe un processus, un paquet ou un chemin d’application, selon la plateforme. Il n’associe pas une marque, une fonction ni une intention d’utilisateur. Quand l’application confie le téléchargement à un assistant, à un service partagé de la plateforme ou à un composant du navigateur, cet assistant a sa propre identité et son propre chemin dans le tunnel. La liste d’exclusions ne se doute pas que les deux processus appartiennent au même produit. Elle sait seulement lequel vous avez nommé.

La règle fait donc exactement ce qu’on lui a dit. L’hypothèse sur qui possède le transfert était fausse, et la correction commence par identifier ce propriétaire plutôt que par ajouter d’autres exclusions.

Trouvez le propriétaire du transfert

Sur Android, la mise à jour peut être récupérée par un paquet de service partagé plutôt que par le paquet de l’application que vous avez exclu, et une règle VPN par application s’applique au paquet qui ouvre la socket. Sur Windows, un service de mise à jour peut s’exécuter sous un chemin exécutable différent de celui de l’application, si bien qu’une règle qui correspond au chemin de l’application le rate. Sur macOS, un assistant privilégié ou un démon de mise à jour du système peut effectuer le transfert pendant que l’application ne fait que le demander.

Identifiez le propriétaire à partir de preuves : la vue d’activité réseau de la plateforme, une capture de paquets filtrée par processus ou la documentation du fournisseur qui nomme le composant de mise à jour. Deviner à partir du nom du processus, c’est ainsi que deux binaires similaires sont confondus et que le mauvais est exclu.

Les systèmes de mise à jour divisent souvent aussi le travail. Une petite requête de métadonnées vérifie une version, et un téléchargement de paquet bien plus volumineux part vers un hôte de diffusion de contenu ou un autre domaine. La vérification des métadonnées peut réussir à travers le tunnel pendant que le transfert du paquet bloque sur un hôte que le tunnel route autrement. Cette division explique le rapport déroutant où des mises à jour sont détectées mais jamais installées. Testez le téléchargement du paquet lui-même, depuis le même appareil et le même réseau, plutôt que de tester si l’application s’ouvre.

La vérification survit à un changement de route

Changer une route ne remplace ni TLS, ni l’identité de l’éditeur, ni la vérification de la signature du paquet. Ne désactivez pas ces contrôles parce qu’un téléchargement ne réussit qu’après avoir ignoré un avertissement de certificat inexplicable. Un avertissement qui n’apparaît que sur le chemin exclu est une constatation, pas un obstacle. Examinez-le avant d’élargir le contournement.

Sur un appareil géré, demandez une exception prise en charge au lieu d’ajouter une règle large pour chaque service système. Une règle qui exclut tous les services partagés pour réparer un seul programme de mise à jour élargit le contournement bien au-delà de la demande initiale.

Testez la mise à jour, puis documentez le propriétaire

Reconnectez-vous après le changement et vérifiez à nouveau la règle appliquée, car certains clients reconstruisent leur routage quand le tunnel se reconnecte. Effectuez un cycle de mise à jour complet : vérifier, télécharger, vérifier et installer. Une vérification réussie ne prouve que la plus petite partie du chemin.

Consignez le propriétaire du transfert, les hôtes de destination et la route prévue au même endroit que la règle de tunneling divisé. Sinon, le prochain changement du mécanisme de mise à jour invalidera silencieusement l’exception, et la personne qui en héritera n’aura aucun moyen de savoir pour quel processus la règle a été écrite.