Wêrom in blokkearre Android-app noch altyd netwurkgebrûk toant

Jo blokkearje in app yn jo Android-VPN-firewall, de app wurket net mear, en syn gebrûkrige bliuwt klimmen. De ferliedlike konklúzje is dat de blokkade lekke is, of dat de teller stikken is. Gjin fan beide folget. In gebrûksregistraasje seit dat bytes op in beoardielingspunt oan dy identiteit taskreaun waarden; it seit neat oer de fraach oft in tsjinst op ôfstân in oanfraach akseptearre hat. Sadree't jo witte hokker grins metten is en oan hokker identiteit it taskreaun is, hâlde de twa waarnimmings op elkoar tsjin te sprekken.

De teller mjit bytes, net levering

Android taskennt ferkear oan in UID en telt it yn beide rjochtingen, en dat docht it op in ynterfacegrins yn stee fan op it stuit dat in oanfraach fan in app slagget.

In ferbiningspoging dy’t wegere wurdt, ferpleatst noch altyd pakketten: de SYN, de reset of de werhellings dy’t folgje, plus de DNS-fraach dy’t oan beide foarôfgie. Dy bytes besteane ek as neat levere is, en op guon paden wurde se teld foardat hokker filter dan ek beslút wat der mei te dwaan.

Dêrom kin de rige fan in blokkearre app groeie wylst elke oanfraach mislearret. De teller beantwurdet «hoefolle bytes binne oan dizze identiteit taskreaun», net «is dizze identiteit it ynternet berikt». In grafyk kin in akseptearre stream net fan in beleden wegere hânskodding ûnderskiede, en in totaal dat beide rjochtingen byinoar optelt ek net.

De tawizing folget de UID, net it ikoan

De rige is per UID, en ien UID kin troch mear as ien pakket dield wurde, wylst in sichtbere app wurk oerdrage kin oan in apart komponint dat ûnder syn eigen identiteit draait. In browser-tab dy’t troch in dielde WebView-proses tekene wurdt, in eftergrûnsyngronisaasjetsjinst, of in begeliedend pakket dat njonken de haadapp ynstallearre is, produsearje allegear ferkear dat it gebrûksskerm ûnder in namme toane kin dy’t jo net ferwachte, of ûnder de app dy’t jo wol blokkearre hawwe. In blokkearre pakket en in helper dy’t syn oanfragen draacht binne twa ferskillende subjekten, en de regel besloech mar ien fan beide.

As de sifers ferkeard lykje, fergelykje dan de UID yn stee fan it label. De gebrûks-API wurdt per UID oproppen, en adb shell dumpsys package <package> | grep userId= prints it getal om mei te fergelykjen, sadat twa items mei deselde UID deselde identiteit binne fanút it eachpunt fan de teller.

It tiidfinster kin jo regel foarôfgeane

Gebrûksgegevens wurde yn bakken sammele en polled, net live streamd. In deistich totaal kin de minuten foar it ynskeakeljen fan de blokkade omfetsje, in eftergrûnsyngronisaasje fan it foarige oere, of ferkear dat al ûnderweis wie. In kumulatyt totaal fergelykje mei ien wegere oanfraach en it ferskil in lek neame is in mjitflater, net in firewallbeffining.

Brûk in koarter finster en in frisse start. Notearje de tiidstimpel as jo de regel feroarje, wachtsje ien sammelinterval en sjoch dan allinnich nei gegevens dêrnei. As it totaal trochgroeit yn in finster dat nei de regel begjint, hawwe jo wat te ûndersykjen; as it ophâldt mei groeien, wie de eardere groei skiednis dy’t toand waard.

De VPN-tsjinst is miskien net dy’t jo ynsteld hawwe

In VPN-firewall sjocht allinnich ferkear dat syn eigen tsjinst draacht. As in oare VPN-app start en de aktive ferbining oernimt, sit jo filter net mear yn it paad wylst syn ynterface noch yn de ynstellingen bestiet. Oerslaanlisten per app dogge itselde mei opset, en in profyl dat in app útslút is gjin lek as de app dêrnei wurket.

IPv4, IPv6 en DNS kinne ek útinoar rinne. In filter dat IPv4 behannelet, kin IPv6 of in privee DNS-resolver derbûten litte, sadat in part fan it ferkear fan de app in paad folget dat jo regels nea beskreau. Kontrolearje hokker app op dit stuit de VPN besit en wat de útslutingslist seit foardat jo eat oerskriuwe:

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

Test ien frisse oanfraach en notearje fjouwer feiten

Kies in ûnskatlike oanfraach, doch it ien kear, en skriuw fjouwer feiten op: de jildende regel, de UID fan de app, de netwurksteat en de tiid. Kontrolearje dan oft jo filter de stream logt hat, en oft de bestemming of de gateway deselde ferbining seach. Ien stream dy’t oan beide kanten identifisearre is, is bewiis; in gearfoege totaal is dat net.

In ferdigenbere konklúzje neamt wat wegere waard en hokker waarnimming it befêstige. «De teller gie omheech» is gjin beffining, en «alle gebrûkstellers binne falsk» ek net. In slogan oer de OSI-laach beslist dit net: it earlike antwurd is dat de teller en de blokkade beide korrekt wêze kinne wylst se ferskillende dingen beskriuwe. Android syn NetworkStatsManager-referinsje dokumintearret hoe’t dy bakken oproppen en tawiisd wurde.