Miért mutat mégis hálózati forgalmat egy blokkolt Android-alkalmazás

Blokkol egy alkalmazást az Android VPN-tűzfalában, az alkalmazás leáll, a forgalmi sora mégis tovább emelkedik. A csábító következtetés az, hogy a blokk szivárgott, vagy hogy a számláló elromlott. Egyik sem következik. A forgalmi rekord azt mondja, hogy bájtokat rendeltek ehhez az identitáshoz valamely megfigyelési ponton; semmit nem mond arról, hogy egy távoli szolgáltatás elfogadott-e egy kérést. Amint tudja, melyik határt mérték és melyik identitásra terhelték, a két megfigyelés megszűnik ellentmondani egymásnak.

A számláló bájtokat mér, nem kézbesítést

Az Android a forgalmat egy UID-hez rendeli és mindkét irányban számolja, és ezt interfészhatáron teszi, nem abban a pillanatban, amikor egy alkalmazás kérése sikeres lesz.

Az elutasított kapcsolódási kísérlet is mozgat csomagokat: a SYN-t, a resetet vagy az azt követő újraküldéseket, valamint az előbbiek előtt lezajlott DNS-lekérdezést. Ezek a bájtok akkor is léteznek, ha semmi nem került kézbesítésre, és bizonyos útvonalakon még azelőtt számolják őket, hogy bármely szűrő eldöntené, mi legyen velük.

Ezért nőhet egy blokkolt alkalmazás sora, miközben minden kérés meghiúsul. A számláló arra válaszol, hogy „hány bájtot rendeltek ehhez az identitáshoz”, nem arra, hogy „elérte-e ez az identitás az internetet”. Egy diagram nem tud különbséget tenni elfogadott adatfolyam és udvariasan elutasított kézfogás között, és egy összeg sem, amely mindkét irányt összeadja.

A hozzárendelés az UID-t követi, nem az ikont

A sor UID-nként értendő, és egy UID-t több csomag is megoszthat, miközben egy látható alkalmazás átadhat munkát egy külön komponensnek, amely a saját identitása alatt fut. Egy megosztott WebView-folyamat által rajzolt böngészőlap, egy háttérszinkronizáló szolgáltatás vagy a fő alkalmazás mellé telepített kísérőcsomag mind olyan forgalmat termel, amelyet a forgalmi képernyő olyan név alatt jeleníthet meg, amelyre nem számított, vagy éppen a blokkolt alkalmazás alatt. A blokkolt csomag és a kéréseit vivő segéd két különböző alany, és a szabály csak az egyiket fedte le.

Amikor a számok hibásnak tűnnek, az UID-t hasonlítsa össze, ne a címkét. A forgalmi API-t UID szerint kérdezik le, és adb shell dumpsys package <package> | grep userId= kinyomtatja az összehasonlítandó számot, így két azonos UID-es bejegyzés ugyanaz az identitás a számláló szemszögéből.

Az időablak megelőzheti a szabályát

A forgalmi adatokat gyűjtőkbe szedve, lekérdezéssel szerzik be, nem élőben streamelik. Egy napi összeg tartalmazhatja a blokk engedélyezése előtti perceket, egy előző órai háttérszinkronizálást vagy már úton lévő forgalmat. Egy kumulatív összeget egyetlen elutasított kéréshez hasonlítani, és a különbséget szivárgásnak nevezni mérési hiba, nem tűzfalmegállapítás.

Használjon rövidebb ablakot és tiszta kezdést. Jegyezze fel az időbélyeget, amikor módosítja a szabályt, várjon egy gyűjtési intervallumot, majd csak az utána következő adatokat nézze. Ha az összeg tovább emelkedik egy olyan ablakban, amely a szabály után kezdődik, van mit kivizsgálnia; ha abbamarad az emelkedés, a korábbi növekedés megjelenített történet volt.

A VPN-szolgáltatás nem feltétlenül az, amelyet beállított

Egy VPN-tűzfal csak azt a forgalmat látja, amelyet a saját szolgáltatása szállít. Ha egy másik VPN-alkalmazás indul el és átveszi az aktív kapcsolatot, a szűrője már nincs az útvonalon, miközben a felülete továbbra is létezik a beállításokban. Az alkalmazásonkénti megkerülési listák ugyanezt teszik szándékosan, és egy alkalmazást kizáró profil nem szivárgás, amikor az alkalmazás utána működik.

Az IPv4, az IPv6 és a DNS is eltérhet. Egy IPv4-et kezelő szűrő az IPv6-ot vagy egy privát DNS-feloldót kívül hagyhat, így az alkalmazás forgalmának egy része olyan útvonalon halad, amelyet a szabályai soha nem írtak le. Ellenőrizze, melyik alkalmazás birtokolja jelenleg a VPN-t, és mit mond a kizárási lista, mielőtt bármit átírna:

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

Teszteljen egy friss kérést, és rögzítsen négy tényt

Válasszon egy ártalmatlan kérést, hajtsa végre egyszer, és írjon le négy tényt: az érvényben lévő szabályt, az alkalmazás UID-jét, a hálózat állapotát és az időt. Ezután ellenőrizze, hogy a szűrője naplózta-e a folyamot, és hogy a cél vagy az átjáró ugyanazt a kapcsolatot látta-e. Egy mindkét oldalon azonosított folyam bizonyíték; egy összesített végösszeg nem az.

Egy védhető következtetés megnevezi, mit tagadtak meg, és melyik megfigyelés erősítette meg. „A számláló emelkedett” nem megállapítás, és „minden forgalomszámláló hamis” sem az. Egy OSI-réteges szlogen ezt nem dönti el: a tisztességes válasz az, hogy a számláló és a blokk egyszerre is helyes lehet, miközben különböző dolgokat ír le. Az Android NetworkStatsManager referenciája dokumentálja, hogyan kérdezhetők le és rendelhetők hozzá ezek a gyűjtők.