Waarom een geblokkeerde Android-app nog steeds netwerkgebruik toont

Je blokkeert een app in je Android-VPN-firewall, de app stopt met werken en de gebruikersregel blijft stijgen. De verleidelijke conclusie is dat de blokkade is gelekt, of dat de teller stuk is. Geen van beide volgt. Een gebruiksrecord zegt dat bytes op een of ander observatiepunt aan die identiteit zijn toegewezen; het zegt niets over de vraag of een externe dienst een verzoek heeft geaccepteerd. Zodra je weet welke grens is gemeten en aan welke identiteit het is toegerekend, houden de twee waarnemingen op elkaar tegen te spreken.

De teller meet bytes, niet levering

Android kent verkeer toe aan een UID en telt het in beide richtingen, en dat doet het op een interfacegrens in plaats van op het moment dat een verzoek van een app slaagt.

Een geweigerde verbindingspoging verplaatst nog steeds pakketten: de SYN, de reset of de daaropvolgende hertransmissies, plus de DNS-query die aan beide voorafging. Die bytes bestaan zelfs als er niets is geleverd, en op sommige paden worden ze geteld voordat een filter beslist wat ermee gebeurt.

Daarom kan de regel van een geblokkeerde app groeien terwijl elk verzoek mislukt. De teller beantwoordt „hoeveel bytes zijn aan deze identiteit toegewezen“, niet „heeft deze identiteit het internet bereikt“. Een grafiek kan een geaccepteerde stream niet onderscheiden van een beleefd geweigerde handdruk, en een totaal dat beide richtingen optelt ook niet.

De toewijzing volgt de UID, niet het pictogram

De regel is per UID, en één UID kan door meer dan één pakket worden gedeeld, terwijl een zichtbare app werk kan overdragen aan een aparte component die onder zijn eigen identiteit draait. Een browsertab die door een gedeeld WebView-proces wordt getekend, een achtergrondsynchronisatiedienst of een begeleidend pakket dat naast de hoofdapp is geïnstalleerd, produceren allemaal verkeer dat het gebruiksscherm kan tonen onder een naam die je niet verwachtte, of onder de app die je wel hebt geblokkeerd. Een geblokkeerd pakket en een helper die de verzoeken draagt, zijn twee verschillende subjecten, en de regel dekte er maar één van.

Als de cijfers er verkeerd uitzien, vergelijk dan de UID en niet het label. De gebruiks-API wordt per UID bevraagd, en adb shell dumpsys package <package> | grep userId= drukt het getal af waarmee je moet vergelijken, dus twee vermeldingen met dezelfde UID zijn dezelfde identiteit vanuit het oogpunt van de teller.

Het tijdvenster kan je regel voorafgaan

Gebruiksgegevens worden in emmers verzameld en gepeild, niet live gestreamd. Een dagtotaal kan de minuten vóór het inschakelen van de blokkade bevatten, een achtergrondsynchronisatie van het vorige uur of verkeer dat al onderweg was. Een cumulatief totaal vergelijken met één geweigerd verzoek en het verschil een lek noemen is een meetfout, geen firewallbevinding.

Gebruik een korter venster en een schone start. Noteer de tijdstempel wanneer je de regel wijzigt, wacht één verzamelinterval en kijk daarna alleen naar gegevens daarna. Als het totaal blijft stijgen in een venster dat na de regel begint, heb je iets om te onderzoeken; als het stopt met stijgen, was de eerdere groei weergegeven geschiedenis.

De VPN-dienst is misschien niet degene die je hebt ingesteld

Een VPN-firewall ziet alleen verkeer dat zijn eigen dienst draagt. Als een andere VPN-app start en de actieve verbinding overneemt, zit je filter niet meer in het pad terwijl de interface ervan nog in de instellingen bestaat. Lijsten voor omzeiling per app doen hetzelfde met opzet, en een profiel dat een app uitsluit is geen lek wanneer de app daarna werkt.

IPv4, IPv6 en DNS kunnen ook uiteenlopen. Een filter dat IPv4 afhandelt, kan IPv6 of een privé-DNS-resolver erbuiten laten, zodat een deel van het verkeer van de app een pad volgt dat je regels nooit hebben beschreven. Controleer welke app op dit moment de VPN bezit en wat de uitsluitingslijst zegt voordat je iets herschrijft:

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

Test één vers verzoek en noteer vier feiten

Kies een onschadelijk verzoek, voer het één keer uit en schrijf vier feiten op: de geldende regel, de UID van de app, de netwerkstatus en de tijd. Controleer dan of je filter de stroom heeft gelogd, en of de bestemming of de gateway dezelfde verbinding zag. Eén aan beide zijden geïdentificeerde stroom is bewijs; een samengevat totaal is dat niet.

Een verdedigbare conclusie benoemt wat is geweigerd en welke waarneming dat bevestigde. „De teller steeg“ is geen bevinding, en „alle gebruikstellers zijn nep“ ook niet. Een OSI-laagslogan beslecht dit niet: het eerlijke antwoord is dat de teller en de blokkade beide correct kunnen zijn terwijl ze verschillende dingen beschrijven. Androids NetworkStatsManager-referentie documenteert hoe die emmers worden bevraagd en toegewezen.