Kial blokita Android-a aplikaĵo ankoraŭ montras retuzon

Vi blokas aplikaĵon en via Android VPN-fajroŝirmilo, la aplikaĵo ĉesas funkcii, kaj ĝia uza vico daŭre grimpas. La alloga konkludo estas, ke la blokado likis, aŭ ke la kalkulilo difektiĝis. Nek unu sekvas. Uza rikordo diras, ke bajtoj estis atribuitaj al tiu identeco ĉe iu observpunkto; ĝi diras nenion pri tio, ĉu fora servo akceptis peton. Post kiam vi scias, kiu limo estis mezurita kaj al kiu identeco ĝi estis ŝargita, la du observoj ĉesas kontraŭdiri unu la alian.

La kalkulilo mezuras bajtojn, ne liveron

Android atribuas trafikon al UID kaj kalkulas ĝin en ambaŭ direktoj, kaj ĝi faras tion ĉe interfaca limo, ne en la momento, kiam peto de aplikaĵo sukcesas.

Rifuzita konektoprovo tamen movas pakaĵojn: la SYN, la reset aŭ la ripetoj, kiuj sekvas, plus la DNS-demando, kiu antaŭis ambaŭ. Tiuj bajtoj ekzistas eĉ kiam nenio estis liverita, kaj sur iuj vojoj ili estas kalkulitaj antaŭ ol ajna filtrilo decidas, kion fari pri ili.

Tial la vico de blokita aplikaĵo povas kreski dum ĉiu peto malsukcesas. La kalkulilo respondas «kiom da bajtoj estis atribuitaj al ĉi tiu identeco», ne «ĉu ĉi tiu identeco atingis la interreton». Diagramo ne povas distingi akceptitan fluon de ĝentile rifuzita manpremo, kaj nek povas totalo, kiu sumas ambaŭ direktojn kune.

La atribuo sekvas la UID-on, ne la ikonon

La vico estas laŭ UID, kaj unu UID povas esti dividita de pli ol unu pakaĵo, dum videbla aplikaĵo povas transdoni laboron al aparta komponanto, kiu funkcias sub sia propra identeco. Retumila langeto desegnita de komuna WebView-procezo, fona sinkroniga servo, aŭ akompana pakaĵo instalita apud la ĉefa aplikaĵo ĉiuj produktas trafikon, kiun la uza ekrano povas montri sub nomo, kiun vi ne atendis, aŭ sub la aplikaĵo, kiun vi ja blokis. Blokita pakaĵo kaj helpanto, kiu portas ĝiajn petojn, estas du malsamaj subjektoj, kaj la regulo kovris nur unu el ili.

Kiam la nombroj aspektas malĝustaj, komparu la UID-on anstataŭ la etikedon. La uza API estas demandata laŭ UID, kaj adb shell dumpsys package <package> | grep userId= presas la nombron, kun kiu kompari, do du enskriboj kun la sama UID estas la sama identeco el la vidpunkto de la kalkulilo.

La tempfenestro eble antaŭas vian regulon

Uzaj datumoj estas kolektataj en korboj kaj demandataj, ne elsendataj vive. Ĉiutaga totalo povas inkluzivi la minutojn antaŭ ol vi ŝaltis la blokadon, fonan sinkronigon el la antaŭa horo, aŭ trafikon jam survoje. Kompari akumulitan totalon kun unu rifuzita peto kaj nomi la diferencon liko estas mezureraro, ne trovaĵo de fajroŝirmilo.

Uzu pli mallongan fenestron kaj freŝan komencon. Notu la tempostampon, kiam vi ŝanĝas la regulon, atendu unu kolektan intervalon, poste rigardu nur datumojn post ĝi. Se la totalo daŭre kreskas en fenestro, kiu komenciĝas post la regulo, vi havas ion esplorendan; se ĝi ĉesas kreski, la pli frua kresko estis montrata historio.

La VPN-servo eble ne estas tiu, kiun vi agordis

VPN-fajroŝirmilo vidas nur trafikon, kiun portas ĝia propra servo. Se alia VPN-aplikaĵo ekfunkcias kaj prenas la aktivan konekton, via filtrilo ne plu estas sur la vojo, dum ĝia interfaco ankoraŭ ekzistas en la agordoj. Listoj de preterpaso laŭ aplikaĵo faras la samon intence, kaj profilo, kiu ekskludas aplikaĵon, ne estas liko, kiam la aplikaĵo poste funkcias.

IPv4, IPv6 kaj DNS ankaŭ povas diverĝi. Filtrilo, kiu traktas IPv4, povas lasi IPv6 aŭ privatan DNS-resolvilon ekster ĝi, do parto de la trafiko de la aplikaĵo sekvas vojon, kiun viaj reguloj neniam priskribis. Kontrolu, kiu aplikaĵo nun posedas la VPN-on kaj kion diras la ekskluda listo antaŭ ol vi reverku ion:

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

Testu unu freŝan peton kaj notu kvar faktojn

Elektu sendanĝeran peton, faru ĝin unufoje, kaj notu kvar faktojn: la validan regulon, la UID de la aplikaĵo, la retan staton kaj la tempon. Poste kontrolu, ĉu via filtrilo protokolis la fluon, kaj ĉu la celo aŭ la kluzo vidis la saman konekton. Unu fluo identigita ambaŭflanke estas pruvo; sumigita totalo ne estas.

Defendebla konkludo nomas, kio estis malpermesita kaj kiu observo konfirmis tion. «La kalkulilo altiĝis» ne estas trovaĵo, kaj «ĉiuj uzkalkuliloj estas falsaj» ankaŭ ne. Slogano pri OSI-tavolo ne solvas ĉi tion: la honesta respondo estas, ke la kalkulilo kaj la blokado povas ambaŭ esti ĝustaj, dum ili priskribas malsamajn aferojn. La referenco NetworkStatsManager de Android dokumentas, kiel tiuj korboj estas demandataj kaj atribuataj.