Miks blokeeritud Androidi rakendus näitab endiselt võrgukasutust

Blokeerite rakenduse oma Androidi VPN-tulemüüris, rakendus lakkab töötamast ja selle kasutusrida kasvab edasi. Peibutav järeldus on, et blokeering lekkis või et loendur on katki. Kumbki ei järgne. Kasutuskirje ütleb, et baidid omistati sellele identiteedile mingis vaatluspunktis; see ei ütle midagi selle kohta, kas kaugteenus päringu vastu võttis. Kui teate, millist piiri mõõdeti ja millisele identiteedile see kirjutati, lakkavad kaks vaatlust üksteisele vastu rääkimast.

Loendur mõõdab baite, mitte kohaletoimetamist

Android omistab liikluse UID-ile ja loendab seda mõlemas suunas, tehes seda liidese piiril, mitte hetkel, mil rakenduse päring õnnestub.

Tagasi lükatud ühenduskatse liigutab ikkagi pakette: SYN, reset või sellele järgnevad kordused, pluss DNS-päring, mis mõlema eel käis. Need baidid on olemas ka siis, kui midagi ei toimetatud, ja mõnel teekonnal loendatakse neid enne, kui ükskõik milline filter otsustab, mida nendega teha.

Seetõttu võib blokeeritud rakenduse rida kasvada, samal ajal kui iga päring ebaõnnestub. Loendur vastab küsimusele „kui palju baite omistati sellele identiteedile“, mitte „kas see identiteet jõudis internetti“. Diagramm ei suuda eristada vastuvõetud voogu viisakalt tagasi lükatud kätlusest, ja seda ei suuda ka summa, mis liidab mõlemad suunad kokku.

Omistamine järgib UID-i, mitte ikooni

Rida on UID-põhine ja üht UID-i võib jagada rohkem kui üks pakett, samal ajal kui nähtav rakendus võib töö üle anda eraldi komponendile, mis töötab oma identiteedi all. Ühise WebView-protsessi joonistatud brauseri vahekaart, taustal sünkroonimisteenus või põhirakenduse kõrvale paigaldatud kaasaspakett tekitavad kõik liiklust, mida kasutusekraan võib näidata nime all, mida te ei oodanud, või rakenduse all, mille te blokeerisite. Blokeeritud pakett ja selle päringuid kandev abiline on kaks eri subjekti ning reegel kattis neist ainult ühte.

Kui numbrid tunduvad valed, võrrelge UID-i, mitte silti. Kasutus-API-t küsitakse UID-i järgi ja adb shell dumpsys package <package> | grep userId= prindib numbri, millega võrrelda, seega kaks sama UID-iga kirjet on loenduri vaatepunktist sama identiteet.

Ajavahemik võib olla teie reeglist varasem

Kasutusandmed kogutakse ämbritesse ja küsitakse perioodiliselt, mitte ei voogata reaalajas. Päevane kogusumma võib sisaldada minuteid enne blokeeringu lubamist, taustal sünkroonimist eelmisest tunnist või liiklust, mis oli juba teel. Kumulatiivse kogusumma võrdlemine ühe tagasi lükatud päringuga ja erinevuse lekkeks nimetamine on mõõtmisviga, mitte tulemüüri leid.

Kasutage lühemat ajavahemikku ja värsket algust. Märkige üles ajatempel, kui reeglit muudate, oodake üks kogumisintervall ja vaadake siis ainult sellele järgnevaid andmeid. Kui kogusumma kasvab edasi ajavahemikus, mis algab pärast reeglit, on teil midagi uurida; kui see kasvamise lõpetab, oli varasem kasv kuvatud ajalugu.

VPN-teenus ei pruugi olla see, mille te seadistasite

VPN-tulemüür näeb ainult liiklust, mida kannab tema enda teenus. Kui mõni teine VPN-rakendus käivitub ja võtab aktiivse ühenduse üle, ei ole teie filter enam teekonnal, samal ajal kui selle liides on seadetes endiselt olemas. Rakendusepõhised möödasõiduloendid teevad seda meelega, ja profiil, mis rakenduse välja jätab, ei ole leke, kui rakendus seejärel töötab.

IPv4, IPv6 ja DNS võivad samuti lahkneda. IPv4-iga tegelev filter võib jätta IPv6 või privaatse DNS-resolveri sellest välja, nii et osa rakenduse liiklusest järgib teekonda, mida teie reeglid kunagi ei kirjeldanud. Enne millegi ümberkirjutamist kontrollige, milline rakendus praegu VPN-i omab ja mida välistusloend ütleb:

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

Testige üht värsket päringut ja kirjutage üles neli fakti

Valige kahjutu päring, tehke seda üks kord ja kirjutage üles neli fakti: kehtiv reegel, rakenduse UID, võrgu olek ja kellaaeg. Seejärel kontrollige, kas teie filter logis voo ja kas sihtkoht või lüüs nägi sama ühendust. Üks mõlemal pool tuvastatud voog on tõend; koondsumma ei ole.

Kaitstav järeldus nimetab, mis keelati ja milline vaatlus seda kinnitas. „Loendur kasvas“ ei ole leid ja „kõik kasutusloendurid on võltsid“ samuti mitte. OSI-kihi loosung seda ei lahenda: aus vastus on, et loendur ja blokeering võivad mõlemad olla õiged, kirjeldades erinevaid asju. Androidi viide NetworkStatsManager dokumenteerib, kuidas neid ämbreid küsitakse ja omistatakse.