Dlaczego zablokowana aplikacja Android nadal pokazuje zużycie sieci

Blokujesz aplikację w zaporze VPN Androida, aplikacja przestaje działać, a jej wiersz zużycia nadal rośnie. Kuszący wniosek jest taki, że blokada przeciekła albo że licznik jest zepsuty. Żaden z nich nie wynika. Zapis zużycia mówi, że bajty przypisano tej tożsamości w jakimś punkcie obserwacji; nie mówi nic o tym, czy zdalna usługa przyjęła żądanie. Gdy wiadomo, która granica została zmierzona i której tożsamości to przypisano, oba spostrzeżenia przestają sobie przeczyć.

Licznik mierzy bajty, a nie dostarczenie

Android przypisuje ruch do UID i liczy go w obu kierunkach, i robi to na granicy interfejsu, a nie w momencie, gdy żądanie aplikacji się powiedzie.

Odrzucona próba połączenia i tak przemieszcza pakiety: SYN, reset lub następujące po nich retransmisje, a także zapytanie DNS, które poprzedzało oba. Te bajty istnieją, nawet gdy nic nie dostarczono, a na niektórych ścieżkach są liczone, zanim jakikolwiek filtr zdecyduje, co z nimi zrobić.

Dlatego wiersz zablokowanej aplikacji może rosnąć, podczas gdy każde żądanie zawodzi. Licznik odpowiada na pytanie „ile bajtów przypisano tej tożsamości”, a nie „czy ta tożsamość dotarła do internetu”. Wykres nie odróżni zaakceptowanego strumienia od uprzejmie odrzuconego uścisku dłoni, a suma dodająca oba kierunki też nie.

Przypisanie idzie za UID, a nie za ikoną

Wiersz jest na UID, a jeden UID może być współdzielony przez więcej niż jeden pakiet, podczas gdy widoczna aplikacja może przekazać pracę osobnemu komponentowi działającemu pod własną tożsamością. Karta przeglądarki rysowana przez współdzielony proces WebView, usługa synchronizacji w tle albo pakiet towarzyszący zainstalowany obok głównej aplikacji — wszystkie generują ruch, który ekran zużycia może pokazać pod nazwą, której się nie spodziewałeś, lub pod aplikacją, którą faktycznie zablokowałeś. Zablokowany pakiet i pomocnik przenoszący jego żądania to dwa różne podmioty, a reguła obejmowała tylko jeden z nich.

Gdy liczby wyglądają źle, porównuj UID, a nie etykietę. API zużycia odpytuje się po UID, a adb shell dumpsys package <package> | grep userId= wypisuje liczbę, z którą trzeba porównać, więc dwa wpisy z tym samym UID to z punktu widzenia licznika ta sama tożsamość.

Okno czasowe może poprzedzać twoją regułę

Dane o zużyciu są zbierane w kubełkach i odpytywane okresowo, a nie przesyłane na żywo. Suma dzienna może obejmować minuty przed włączeniem blokady, synchronizację w tle z poprzedniej godziny albo ruch, który już był w drodze. Porównywanie sumy skumulowanej z jednym odrzuconym żądaniem i nazywanie różnicy wyciekiem to błąd pomiaru, a nie ustalenie zapory.

Użyj krótszego okna i czystego startu. Zapisz znacznik czasu, gdy zmieniasz regułę, odczekaj jeden interwał zbierania, a potem patrz tylko na dane po nim. Jeśli suma nadal rośnie w oknie, które zaczyna się po regule, masz co badać; jeśli przestaje rosnąć, wcześniejszy wzrost był wyświetlaną historią.

Usługa VPN może nie być tą, którą skonfigurowałeś

Zapora VPN widzi tylko ruch, który niesie jej własna usługa. Jeśli uruchomi się inna aplikacja VPN i przejmie aktywne połączenie, twój filtr nie jest już na ścieżce, choć jego interfejs nadal istnieje w ustawieniach. Listy obejścia dla poszczególnych aplikacji robią to samo celowo, a profil wykluczający aplikację nie jest wyciekiem, gdy aplikacja potem działa.

IPv4, IPv6 i DNS też mogą się rozchodzić. Filtr obsługujący IPv4 może zostawić IPv6 lub prywatny resolver DNS poza sobą, więc część ruchu aplikacji idzie ścieżką, której twoje reguły nigdy nie opisały. Sprawdź, która aplikacja obecnie posiada VPN i co mówi lista wyjątków, zanim cokolwiek przepiszesz:

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

Przetestuj jedno świeże żądanie i zapisz cztery fakty

Wybierz nieszkodliwe żądanie, wykonaj je raz i zapisz cztery fakty: obowiązującą regułę, UID aplikacji, stan sieci i czas. Następnie sprawdź, czy filtr zalogował strumień i czy cel lub brama widziały to samo połączenie. Jeden strumień zidentyfikowany po obu stronach jest dowodem; suma zbiorcza nie jest.

Obronny wniosek nazywa to, czego odmówiono, i obserwację, która to potwierdziła. „Licznik wzrósł” nie jest ustaleniem, a „wszystkie liczniki zużycia są fałszywe” też nie. Slogan o warstwie OSI tego nie rozstrzyga: uczciwa odpowiedź brzmi, że licznik i blokada mogą być jednocześnie poprawne, opisując różne rzeczy. Dokumentacja NetworkStatsManager dla Androida opisuje, jak te kubełki są odpytywane i przypisywane.