De ce o aplicație Android blocată încă arată consum de rețea

Blocați o aplicație în firewallul VPN Android, aplicația nu mai funcționează, iar rândul ei de consum continuă să crească. Concluzia tentantă este că blocarea a scăpat, sau că numărătorul e stricat. Niciuna nu decurge. O înregistrare de consum spune că octeți au fost atribuiți acelei identități într-un anumit punct de observare; nu spune nimic despre faptul dacă un serviciu îndepărtat a acceptat o cerere. Odată ce știți ce frontieră a fost măsurată și cărei identități i-a fost imputată, cele două observații nu se mai contrazic.

Contorul măsoară octeți, nu livrare

Android atribuie traficul unui UID și îl numără în ambele direcții, iar asta o face la o frontieră de interfață, nu în momentul în care cererea unei aplicații reușește.

O încercare de conexiune refuzată tot mișcă pachete: SYN, resetul sau retransmisiile care urmează, plus interogarea DNS care le-a precedat pe amândouă. Acești octeți există chiar dacă nu s-a livrat nimic, iar pe unele căi sunt numărați înainte ca vreun filtru să decidă ce să facă cu ei.

De aceea rândul unei aplicații blocate poate crește în timp ce fiecare cerere eșuează. Contorul răspunde la „câți octeți au fost atribuiți acestei identități”, nu la „a ajuns această identitate la internet”. Un grafic nu poate distinge un flux acceptat de o strângere de mână refuzată politicos, iar un total care adună ambele direcții nici atât.

Atribuirea urmează UID-ul, nu pictograma

Rândul este pe UID, iar un UID poate fi partajat de mai mult de un pachet, în timp ce o aplicație vizibilă poate preda lucrul unui component separat care rulează sub propria identitate. Un tab de browser desenat de un proces WebView partajat, un serviciu de sincronizare din fundal sau un pachet însoțitor instalat lângă aplicația principală produc toate trafic pe care ecranul de consum îl poate afișa sub un nume la care nu vă așteptați, sau sub aplicația pe care ați blocat-o. Un pachet blocat și un ajutor care îi transportă cererile sunt două subiecte diferite, iar regula acoperea doar unul dintre ele.

Când cifrele arată greșit, comparați UID-ul, nu eticheta. API-ul de consum este interogat după UID, iar adb shell dumpsys package <package> | grep userId= afișează numărul cu care trebuie comparat, așa că două intrări cu același UID sunt aceeași identitate din perspectiva contorului.

Fereastra de timp poate precede regula dumneavoastră

Datele de consum sunt colectate în găleți și interogate periodic, nu transmise în direct. Un total zilnic poate include minutele dinaintea activării blocării, o sincronizare din fundal din ora precedentă sau trafic care era deja în curs. Să compari un total cumulat cu o singură cerere refuzată și să numești diferența scurgere este o eroare de măsurare, nu o constatare a firewallului.

Folosiți o fereastră mai scurtă și un început curat. Notați momentul când schimbați regula, așteptați un interval de colectare, apoi uitați-vă doar la datele de după el. Dacă totalul continuă să crească într-o fereastră care începe după regulă, aveți ce investiga; dacă se oprește din creștere, creșterea anterioară era istoric afișat.

Serviciul VPN poate să nu fie cel pe care l-ați configurat

Un firewall VPN vede doar traficul pe care îl transportă propriul serviciu. Dacă o altă aplicație VPN pornește și preia conexiunea activă, filtrul dumneavoastră nu mai este pe traseu, deși interfața lui încă există în setări. Listele de ocolire pe aplicație fac același lucru intenționat, iar un profil care exclude o aplicație nu este o scurgere când aplicația funcționează apoi.

IPv4, IPv6 și DNS pot și ele să divergă. Un filtru care tratează IPv4 poate lăsa IPv6 sau un rezolvator DNS privat în afara lui, astfel încât o parte din traficul aplicației urmează o cale pe care regulile dumneavoastră nu au descris-o niciodată. Verificați ce aplicație deține acum VPN-ul și ce spune lista de excluderi înainte de a rescrie ceva:

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

Testați o cerere nouă și notați patru fapte

Alegeți o cerere inofensivă, executați-o o dată și notați patru fapte: regula în vigoare, UID-ul aplicației, starea rețelei și ora. Apoi verificați dacă filtrul a înregistrat fluxul și dacă destinația sau gateway-ul au văzut aceeași conexiune. Un flux identificat pe ambele părți este dovadă; un total agregat nu este.

O concluzie defendabilă numește ce a fost refuzat și ce observație a confirmat asta. „Contorul a crescut” nu este o constatare, iar „toate contoarele de consum sunt false” nici atât. Un slogan despre stratul OSI nu rezolvă asta: răspunsul onest este că contorul și blocarea pot fi ambele corecte în timp ce descriu lucruri diferite. Referința NetworkStatsManager a Android documentează cum sunt interogate și atribuite aceste găleți.