Hvorfor en blokeret Android-app stadig viser netværksforbrug

Du blokerer en app i din Android VPN-firewall, appen holder op med at virke, og dens forbrugsrække bliver ved med at stige. Den fristende konklusion er, at blokeringen lækkede, eller at tælleren er i stykker. Ingen af delene følger. En forbrugsregistrering siger, at bytes blev tilskrevet den identitet på et eller andet observationspunkt; den siger intet om, hvorvidt en fjerntjeneste accepterede en anmodning. Når du ved, hvilken grænse der blev målt, og hvilken identitet det blev opkrævet på, holder de to observationer op med at modsige hinanden.

Tælleren måler bytes, ikke levering

Android tilskriver trafik til en UID og tæller den i begge retninger, og det gør den ved en grænsefladegrænse snarere end i det øjeblik, en apps anmodning lykkes.

Et forbindelsesforsøg, der afvises, flytter stadig pakker: SYN, reset eller de gentagne transmissioner, der følger, plus DNS-forespørgslen, der gik forud for begge. De bytes findes, selv om intet blev leveret, og på nogle veje tælles de, før noget filter beslutter, hvad der skal ske med dem.

Derfor kan en blokeret apps række vokse, mens hver anmodning fejler. Tælleren svarer på »hvor mange bytes blev tilskrevet denne identitet«, ikke »nåede denne identitet internettet«. Et diagram kan ikke skelne en accepteret strøm fra et høfligt afvist håndtryk, og en sum, der lægger begge retninger sammen, kan heller ikke.

Tildelingen følger UID’en, ikke ikonet

Rækken er pr. UID, og én UID kan deles af mere end én pakke, mens en synlig app kan overdrage arbejde til en separat komponent, der kører under sin egen identitet. En browservane, der tegnes af en delt WebView-proces, en baggrundssynkroniseringstjeneste eller en ledsagerpakke installeret sammen med hovedappen producerer alle trafik, som forbrugsskærmen kan vise under et navn, du ikke forventede, eller under den app, du faktisk blokerede. En blokeret pakke og en hjælper, der bærer dens anmodninger, er to forskellige subjekter, og reglen dækkede kun den ene.

Når tallene ser forkerte ud, sammenlign UID’en i stedet for etiketten. Forbrugs-API’et forespørges pr. UID, og adb shell dumpsys package <package> | grep userId= udskriver det tal, du skal sammenligne med, så to poster med samme UID er den samme identitet set fra tællerens side.

Tidsvinduet kan være ældre end din regel

Forbrugsdata indsamles i bøtter og polles, ikke streamet live. En daglig sum kan omfatte minutterne før du aktiverede blokeringen, en baggrundssynkronisering fra den foregående time eller trafik, der allerede var undervejs. At sammenligne en kumulativ sum med én afvist anmodning og kalde forskellen en lækage er en målefejl, ikke en firewall-opdagelse.

Brug et kortere vindue og en frisk start. Noter tidsstemplet, når du ændrer reglen, vent et indsamlingsinterval, og se derefter kun på data efter det. Hvis summen fortsætter med at stige i et vindue, der begynder efter reglen, har du noget at undersøge; hvis den holder op med at stige, var den tidligere vækst historie, der blev vist.

VPN-tjenesten er måske ikke den, du konfigurerede

En VPN-firewall ser kun trafik, som dens egen tjeneste bærer. Hvis en anden VPN-app starter og overtager den aktive forbindelse, er dit filter ikke længere på vejen, mens dets grænseflade stadig findes i indstillingerne. Lister over omgåelse pr. app gør det samme med vilje, og en profil, der udelukker en app, er ikke en lækage, når appen derefter virker.

IPv4, IPv6 og DNS kan også divergere. Et filter, der håndterer IPv4, kan lade IPv6 eller en privat DNS-resolver ligge uden for, så en del af appens trafik følger en vej, som dine regler aldrig beskrev. Kontroller, hvilken app der i øjeblikket ejer VPN’et, og hvad udelukkelseslisten siger, før du omskriver noget:

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

Test én frisk anmodning, og noter fire fakta

Vælg en uskadelig anmodning, udfør den én gang, og skriv fire fakta ned: reglen, der gælder, appens UID, netværkstilstanden og tidspunktet. Kontroller derefter, om dit filter loggede strømmen, og om destinationen eller gatewayen så den samme forbindelse. Én strøm identificeret på begge sider er bevis; en samlet sum er det ikke.

En forsvarlig konklusion navngiver, hvad der blev afvist, og hvilken observation der bekræftede det. »Tælleren steg« er ikke en opdagelse, og »alle forbrugstællere er falske« er det heller ikke. Et OSI-lag-slogan afgør ikke dette: det ærlige svar er, at tælleren og blokeringen begge kan være korrekte, mens de beskriver forskellige ting. Androids NetworkStatsManager-reference dokumenterer, hvordan disse bøtter forespørges og tildeles.