Per què una aplicació d’Android bloquejada encara mostra consum de xarxa

Bloquegeu una aplicació al vostre tallafoc VPN d’Android, l’aplicació deixa de funcionar i la seva fila de consum continua pujant. La conclusió temptadora és que el bloqueig s’ha filtrat o que el comptador està espatllat. Cap de les dues no se’n segueix. Un registre de consum diu que es van atribuir bytes a aquella identitat en algun punt d’observació; no diu res sobre si un servei remot va acceptar una sol·licitud. Quan sabeu quina frontera s’ha mesurat i a quina identitat s’ha carregat, les dues observacions deixen de contradir-se.

El comptador mesura bytes, no lliurament

Android atribueix el trànsit a un UID i el compta en tots dos sentits, i ho fa en una frontera d’interfície, no en el moment en què una sol·licitud de l’aplicació té èxit.

Un intent de connexió refusat encara mou paquets: el SYN, el reset o les retransmissions que el segueixen, més la consulta DNS que va precedir tots dos. Aquests bytes existeixen encara que no s’hagi lliurat res, i en alguns camins es compten abans que cap filtre decideixi què fer-ne.

Per això la fila d’una aplicació bloquejada pot créixer mentre totes les sol·licituds fallen. El comptador respon «quants bytes s’han atribuït a aquesta identitat», no «aquesta identitat ha arribat a internet». Un gràfic no pot distingir un flux acceptat d’una encaixada de mans refusada educadament, i un total que suma tots dos sentits tampoc no ho pot fer.

L’atribució segueix l’UID, no la icona

La fila és per UID, i un UID pot ser compartit per més d’un paquet, mentre que una aplicació visible pot cedir la feina a un component separat que s’executa amb la seva pròpia identitat. Una pestanya del navegador dibuixada per un procés WebView compartit, un servei de sincronització en segon pla o un paquet acompanyant instal·lat al costat de l’aplicació principal produeixen trànsit que la pantalla de consum pot mostrar amb un nom que no esperàveu, o sota l’aplicació que sí que vau bloquejar. Un paquet bloquejat i un auxiliar que transporta les seves sol·licituds són dos subjectes diferents, i la regla només cobria un d’ells.

Quan les xifres semblin malament, compareu l’UID i no l’etiqueta. L’API de consum es consulta per UID, i adb shell dumpsys package <package> | grep userId= imprimeix el número amb què heu de comparar, de manera que dues entrades amb el mateix UID són la mateixa identitat des del punt de vista del comptador.

La finestra temporal pot ser anterior a la vostra regla

Les dades de consum es recullen en blocs i es consulten periòdicament, no s’emeten en directe. Un total diari pot incloure els minuts previs a activar el bloqueig, una sincronització en segon pla de l’hora anterior o trànsit que ja era en curs. Comparar un total acumulat amb una sola sol·licitud refusada i qualificar la diferència de filtració és un error de mesura, no una troballa del tallafoc.

Feu servir una finestra més curta i un inici net. Anoteu la marca de temps quan canvieu la regla, espereu un interval de recollida i mireu només les dades posteriors. Si el total continua pujant en una finestra que comença després de la regla, teniu alguna cosa a investigar; si deixa de pujar, el creixement anterior era història que es mostrava.

El servei VPN pot no ser el que vau configurar

Un tallafoc VPN només veu el trànsit que transporta el seu propi servei. Si una altra aplicació VPN s’inicia i pren la connexió activa, el vostre filtre ja no és al camí mentre la seva interfície encara existeix als paràmetres. Les llistes d’exclusió per aplicació fan el mateix deliberadament, i un perfil que exclou una aplicació no és una filtració quan l’aplicació després funciona.

IPv4, IPv6 i DNS també poden divergir. Un filtre que gestiona IPv4 pot deixar IPv6 o un resolutor DNS privat fora d’ell, de manera que part del trànsit de l’aplicació segueix un camí que les vostres regles mai no van descriure. Comproveu quina aplicació posseeix actualment la VPN i què diu la llista d’exclusions abans de reescriure res:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

Proveu una sol·licitud nova i anoteu quatre fets

Trieu una sol·licitud innòcua, feu-la una vegada i anoteu quatre fets: la regla vigent, l’UID de l’aplicació, l’estat de la xarxa i l’hora. Després comproveu si el vostre filtre va registrar el flux i si la destinació o la porta d’enllaç van veure la mateixa connexió. Un flux identificat als dos costats és una prova; un total agregat no ho és.

Una conclusió defensable anomena què es va denegar i quina observació ho va confirmar. «El comptador va pujar» no és una troballa, i «tots els comptadors de consum són falsos» tampoc no ho és. Un eslògan de capa OSI no resol això: la resposta honesta és que el comptador i el bloqueig poden ser tots dos correctes mentre descriuen coses diferents. La referència NetworkStatsManager d’Android documenta com es consulten i s’atribueixen aquests blocs.