Perché un’app Android bloccata mostra ancora traffico di rete

Bloccate un’app nel vostro firewall VPN di Android, l’app smette di funzionare e la sua riga di consumo continua a salire. La conclusione tentante è che il blocco sia trapelato, o che il contatore sia guasto. Nessuna delle due consegue. Un registro dei consumi dice che dei byte sono stati attribuiti a quell’identità in un certo punto di osservazione; non dice nulla sul fatto che un servizio remoto abbia accettato una richiesta. Una volta che sapete quale frontiera è stata misurata e a quale identità è stata addebitata, le due osservazioni smettono di contraddirsi.

Il contatore misura byte, non consegna

Android attribuisce il traffico a un UID e lo conta in entrambe le direzioni, e lo fa a una frontiera di interfaccia anziché nel momento in cui la richiesta di un’app riesce.

Un tentativo di connessione rifiutato muove comunque pacchetti: il SYN, il reset o le ritrasmissioni che seguono, più la query DNS che li ha preceduti entrambi. Quei byte esistono anche se nulla è stato consegnato, e su alcuni percorsi vengono contati prima che qualsiasi filtro decida cosa farne.

Ecco perché la riga di un’app bloccata può crescere mentre ogni richiesta fallisce. Il contatore risponde a «quanti byte sono stati attribuiti a questa identità», non a «questa identità ha raggiunto internet». Un grafico non può distinguere un flusso accettato da una stretta di mano rifiutata con cortesia, e nemmeno un totale che somma entrambe le direzioni.

L’attribuzione segue l’UID, non l’icona

La riga è per UID, e un UID può essere condiviso da più di un pacchetto, mentre un’app visibile può affidare il lavoro a un componente separato che gira sotto la propria identità. Una scheda del browser disegnata da un processo WebView condiviso, un servizio di sincronizzazione in background o un pacchetto complementare installato accanto all’app principale producono traffico che la schermata dei consumi può mostrare sotto un nome che non vi aspettavate, o sotto l’app che avete bloccato. Un pacchetto bloccato e un aiutante che ne porta le richieste sono due soggetti diversi, e la regola ne copriva solo uno.

Quando i numeri sembrano sbagliati, confrontate l’UID e non l’etichetta. L’API dei consumi si interroga per UID, e adb shell dumpsys package <package> | grep userId= stampa il numero con cui confrontare, quindi due voci con lo stesso UID sono la stessa identità dal punto di vista del contatore.

La finestra temporale può precedere la vostra regola

I dati sui consumi vengono raccolti in blocchi e interrogati periodicamente, non trasmessi in diretta. Un totale giornaliero può includere i minuti precedenti all’attivazione del blocco, una sincronizzazione in background dell’ora precedente o traffico già in corso. Confrontare un totale cumulativo con una sola richiesta rifiutata e chiamare la differenza una fuga è un errore di misurazione, non un riscontro del firewall.

Usate una finestra più breve e un inizio pulito. Annotate il timestamp quando cambiate la regola, aspettate un intervallo di raccolta e poi guardate solo i dati successivi. Se il totale continua a salire in una finestra che inizia dopo la regola, avete qualcosa da indagare; se smette di salire, la crescita precedente era storia visualizzata.

Il servizio VPN potrebbe non essere quello che avete configurato

Un firewall VPN vede solo il traffico che il proprio servizio trasporta. Se un’altra app VPN si avvia e prende la connessione attiva, il vostro filtro non è più sul percorso mentre la sua interfaccia esiste ancora nelle impostazioni. Gli elenchi di esclusione per app fanno lo stesso di proposito, e un profilo che esclude un’app non è una fuga quando l’app poi funziona.

Anche IPv4, IPv6 e DNS possono divergere. Un filtro che gestisce IPv4 può lasciare IPv6 o un resolver DNS privato fuori di sé, così parte del traffico dell’app segue un percorso che le vostre regole non hanno mai descritto. Controllate quale app possiede attualmente la VPN e cosa dice l’elenco delle esclusioni prima di riscrivere qualsiasi cosa:

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

Provate una richiesta nuova e annotate quattro fatti

Scegliete una richiesta innocua, eseguitela una volta e annotate quattro fatti: la regola in vigore, l’UID dell’app, lo stato della rete e l’ora. Poi verificate se il vostro filtro ha registrato il flusso e se la destinazione o il gateway hanno visto la stessa connessione. Un flusso identificato su entrambi i lati è una prova; un totale aggregato non lo è.

Una conclusione difendibile nomina ciò che è stato negato e quale osservazione lo ha confermato. «Il contatore è salito» non è un riscontro, e «tutti i contatori dei consumi sono falsi» non lo è nemmeno. Uno slogan sul livello OSI non risolve la questione: la risposta onesta è che il contatore e il blocco possono essere entrambi corretti mentre descrivono cose diverse. Il riferimento NetworkStatsManager di Android documenta come questi blocchi vengono interrogati e attribuiti.