Proč zablokovaná aplikace pro Android stále ukazuje síťový provoz

Zablokujete aplikaci ve svém Android VPN firewallu, aplikace přestane fungovat a její řádek spotřeby dál roste. Lákavý závěr je, že blokace prosákla, nebo že počítadlo je rozbité. Ani jedno nevyplývá. Záznam o spotřebě říká, že bajty byly v nějakém pozorovacím bodě přiřazeny této identitě; neříká nic o tom, zda vzdálená služba požadavek přijala. Jakmile víte, která hranice byla měřena a které identitě to bylo naúčtováno, obě pozorování si přestanou odporovat.

Počítadlo měří bajty, ne doručení

Android přiřazuje provoz k UID a počítá ho v obou směrech, a dělá to na hranici rozhraní, nikoli v okamžiku, kdy požadavek aplikace uspěje.

Odmítnutý pokus o spojení přesto pohybuje pakety: SYN, reset nebo následná opakovaná přenosy, plus dotaz DNS, který oběma předcházel. Tyto bajty existují, i když nic nebylo doručeno, a na některých cestách se počítají dřív, než jakýkoli filtr rozhodne, co s nimi.

Proto může řádek zablokované aplikace růst, i když každý požadavek selže. Počítadlo odpovídá na otázku „kolik bajtů bylo přiřazeno této identitě“, ne „dosáhla tato identita internetu“. Graf nerozliší přijatý proud od zdvořile odmítnutého handshaku a součet, který sčítá oba směry, také ne.

Přiřazení sleduje UID, ne ikonu

Řádek je podle UID a jedno UID může sdílet více balíčků, zatímco viditelná aplikace může práci předat samostatné komponentě, která běží pod vlastní identitou. Karta prohlížeče vykreslená sdíleným procesem WebView, služba synchronizace na pozadí nebo doprovodný balíček nainstalovaný vedle hlavní aplikace všechny vytvářejí provoz, který obrazovka spotřeby může zobrazit pod jménem, které jste nečekali, nebo pod aplikací, kterou jste zablokovali. Zablokovaný balíček a pomocník, který nese jeho požadavky, jsou dva různé subjekty a pravidlo pokrývalo jen jeden z nich.

Když čísla vypadají špatně, porovnávejte UID, ne označení. API spotřeby se dotazuje podle UID a adb shell dumpsys package <package> | grep userId= vypíše číslo, se kterým je třeba porovnávat, takže dva záznamy se stejným UID jsou z pohledu počítadla stejná identita.

Časové okno může předcházet vašemu pravidlu

Data o spotřebě se shromažďují v segmentech a dotazují se, neproudí živě. Denní součet může zahrnovat minuty před zapnutím blokace, synchronizaci na pozadí z předchozí hodiny nebo provoz, který už byl na cestě. Srovnávat kumulativní součet s jedním odmítnutým požadavkem a rozdíl nazývat únikem je chyba měření, ne zjištění firewallu.

Použijte kratší okno a čistý začátek. Poznamenejte si časovou značku, když pravidlo změníte, počkejte jeden interval sběru a pak se dívejte jen na data po něm. Pokud součet dál roste v okně, které začíná po pravidle, máte co vyšetřovat; pokud přestane růst, dřívější růst byl zobrazovanou historií.

Služba VPN nemusí být ta, kterou jste nastavili

VPN firewall vidí jen provoz, který nese jeho vlastní služba. Pokud se spustí jiná VPN aplikace a převezme aktivní spojení, váš filtr už není na cestě, zatímco jeho rozhraní v nastavení stále existuje. Seznamy obejití podle aplikací dělají totéž záměrně a profil, který aplikaci vylučuje, není únikem, když aplikace pak funguje.

IPv4, IPv6 a DNS se také mohou rozejít. Filtr, který zpracovává IPv4, může nechat IPv6 nebo privátní DNS resolver mimo sebe, takže část provozu aplikace jde cestou, kterou vaše pravidla nikdy nepopsala. Zkontrolujte, která aplikace VPN právě vlastní a co říká seznam výjimek, než cokoli přepíšete:

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

Vyzkoušejte jeden nový požadavek a zapište čtyři skutečnosti

Vyberte neškodný požadavek, jednou ho proveďte a zapište čtyři skutečnosti: platné pravidlo, UID aplikace, stav sítě a čas. Pak zkontrolujte, zda váš filtr tok zaznamenal a zda cíl nebo brána viděly stejné spojení. Jeden tok identifikovaný na obou stranách je důkaz; souhrnný součet není.

Obhajitelný závěr pojmenuje, co bylo odepřeno a které pozorování to potvrdilo. „Počítadlo stouplo“ není zjištění a „všechna počítadla spotřeby jsou falešná“ také ne. Slogan o vrstvě OSI to nevyřeší: poctivá odpověď je, že počítadlo i blokace mohou být obojí správné, i když popisují různé věci. Referenční dokumentace NetworkStatsManager pro Android dokumentuje, jak se tyto segmenty dotazují a přiřazují.