El túnel dividit encara exclou una aplicació que has desinstal·lat

L’aplicació antiga ja no hi és, i la llista del túnel dividit encara té una entrada per a ella. Res no es trenca visiblement, i per això es queda allà durant mesos. Aleshores algú instal·la un altre programa a la mateixa carpeta, o un perfil gestionat restaura la regla a cada reconnexió, i el trànsit comença a agafar un camí que ningú havia planificat. L’exclusió ha sobreviscut al motiu pel qual existia.

Netejar això tracta sobretot d’identitat: a què apunta ara la regla i qui és el propietari de la llista.

El símptoma: una exclusió que no coincideix amb res

Una entrada obsoleta és invisible en l’ús normal. Es fa visible de tres maneres: una aplicació que esperaves que passés pel túnel va directa, un programa nou hereta una excepció antiga, o el client es nega a desar una edició perquè el perfil gestionat la sobreescriu. Les tres semblen errors separats, i les tres són el mateix problema de comptabilitat. Cadascuna és barata de comprovar i cara de diagnosticar malament.

Comença llegint la regla, no esborrant-la.

Esbrina què identifica la regla

Les implementacions del túnel dividit basen les exclusions en coses diferents: un camí executable, un nom de paquet, un identificador de paquet o una ruta. Una regla basada en el camí apunta a un fitxer que potser ja no existeix, o que ara pot ser un fitxer diferent. Una regla basada en el paquet apunta a una identitat que una instal·lació nova pot reutilitzar. Llegeix la documentació del client per al camp que estàs mirant, perquè la mateixa caixa de text significa coses diferents segons el producte. La guia de VpnService d’Android és la referència per al cas basat en paquets.

El nom mostrat és la part menys fiable de l’entrada, i és la part que llegeix la gent.

Les regles de camí i les regles de paquet es comporten de manera diferent

Una regla de camí que sobreviu a una desinstal·lació normalment queda inerta, i inert és el bon resultat. El mal resultat és un camí que es reutilitza, perquè el nou executable hereta l’excepció sense fer soroll. Les regles de paquet es comporten encara d’una altra manera: un producte pot ignorar un paquet no disponible, rebutjar-lo o continuar coincidint pel nom quan alguna cosa nova reclama aquest nom.

No traslladis una suposició d’un client a un altre. Comprova què fa realment el teu amb un objectiu absent, idealment creant la condició deliberadament en una màquina de proves i observant quin procés hereta l’excepció.

Elimina-la a través del propietari

Si la llista ve d’un perfil gestionat, editar-la localment és un canvi temporal que es restaurarà a la propera reconnexió. Canvia el perfil o pregunta a qui el posseeix, i confirma que l’edició sobreviu a una reconnexió. Si la llista és local, elimina l’entrada i comprova que el client ha reescrit la seva configuració en lloc de mantenir l’antiga en memòria.

Una llista buida no és l’objectiu. Ho és una llista les entrades de la qual encara responen a requisits reals.

Després prova les dues direccions

Després de la neteja, prova una aplicació que encara hauria d’estar exclosa i una aplicació que ara hauria de passar pel túnel. Confirma el comportament del DNS per separat, perquè la política del resolutor és un control diferent de la llista d’exclusions. Després reconnecta una vegada i torna a provar, ja que un perfil restaurat és la manera més habitual que una neteja es desfaci silenciosament.

Mantén un propòsit d’una línia al costat de cada excepció restant. Aquesta línia és el que impedeix que la llista es converteixi en un museu, i fa que la propera neteja sigui una feina de cinc minuts.