Hvorfor en blokkert Android-app fortsatt viser nettverksbruk

Du blokkerer en app i Android-VPN-brannmuren din, appen slutter å virke, og bruksraden fortsetter å stige. Den fristende konklusjonen er at blokkeringen lakk, eller at telleren er ødelagt. Ingen av delene følger. En brukspost sier at byte ble tilordnet den identiteten på et eller annet observasjonspunkt; den sier ingenting om hvorvidt en ekstern tjeneste godtok en forespørsel. Når du vet hvilken grense som ble målt og hvilken identitet den ble belastet på, slutter de to observasjonene å motsi hverandre.

Telleren måler byte, ikke levering

Android tilordner trafikk til en UID og teller den i begge retninger, og det gjør den ved en grensesnittgrense snarere enn i det øyeblikket en apps forespørsel lykkes.

Et avvist tilkoblingsforsøk flytter likevel pakker: SYN, reset eller de påfølgende omsendingene, pluss DNS-spørringen som kom før begge. Disse bytene finnes selv om ingenting ble levert, og på noen veier telles de før noen filter bestemmer hva som skal gjøres med dem.

Derfor kan raden til en blokkert app vokse mens hver forespørsel feiler. Telleren svarer på «hvor mange byte ble tilordnet denne identiteten», ikke «nådde denne identiteten internett». Et diagram kan ikke skille en akseptert strøm fra et høflig avvist håndtrykk, og en sum som legger begge retninger sammen kan heller ikke.

Tilordningen følger UID-en, ikke ikonet

Raden er per UID, og én UID kan deles av mer enn én pakke, mens en synlig app kan overlate arbeid til en separat komponent som kjører under sin egen identitet. En nettleserfane tegnet av en delt WebView-prosess, en bakgrunnssynkroniseringstjeneste eller en følgepakke installert ved siden av hovedappen produserer alle trafikk som bruksskjermen kan vise under et navn du ikke forventet, eller under appen du faktisk blokkerte. En blokkert pakke og en hjelper som bærer forespørslene dens, er to forskjellige subjekter, og regelen dekket bare ett av dem.

Når tallene ser gale ut, sammenlign UID-en i stedet for etiketten. Bruks-API-et spørres per UID, og adb shell dumpsys package <package> | grep userId= skriver ut tallet du skal sammenligne med, så to oppføringer med samme UID er samme identitet sett fra tellerens side.

Tidsvinduet kan være eldre enn regelen din

Bruksdata samles i bøtter og polles, ikke strømmes direkte. En døgnsum kan omfatte minuttene før du aktiverte blokkeringen, en bakgrunnssynkronisering fra timen før eller trafikk som allerede var underveis. Å sammenligne en kumulativ sum med én avvist forespørsel og kalle forskjellen en lekkasje er en målefeil, ikke en brannmurfunksjon.

Bruk et kortere vindu og en frisk start. Noter tidsstempelet når du endrer regelen, vent ett innsamlingsintervall og se deretter bare på data etter det. Hvis summen fortsetter å stige i et vindu som begynner etter regelen, har du noe å undersøke; hvis den slutter å stige, var den tidligere veksten historie som ble vist.

VPN-tjenesten er kanskje ikke den du konfigurerte

En VPN-brannmur ser bare trafikk som dens egen tjeneste bærer. Hvis en annen VPN-app starter og tar over den aktive tilkoblingen, er filteret ditt ikke lenger i banen mens grensesnittet fortsatt finnes i innstillingene. Lister for omgåelse per app gjør det samme med vilje, og en profil som utelukker en app er ikke en lekkasje når appen deretter virker.

IPv4, IPv6 og DNS kan også sprike. Et filter som håndterer IPv4 kan la IPv6 eller en privat DNS-resolver ligge utenfor, slik at en del av appens trafikk følger en vei som reglene dine aldri beskrev. Sjekk hvilken app som for øyeblikket eier VPN-en og hva utelukkelseslisten sier før du skriver om noe:

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

Test én frisk forespørsel og noter fire fakta

Velg en uskyldig forespørsel, utfør den én gang, og skriv ned fire fakta: regelen som gjelder, appens UID, nettverkstilstanden og tidspunktet. Sjekk deretter om filteret ditt loggførte strømmen, og om målet eller gatewayen så den samme tilkoblingen. Én strøm identifisert på begge sider er bevis; en samlet sum er det ikke.

En forsvarlig konklusjon navngir hva som ble avvist og hvilken observasjon som bekreftet det. «Telleren steg» er ikke et funn, og «alle brukstellere er falske» er det heller ikke. Et OSI-lag-slagord avgjør ikke dette: det ærlige svaret er at telleren og blokkeringen begge kan være korrekte mens de beskriver forskjellige ting. Androids NetworkStatsManager-referanse dokumenterer hvordan disse bøttene spørres og tilordnes.