Чому заблокований застосунок Android усе ще показує мережевий трафік

Ви блокуєте застосунок у своєму брандмауері VPN на Android, застосунок перестає працювати, а його рядок витрат продовжує зростати. Спокусливий висновок — блокування протекло або лічильник зламався. Жодне не випливає. Запис витрат каже, що байти були віднесені до цієї особистості в деякій точці спостереження; він нічого не каже про те, чи прийняла віддалена служба запит. Щойно ви знаєте, який кордон вимірювався і якій особистості це зараховано, два спостереження перестають суперечити одне одному.

Лічильник вимірює байти, а не доставку

Android відносить трафік до UID і рахує його в обох напрямках, і робить це на межі інтерфейсу, а не в момент, коли запит застосунку завершується успішно.

Відхилена спроба з'єднання все одно рухає пакети: SYN, скидання або наступні повторні передачі, а також DNS-запит, що передував обом. Ці байти існують навіть тоді, коли нічого не доставлено, і на деяких шляхах їх рахують раніше, ніж будь-який фільтр вирішить, що з ними робити.

Ось чому рядок заблокованого застосунку може зростати, поки кожен запит зазнає невдачі. Лічильник відповідає на питання «скільки байтів віднесено до цієї особистості», а не «чи досягла ця особистість інтернету». Графік не може відрізнити прийнятий потік від ввічливо відхиленого рукостискання, і сума, що додає обидва напрямки, теж не може.

Прив'язка йде за UID, а не за значком

Рядок ведеться за UID, і один UID може використовуватися кількома пакетами, тоді як видимий застосунок може передати роботу окремому компоненту, який працює під власною особистістю. Вкладка браузера, яку малює спільний процес WebView, служба фонової синхронізації або супутній пакет, встановлений поруч з основним застосунком, — усі вони створюють трафік, який екран витрат може показати під несподіваним для вас ім'ям або під застосунком, який ви заблокували. Заблокований пакет і помічник, що переносить його запити, — два різні суб'єкти, і правило охоплювало лише один із них.

Коли числа виглядають неправильно, порівнюйте UID, а не мітку. API витрат запитується за UID, і adb shell dumpsys package <package> | grep userId= друкує число, з яким треба порівнювати, тому два записи з однаковим UID з погляду лічильника — та сама особистість.

Часове вікно може передувати вашому правилу

Дані про витрати збираються в кошики й опитуються періодично, а не передаються наживо. Добова сума може включати хвилини до ввімкнення блокування, фонову синхронізацію з попередньої години або трафік, що вже був у дорозі. Порівнювати накопичену суму з одним відхиленим запитом і називати різницю витоком — це помилка вимірювання, а не знахідка брандмауера.

Використовуйте коротше вікно й чистий старт. Запишіть позначку часу, коли змінюєте правило, зачекайте один інтервал збору, а потім дивіться лише на дані після нього. Якщо сума продовжує зростати у вікні, що починається після правила, вам є що досліджувати; якщо зростання припинилося, попереднє зростання було відображуваною історією.

Служба VPN може бути не тією, яку ви налаштували

Брандмауер VPN бачить лише трафік, який несе його власна служба. Якщо запускається інший застосунок VPN і забирає активне з'єднання, ваш фільтр уже не на шляху, хоча його інтерфейс ще є в налаштуваннях. Списки обходу за застосунками роблять те саме навмисно, а профіль, що виключає застосунок, не є витоком, коли застосунок потім працює.

IPv4, IPv6 і DNS також можуть розходитися. Фільтр, що обробляє IPv4, може залишити IPv6 або приватний DNS-резолвер поза собою, тож частина трафіку застосунку йде шляхом, якого ваші правила ніколи не описували. Перевірте, який застосунок зараз володіє VPN і що каже список винятків, перш ніж щось переписувати:

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

Перевірте один свіжий запит і запишіть чотири факти

Виберіть нешкідливий запит, виконайте його один раз і запишіть чотири факти: чинне правило, UID застосунку, стан мережі та час. Потім перевірте, чи зафіксував ваш фільтр потік і чи побачили пункт призначення або шлюз те саме з'єднання. Один потік, розпізнаний з обох боків, — це доказ; сукупна сума — ні.

Захищуваний висновок називає, що було відхилено і яке спостереження це підтвердило. «Лічильник зріс» — не знахідка, і «всі лічильники витрат підроблені» теж. Гасло про рівень OSI цього не вирішує: чесна відповідь полягає в тому, що лічильник і блокування можуть бути обидва правильними, описуючи різні речі. Довідка Android NetworkStatsManager документує, як ці кошики опитуються й відносяться.