Зашто блокирана Android апликација и даље приказује мрежни саобраћај
Бројач потрошње мери бајтове на једној граници, а не успешан захтев. Проверите временски прозор, додељивање UID-у и која апликација поседује VPN услугу.
Блокирате апликацију у свом 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 резолвер изван себе, па део саобраћаја апликације следи путању коју ваша правила никада нису описала. Проверите која апликација тренутно поседује VPN и шта каже листа изузетака пре него што било шта препишете:
adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail
Тестирајте један свеж захтев и запишите четири чињенице
Изаберите безазлен захтев, извршите га једном и запишите четири чињенице: правило на снази, UID апликације, стање мреже и време. Затим проверите да ли је ваш филтер забележио ток и да ли су одредиште или пролаз видели исту везу. Један ток идентификован на обе стране је доказ; збирни укупан износ није.
Одбрањив закључак именује шта је одбијено и које посматрање је то потврдило. „Бројач је порастао“ није налаз, а „сви бројачи потрошње су лажни“ такође није. Слоган о OSI слоју то не решава: поштен одговор је да бројач и блокада могу обоје бити тачни док описују различите ствари. Android референца NetworkStatsManager документује како се те корпе испитују и додељују.