Warum eine blockierte Android-App weiterhin Netzwerknutzung anzeigt

Sie blockieren eine App in Ihrer Android-VPN-Firewall, die App funktioniert nicht mehr, und ihre Nutzungszeile steigt weiter. Der verlockende Schluss ist, dass die Sperre durchgesickert ist oder der Zähler defekt ist. Keines von beiden folgt. Ein Nutzungseintrag besagt, dass Bytes an irgendeinem Beobachtungspunkt dieser Identität zugerechnet wurden; er sagt nichts darüber, ob ein entfernter Dienst eine Anfrage angenommen hat. Sobald Sie wissen, welche Grenze gemessen wurde und welcher Identität sie belastet wurde, hören die beiden Beobachtungen auf, sich zu widersprechen.

Der Zähler misst Bytes, nicht Zustellung

Android ordnet Verkehr einer UID zu und zählt ihn in beide Richtungen, und zwar an einer Schnittstellengrenze statt in dem Moment, in dem eine Anfrage einer App erfolgreich ist.

Ein abgelehnter Verbindungsversuch bewegt trotzdem Pakete: das SYN, das Reset oder die folgenden Neuübertragungen, plus die DNS-Abfrage, die beiden vorausging. Diese Bytes existieren, obwohl nichts zugestellt wurde, und auf manchen Pfaden werden sie gezählt, bevor irgendein Filter entscheidet, was mit ihnen geschieht.

Deshalb kann die Zeile einer blockierten App wachsen, während jede Anfrage scheitert. Der Zähler beantwortet „wie viele Bytes dieser Identität zugerechnet wurden“, nicht „hat diese Identität das Internet erreicht“. Ein Diagramm kann einen angenommenen Strom nicht von einem höflich abgelehnten Handshake unterscheiden, und eine Summe, die beide Richtungen addiert, ebenso wenig.

Die Zuordnung folgt der UID, nicht dem Symbol

Die Zeile gilt pro UID, und eine UID kann von mehr als einem Paket geteilt werden, während eine sichtbare App Arbeit an eine separate Komponente übergeben kann, die unter ihrer eigenen Identität läuft. Ein Browser-Tab, den ein gemeinsamer WebView-Prozess rendert, ein Hintergrund-Synchronisierungsdienst oder ein Begleitpaket, das neben der Haupt-App installiert ist, erzeugen alle Verkehr, den der Nutzungsbildschirm unter einem Namen anzeigen kann, den Sie nicht erwartet haben, oder unter der App, die Sie tatsächlich blockiert haben. Ein blockiertes Paket und ein Helfer, der seine Anfragen trägt, sind zwei verschiedene Subjekte, und die Regel deckte nur eines davon ab.

Wenn die Zahlen falsch aussehen, vergleichen Sie die UID statt der Bezeichnung. Die Nutzungs-API wird per UID abgefragt, und adb shell dumpsys package <package> | grep userId= gibt die Zahl aus, mit der Sie vergleichen sollen, sodass zwei Einträge mit derselben UID aus Sicht des Zählers dieselbe Identität sind.

Das Zeitfenster kann Ihrer Regel vorausgehen

Nutzungsdaten werden in Buckets gesammelt und abgefragt, nicht live gestreamt. Eine Tagessumme kann die Minuten vor dem Aktivieren der Sperre enthalten, eine Hintergrund-Synchronisierung aus der vorigen Stunde oder Verkehr, der bereits unterwegs war. Eine kumulative Summe mit einer einzigen abgelehnten Anfrage zu vergleichen und die Differenz ein Leck zu nennen, ist ein Messfehler, kein Firewall-Befund.

Verwenden Sie ein kürzeres Fenster und einen frischen Start. Notieren Sie den Zeitstempel, wenn Sie die Regel ändern, warten Sie ein Erfassungsintervall ab und schauen Sie dann nur auf Daten danach. Steigt die Summe in einem Fenster weiter, das nach der Regel beginnt, haben Sie etwas zu untersuchen; hört sie auf zu steigen, war das frühere Wachstum angezeigte Geschichte.

Der VPN-Dienst ist möglicherweise nicht der, den Sie eingerichtet haben

Eine VPN-Firewall sieht nur Verkehr, den ihr eigener Dienst trägt. Startet eine andere VPN-App und übernimmt die aktive Verbindung, ist Ihr Filter nicht mehr im Pfad, während seine Schnittstelle in den Einstellungen weiterhin existiert. Umgehungslisten pro App tun dasselbe absichtlich, und ein Profil, das eine App ausschließt, ist kein Leck, wenn die App danach funktioniert.

IPv4, IPv6 und DNS können ebenfalls auseinanderlaufen. Ein Filter, der IPv4 behandelt, kann IPv6 oder einen privaten DNS-Resolver außerhalb lassen, sodass ein Teil des App-Verkehrs einen Pfad nimmt, den Ihre Regeln nie beschrieben haben. Prüfen Sie, welche App derzeit das VPN besitzt und was die Ausschlussliste sagt, bevor Sie etwas umschreiben:

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

Testen Sie eine frische Anfrage und notieren Sie vier Fakten

Wählen Sie eine harmlose Anfrage, führen Sie sie einmal aus und notieren Sie vier Fakten: die geltende Regel, die UID der App, den Netzwerkzustand und die Zeit. Prüfen Sie dann, ob Ihr Filter den Fluss protokolliert hat und ob das Ziel oder der Gateway dieselbe Verbindung gesehen hat. Ein auf beiden Seiten identifizierter Fluss ist ein Beleg; eine aggregierte Summe ist keiner.

Eine belastbare Schlussfolgerung benennt, was verweigert wurde und welche Beobachtung es bestätigt hat. „Der Zähler ist gestiegen“ ist kein Befund, und „alle Nutzungszähler sind gefälscht“ ebenso wenig. Ein OSI-Schichten-Slogan entscheidet das nicht: Die ehrliche Antwort ist, dass Zähler und Sperre beide korrekt sein können, während sie verschiedene Dinge beschreiben. Androids NetworkStatsManager-Referenz dokumentiert, wie diese Buckets abgefragt und zugerechnet werden.