Le tunnel fractionné exclut toujours une application que vous avez désinstallée

L’ancienne application a disparu, et la liste du tunnel fractionné contient toujours une entrée pour elle. Rien ne casse visiblement, et c’est pourquoi elle reste là pendant des mois. Puis quelqu’un installe un autre programme dans le même dossier, ou un profil géré restaure la règle à chaque reconnexion, et le trafic commence à emprunter un chemin que personne n’avait prévu. L’exclusion a survécu à la raison pour laquelle elle existait.

Nettoyer cela relève surtout de l’identité : vers quoi la règle pointe maintenant, et à qui appartient la liste.

Le symptôme : une exclusion qui ne correspond à rien

Une entrée obsolète est invisible en usage normal. Elle devient visible de trois manières : une application que vous pensiez acheminée par le tunnel passe en direct, un nouveau programme hérite d’une ancienne exception, ou le client refuse d’enregistrer une modification parce que le profil géré l’écrase. Les trois ressemblent à des bogues distincts, et les trois sont le même problème de tenue de registre. Chacune est peu coûteuse à vérifier et coûteuse à mal diagnostiquer.

Commencez par lire la règle, pas par la supprimer.

Découvrez ce que la règle identifie

Les implémentations du tunnel fractionné fondent les exclusions sur des éléments différents : un chemin d’exécutable, un nom de paquet, un identifiant de paquet ou une route. Une règle fondée sur le chemin pointe vers un fichier qui peut ne plus exister, ou qui peut désormais être un autre fichier. Une règle fondée sur le paquet pointe vers une identité qu’une nouvelle installation peut réutiliser. Lisez la documentation du client pour le champ que vous regardez, car la même zone de texte signifie des choses différentes selon les produits. Le guide VpnService d’Android est la référence pour le cas fondé sur le paquet.

Le nom affiché est la partie la moins fiable de l’entrée, et c’est celle que les gens lisent.

Les règles de chemin et les règles de paquet se comportent différemment

Une règle de chemin qui survit à une désinstallation devient généralement inerte, et inerte est le bon résultat. Le mauvais résultat est un chemin réutilisé, car le nouvel exécutable hérite silencieusement de l’exception. Les règles de paquet se comportent encore autrement : un produit peut ignorer un paquet indisponible, le rejeter, ou continuer à correspondre par nom quand quelque chose de nouveau revendique ce nom.

Ne transposez pas une hypothèse d’un client à l’autre. Vérifiez ce que le vôtre fait réellement avec une cible absente, idéalement en créant la condition exprès sur une machine de test et en observant quel processus hérite de l’exception.

Supprimez-la via le propriétaire

Si la liste provient d’un profil géré, la modifier localement est un changement temporaire qui sera restauré à la prochaine reconnexion. Modifiez le profil, ou demandez à celui qui le possède, et confirmez que la modification survit à une reconnexion. Si la liste est locale, supprimez l’entrée et vérifiez que le client a réécrit sa configuration au lieu de garder l’ancienne en mémoire.

Une liste vide n’est pas l’objectif. L’objectif est une liste dont les entrées correspondent encore à des exigences réelles.

Testez ensuite les deux directions

Après le nettoyage, testez une application qui devrait encore être exclue et une application qui devrait maintenant passer par le tunnel. Confirmez le comportement DNS séparément, car la politique du résolveur est un contrôle différent de la liste d’exclusions. Puis reconnectez-vous une fois et retestez, car un profil restauré est le moyen le plus courant pour qu’un nettoyage s’annule tout seul.

Gardez un objet d’une ligne à côté de chaque exception restante. Cette ligne est ce qui empêche la liste de devenir un musée, et elle fait du prochain nettoyage un travail de cinq minutes.