Защо блокирано Android приложение все още показва мрежово потребление

Блокирате приложение в защитната стена на Android за VPN, приложението спира да работи, а редът му за потребление продължава да расте. Изкушаващото заключение е, че блокирането е пропуснало, или че броячът е повреден. Нито едното не следва. Записът за потребление казва, че байтове са приписани на тази идентичност в някаква точка на наблюдение; той не казва нищо за това дали отдалечена услуга е приела заявка. Щом знаете коя граница е измерена и на коя идентичност е приписана, двете наблюдения спират да си противоречат.

Броячът измерва байтове, а не доставяне

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 resolver извън себе си, така че част от трафика на приложението следва път, който вашите правила никога не са описвали. Проверете кое приложение притежава VPN в момента и какво казва списъкът с изключения, преди да пренапишете нещо:

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

Тествайте една нова заявка и запишете четири факта

Изберете безвредна заявка, направете я веднъж и запишете четири факта: правилото в сила, UID на приложението, състоянието на мрежата и времето. След това проверете дали филтърът е регистрирал потока и дали дестинацията или шлюзът са видели същата връзка. Един поток, идентифициран от двете страни, е доказателство; общият сбор не е.

Защитимо заключение назовава какво е било отказано и кое наблюдение го е потвърдило. „Броячът се вдигна“ не е констатация и „всички броячи на потребление са фалшиви“ също не е. Лозунг за OSI слой не решава това: честният отговор е, че броячът и блокирането могат да бъдат едновременно верни, докато описват различни неща. Справочникът на Android NetworkStatsManager документира как тези групи се запитват и приписват.