Kvifor ein blokkert Android-app framleis viser nettverksbruk

Du blokkerer ein app i Android-VPN-brannmuren din, appen sluttar å verke, og bruksrada held fram med å stige. Den freistande konklusjonen er at blokkeringa lak, eller at teljaren er øydelagd. Ingen av delane følgjer. Ei brukspost seier at byte vart tildelt den identiteten på eit eller anna observasjonspunkt; ho seier ingenting om ein ekstern teneste godtok ein førespurnad. Når du veit kva grense som vart målt og kva identitet ho vart belasta på, sluttar dei to observasjonane å motseie kvarandre.

Teljaren måler byte, ikkje levering

Android tildeler trafikk til ein UID og tel han i begge retningar, og det gjer han ved ei grensesnittgrense snarare enn i det augneblinken ein førespurnad frå ein app lukkast.

Eit avvist tilkoplingsforsøk flyttar likevel pakkar: SYN, reset eller dei påfølgjande omsendingane, pluss DNS-spørjinga som kom før begge. Desse bytene finst sjølv om ingenting vart levert, og på nokre vegar vert dei talde før nokon filter avgjer kva som skal gjerast med dei.

Difor kan rada til ein blokkert app vekse medan kvar førespurnad feilar. Teljaren svarar på «kor mange byte vart tildelt denne identiteten», ikkje «nådde denne identiteten internett». Eit diagram kan ikkje skilje ein godteken straum frå eit høfleg avvist handtrykk, og ein sum som legg begge retningane saman kan heller ikkje.

Tildelinga følgjer UID-en, ikkje ikonet

Rada er per UID, og éin UID kan delast av meir enn éin pakke, medan ein synleg app kan overlate arbeid til ein separat komponent som køyrer under sin eigen identitet. Ei nettlesarfane teikna av ein delt WebView-prosess, ei bakgrunnssynkroniseringsteneste eller ein følgjepakke installert ved sida av hovudappen produserer alle trafikk som bruksskjermen kan vise under eit namn du ikkje venta, eller under appen du faktisk blokkerte. Ein blokkert pakke og ein hjelpar som ber førespurnadene hans, er to ulike subjekt, og regelen dekte berre eitt av dei.

Når tala ser gale ut, samanlikn UID-en i staden for etiketten. Bruks-API-et vert spurt per UID, og adb shell dumpsys package <package> | grep userId= skriv ut talet du skal samanlikne med, så to oppføringar med same UID er same identitet sett frå teljaren si side.

Tidsvindauget kan vere eldre enn regelen din

Bruksdata vert samla i bøtter og polla, ikkje strøymde direkte. Ein døgnsum kan omfatte minutta før du aktiverte blokkeringa, ei bakgrunnssynkronisering frå timen før eller trafikk som allereie var undervegs. Å samanlikne ein kumulativ sum med éin avvist førespurnad og kalle skilnaden ein lekkasje er ein målefeil, ikkje eit brannmurfunn.

Bruk eit kortare vindauge og ein rein start. Noter tidsstempelet når du endrar regelen, vent eitt innsamlingsintervall og sjå deretter berre på data etter det. Viss summen held fram med å stige i eit vindauge som byrjar etter regelen, har du noko å undersøkje; viss han sluttar å stige, var den tidlegare veksten historie som vart vist.

VPN-tenesta er kanskje ikkje den du konfigurerte

Ein VPN-brannmur ser berre trafikk som tenesta hans eiga ber. Viss ein annan VPN-app startar og tek over den aktive tilkoplinga, er filteret ditt ikkje lenger i banen medan grensesnittet framleis finst i innstillingane. Lister for omgåing per app gjer det same med vilje, og ein profil som utelukkar ein app er ikkje ein lekkasje når appen deretter verkar.

IPv4, IPv6 og DNS kan også sprike. Eit filter som handterer IPv4 kan la IPv6 eller ein privat DNS-resolvar liggje utanfor, slik at ein del av trafikken til appen følgjer ein veg som reglane dine aldri skildra. Sjekk kva app som for tida eig VPN-en og kva utelatingslista seier før du skriv om noko:

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

Test éin fersk førespurnad og noter fire fakta

Vel ein uskuldig førespurnad, utfør han éin gong, og skriv ned fire fakta: regelen som gjeld, UID-en til appen, nettverkstilstanden og tidspunktet. Sjekk deretter om filteret ditt logga straumen, og om målet eller gatewayen såg den same tilkoplinga. Éin straum identifisert på begge sider er prov; ein samla sum er det ikkje.

Ein forsvarleg konklusjon namngjev kva som vart avvist og kva observasjon som stadfesta det. «Teljaren steig» er ikkje eit funn, og «alle bruksteljarar er falske» er det heller ikkje. Eit OSI-lag-slagord avgjer ikkje dette: det ærlege svaret er at teljaren og blokkeringa begge kan vere korrekte medan dei skildrar ulike ting. Android sin NetworkStatsManager-referanse dokumenterer korleis desse bøttene vert spurde og tildelte.