Zakaj blokirana aplikacija Android še vedno prikazuje omrežno porabo

V aplikaciji Android blokirate aplikacijo v požarnem zidu VPN, aplikacija preneha delovati, njena vrstica porabe pa še naprej raste. Mamljiv sklep je, da je blokada puščala, ali da je števec pokvarjen. Nobeno ne sledi. Zapis porabe pravi, da so bili bajti pripisani tej identiteti na neki opazovalni točki; ne pove ničesar o tem, ali je oddaljena storitev zahtevo sprejela. Ko veste, katera meja je bila izmerjena in kateri identiteti je bilo to obračunano, si opažanji ne nasprotujeta več.

Števec meri bajte, ne dostave

Android pripiše promet UID in ga šteje v obe smeri, in to na meji vmesnika, ne v trenutku, ko zahteva aplikacije uspe.

Zavrnjen poskus povezave še vedno premika pakete: SYN, reset ali ponovne pošiljke, ki sledijo, plus poizvedba DNS, ki je obema sledila pred njima. Ti bajti obstajajo, tudi ko ni bilo ničesar dostavljenega, in na nekaterih poteh se štejejo, preden kateri koli filter odloči, kaj z njimi.

Zato lahko vrstica blokirane aplikacije raste, medtem ko vsaka zahteva propade. Števec odgovarja na vprašanje »koliko bajtov je bilo pripisanih tej identiteti«, ne »ali je ta identiteta dosegla internet«. Graf ne more ločiti sprejetega toka od vljudno zavrnjenega rokovanja, tudi vsota, ki sešteje obe smeri, ne.

Pripis sledi UID, ne ikoni

Vrstica je po UID, in en UID si lahko deli več paketov, medtem ko lahko vidna aplikacija delo preda ločeni komponenti, ki teče pod lastno identiteto. Zavihek brskalnika, ki ga riše skupni proces WebView, storitev sinhronizacije v ozadju ali spremljevalni paket, nameščen poleg glavne aplikacije, vsi ustvarjajo promet, ki ga lahko zaslon porabe prikaže pod imenom, ki ga niste pričakovali, ali pod aplikacijo, ki ste jo blokirali. Blokiran paket in pomočnik, ki nosi njegove zahteve, sta dva različna subjekta, pravilo pa je pokrivalo le enega od njiju.

Ko se številke zdijo napačne, primerjajte UID in ne oznake. API porabe se poizveduje po UID, adb shell dumpsys package <package> | grep userId= pa izpiše število, s katerim je treba primerjati, zato sta dva vnosa z istim UID z vidika števca ista identiteta.

Časovno okno lahko predhaja vašemu pravilu

Podatki o porabi se zbirajo v segmentih in poizvedujejo redno, ne pretakajo se v živo. Dnevna vsota lahko vključuje minute pred omogočitvijo blokade, sinhronizacijo v ozadju iz prejšnje ure ali promet, ki je bil že na poti. Primerjanje kumulativne vsote z eno zavrnjeno zahtevo in imenovanje razlike puščanje je merilna napaka, ne ugotovitev požarnega zidu.

Uporabite krajše okno in čist začetek. Zabeležite časovni žig, ko spremenite pravilo, počakajte en interval zbiranja in nato glejte le podatke po njem. Če vsota v oknu, ki se začne po pravilu, še naprej raste, imate kaj raziskati; če preneha rasti, je bila prejšnja rast prikazana zgodovina.

Storitev VPN morda ni tista, ki ste jo nastavili

Požarni zid VPN vidi le promet, ki ga nosi njegova lastna storitev. Če se zažene druga aplikacija VPN in prevzame aktivno povezavo, vaš filter ni več na poti, čeprav njegov vmesnik v nastavitvah še vedno obstaja. Seznami zaobida po aplikacijah počnejo isto namerno, profil, ki izključuje aplikacijo, pa ni puščanje, ko aplikacija nato deluje.

Tudi IPv4, IPv6 in DNS se lahko razhajajo. Filter, ki obravnava IPv4, lahko pusti IPv6 ali zasebni DNS razreševalnik zunaj sebe, zato del prometa aplikacije sledi poti, ki je vaša pravila nikoli niso opisala. Preverite, katera aplikacija trenutno ima VPN in kaj pravi seznam izjem, preden karkoli prepišete:

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

Preizkusite eno novo zahtevo in zapišite štiri dejstva

Izberite nedolžno zahtevo, izvedite jo enkrat in zapišite štiri dejstva: veljavno pravilo, UID aplikacije, stanje omrežja in čas. Nato preverite, ali je vaš filter zabeležil tok in ali sta cilj ali prehod videla isto povezavo. En tok, prepoznan na obeh straneh, je dokaz; skupna vsota ni.

Zagovorljiv sklep poimenuje, kaj je bilo zavrnjeno in katero opažanje je to potrdilo. »Števec se je dvignil« ni ugotovitev, in »vsi števci porabe so lažni« tudi ne. Slogan o plasti OSI tega ne razreši: pošten odgovor je, da sta lahko števec in blokada hkrati pravilna, medtem ko opisujeta različne stvari. Referenca NetworkStatsManager za Android dokumentira, kako se ti segmenti poizvedujejo in pripisujejo.