Hoekom 'n geblokkeerde Android-toepassing steeds netwerkgebruik wys

Jy blokkeer 'n toepassing in jou Android-VPN-firewall, die toepassing hou op werk, en sy gebruikry bly klim. Die verleidelike gevolgtrekking is dat die blok gelek het, of dat die teller stukkend is. Nie een volg nie. 'n Gebruikrekord sê dat grepe by een of ander waarnemingspunt aan daardie identiteit toegeskryf is; dit sê niks oor of 'n afgeleë diens 'n versoek aanvaar het nie. Sodra jy weet watter grens gemeet is en aan watter identiteit dit gehef is, hou die twee waarnemings op om mekaar te weerspreek.

Die teller meet grepe, nie aflewering nie

Android skryf verkeer aan 'n UID toe en tel dit in beide rigtings, en dit doen dit by 'n koppelvlakgrens eerder as op die oomblik wanneer 'n toepassing se versoek slaag.

'n Verbindingspoging wat geweier word, beweeg steeds pakkette: die SYN, die reset of die hertransmissies wat daarop volg, plus die DNS-navraag wat beide voorafgegaan het. Daardie grepe bestaan selfs al is niks afgelewer nie, en op sommige paaie word hulle getel voordat enige filter besluit wat om daarmee te doen.

Dit is waarom 'n geblokkeerde toepassing se ry kan groei terwyl elke versoek misluk. Die teller antwoord "hoeveel grepe is aan hierdie identiteit toegeskryf", nie "het hierdie identiteit die internet bereik" nie. 'n Grafiek kan nie 'n aanvaarde stroom van 'n beleefd geweierde handdruk onderskei nie, en 'n totaal wat beide rigtings bymekaartel ook nie.

Toeskrywing volg die UID, nie die ikoon nie

Die ry is per UID, en een UID kan deur meer as een pakket gedeel word, terwyl 'n sigbare toepassing werk aan 'n aparte komponent kan oorhandig wat onder sy eie identiteit loop. 'n Blaaier-oortjie wat deur 'n gedeelde WebView-proses gerender word, 'n agtergrondsinchroniseringsdiens, of 'n metgeselpakket wat saam met die hoofdtoepassing geïnstalleer is, produseer almal verkeer wat die gebruikskerm onder 'n naam kan wys wat jy nie verwag het nie, of onder die toepassing wat jy wel geblokkeer het. 'n Geblokkeerde pakket en 'n helper wat sy versoeke dra, is twee verskillende subjekte, en die reël het net een van hulle gedek.

Wanneer die syfers verkeerd lyk, vergelyk die UID eerder as die etiket. Die gebruik-API word per UID bevra, en adb shell dumpsys package <package> | grep userId= druk die nommer wat jy moet vergelyk, so twee inskrywings met dieselfde UID is dieselfde identiteit uit die teller se oogpunt.

Die tydvenster kan jou reël voorafdateer

Gebruiksdata word in emmers versamel en gepeil, nie regstreeks gestroom nie. 'n Daaglikse totaal kan die minute insluit voor jy die blok aangeskakel het, 'n agtergrondsinchronisering van die vorige uur, of verkeer wat reeds onderweg was. Om 'n kumulatiewe totaal met een geweierde versoek te vergelyk en die verskil 'n lek te noem, is 'n meetfout, nie 'n firewall-bevinding nie.

Gebruik 'n korter venster en 'n vars begin. Noteer die tydstempel wanneer jy die reël verander, wag een versamelingsinterval, kyk dan net na data daarna. As die totaal bly styg oor 'n venster wat ná die reël begin, het jy iets om te ondersoek; as dit ophou styg, was die vroeëre groei geskiedenis wat vertoon is.

Die VPN-diens is dalk nie die een wat jy opgestel het nie

'n VPN-firewall sien net verkeer wat sy eie diens dra. As 'n ander VPN-toepassing begin en die aktiewe verbinding oorneem, is jou filter nie meer in die pad nie, terwyl sy koppelvlak nog in die instellings bestaan. Per-toepassing-omseil-lyste doen dieselfde ding doelbewus, en 'n profiel wat 'n toepassing uitsluit, is nie 'n lek wanneer die toepassing dan werk nie.

IPv4, IPv6 en DNS kan ook uiteenloop. 'n Filter wat IPv4 hanteer, kan IPv6 of 'n private DNS-resolver daar buite laat, so deel van die toepassing se verkeer volg 'n pad wat jou reëls nooit beskryf het nie. Kyk watter toepassing tans die VPN besit en wat die uitsluitingslys sê voordat jy enigiets herskryf:

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

Toets een vars versoek en teken vier feite aan

Kies 'n onskadelike versoek, maak dit een keer, en skryf vier feite neer: die reël wat geld, die toepassing se UID, die netwerktoestand en die tyd. Kyk dan of jou filter die vloei gelog het, en of die bestemming of poort die selfde verbinding gesien het. Een vloei wat aan beide kante geïdentifiseer is, is bewys; 'n saamgestelde totaal is nie.

'n Verdedigbare gevolgtrekking noem wat geweier is en watter waarneming dit bevestig het. "Die teller het gestyg" is nie 'n bevinding nie, en "alle gebruikstellers is vals" ook nie. 'n OSI-laag-slogan besleg dit nie: die eerlike antwoord is dat die teller en die blok albei korrek kan wees terwyl hulle verskillende dinge beskryf. Android se NetworkStatsManager-verwysing dokumenteer hoe daardie emmers bevra en toegeskryf word.