O túnel dividido segue excluíndo unha app que desinstalaches

A app antiga xa non está, e a lista do túnel dividido aínda ten unha entrada para ela. Nada se rompe de forma visible, e por iso queda alí durante meses. Despois alguén instala outro programa no mesmo cartafol, ou un perfil xestionado restaura a regra en cada reconexión, e o tráfico comeza a coller unha ruta que ninguén planificara. A exclusión sobreviviu ao motivo polo que existía.

Limpar isto ten que ver sobre todo coa identidade: a que apunta agora a regra e quen é o dono da lista.

O síntoma: unha exclusión que non coincide con nada

Unha entrada obsoleta é invisible no uso normal. Faise visible de tres maneiras: unha aplicación que esperabas que pasase polo túnel vai directa, un programa novo herda unha excepción antiga, ou o cliente négase a gardar unha edición porque o perfil xestionado a sobrescribe. As tres parecen fallos separados, e as tres son o mesmo problema de contabilidade. Cada unha é barata de comprobar e cara de diagnosticar mal.

Comeza lendo a regra, non borrándoa.

Descubre que identifica a regra

As implementacións do túnel dividido basean as exclusións en cousas distintas: unha ruta executábel, un nome de paquete, un identificador de paquete ou unha ruta de rede. Unha regra baseada na ruta apunta a un ficheiro que pode que xa non exista, ou que agora pode ser outro ficheiro. Unha regra baseada no paquete apunta a unha identidade que unha instalación nova pode reutilizar. Le a documentación do cliente para o campo que estás mirando, porque a mesma caixa de texto significa cousas distintas en produtos distintos. A guía de VpnService de Android é a referencia para o caso baseado en paquetes.

O nome mostrado é a parte menos fiable da entrada, e é a parte que le a xente.

As regras de ruta e as regras de paquete compórtanse de xeito distinto

Unha regra de ruta que sobrevive a unha desinstalación adoita quedar inerte, e inerte é o bo resultado. O mal resultado é unha ruta que se reutiliza, porque o novo executábel herda a excepción en silencio. As regras de paquete compórtanse doutro xeito: un produto pode ignorar un paquete non dispoñible, rexeitalo ou seguir coincidindo por nome cando algo novo reclama ese nome.

Non traslades unha suposición dun cliente a outro. Comproba que fai o teu cun destino ausente, idealmente creando a condición a propósito nunha máquina de probas e observando que proceso herda a excepción.

Elimínaa a través do propietario

Se a lista vén dun perfil xestionado, editala localmente é un cambio temporal que se restaurará na próxima reconexión. Cambia o perfil ou pregúntalle a quen o posúe, e confirma que a edición sobrevive a unha reconexión. Se a lista é local, elimina a entrada e comproba que o cliente reescribiu a súa configuración en lugar de manter a antiga en memoria.

Unha lista baleira non é o obxectivo. O obxectivo é unha lista cuxas entradas aínda responden a requisitos reais.

Despois proba as dúas direccións

Despois da limpeza, proba unha app que aínda debería estar excluída e unha app que agora debería pasar polo túnel. Confirma o comportamento de DNS por separado, porque a política do resolutor é un control distinto da lista de exclusións. Despois reconecta unha vez e volve probar, xa que un perfil restaurado é a forma máis habitual de que unha limpeza se desfaga en silencio.

Mantén un propósito dunha liña xunto a cada excepción restante. Esa liña é o que impide que a lista se converta nun museo, e fai que a próxima limpeza sexa un traballo de cinco minutos.