Pse një aplikacion Android i bllokuar vazhdon të tregojë përdorim të rrjetit

Ju bllokoni një aplikacion në firewall-in VPN të Android-it, aplikacioni ndalon së funksionuari dhe rreshti i përdorimit vazhdon të rritet. Përfundimi joshës është se bllokimi ka rrjedhur, ose se numëruesi është prishur. Asnjëri nuk rrjedh. Një regjistër përdorimi thotë se bajt u atribuuan atij identiteti në një pikë vëzhgimi; ai nuk thotë asgjë për faktin nëse një shërbim i largët pranoi një kërkesë. Pasi të dini cili kufi u mat dhe cilit identitet iu ngarkua, dy vëzhgimet nuk kundërshtojnë më njëri-tjetrin.

Numëruesi mat bajt, jo dorëzim

Android ia atribuon trafikun një UID dhe e numëron në të dy drejtimet, dhe këtë e bën në një kufi ndërfaqeje, jo në momentin kur kërkesa e një aplikacioni ka sukses.

Një përpjekje lidhjeje e refuzuar gjithsesi lëviz paketa: SYN, reset ose ritransmetimet që vijojnë, plus pyetja DNS që i parapriu të dyjave. Këto bajt ekzistojnë edhe kur asgjë nuk u dorëzua, dhe në disa rrugë numërohen përpara se ndonjë filtër të vendosë çfarë të bëjë me to.

Kjo është arsyeja pse rreshti i një aplikacioni të bllokuar mund të rritet ndërsa çdo kërkesë dështon. Numëruesi përgjigjet «sa bajt iu atribuuan këtij identiteti», jo «a arriti ky identitet në internet». Një grafik nuk mund të dallojë një rrjedhë të pranuar nga një shtrëngim duarsh i refuzuar me mirësjellje, dhe as një total që mbledh të dy drejtimet së bashku.

Atribuimi ndjek UID-në, jo ikonën

Rreshti është për UID, dhe një UID mund të ndahet nga më shumë se një paketë, ndërsa një aplikacion i dukshëm mund t’ia kalojë punën një komponenti të veçantë që punon nën identitetin e vet. Një skedë shfletuesi e vizatuar nga një proces WebView i përbashkët, një shërbim sinkronizimi në sfond ose një paketë shoqëruese e instaluar pranë aplikacionit kryesor prodhojnë trafik që ekrani i përdorimit mund ta shfaqë nën një emër që nuk e prisnit, ose nën aplikacionin që bllokuat. Një paketë e bllokuar dhe një ndihmës që mbart kërkesat e saj janë dy subjekte të ndryshme, dhe rregulli mbulonte vetëm njërin prej tyre.

Kur numrat duken gabim, krahasoni UID dhe jo etiketën. API-ja e përdorimit pyetet sipas UID, dhe adb shell dumpsys package <package> | grep userId= shtyp numrin me të cilin duhet krahasuar, pra dy zëra me të njëjtin UID janë i njëjti identitet nga këndvështrimi i numëruesit.

Dritarja kohore mund t’i paraprijë rregullit tuaj

Të dhënat e përdorimit mblidhen në kova dhe pyeten periodikisht, nuk transmetohen drejtpërdrejt. Një total ditor mund të përfshijë minutat përpara se të aktivizonit bllokimin, një sinkronizim në sfond nga ora e mëparshme ose trafik që ishte tashmë në rrugë. Të krahasosh një total kumulativ me një kërkesë të refuzuar dhe ta quash diferencën rrjedhje është gabim matjeje, jo gjetje e firewall-it.

Përdorni një dritare më të shkurtër dhe një fillim të pastër. Shënoni vulën kohore kur ndryshoni rregullin, prisni një interval mbledhjeje dhe më pas shikoni vetëm të dhënat pas tij. Nëse totali vazhdon të rritet në një dritare që fillon pas rregullit, keni diçka për të hetuar; nëse ndalon së rrituri, rritja e mëparshme ishte histori e shfaqur.

Shërbimi VPN mund të mos jetë ai që konfiguruat

Një firewall VPN sheh vetëm trafikun që mbart shërbimi i tij. Nëse nis një aplikacion tjetër VPN dhe merr lidhjen aktive, filtri juaj nuk është më në rrugë, ndërsa ndërfaqja e tij ekziston ende në cilësime. Listat e anashkalimit sipas aplikacionit e bëjnë të njëjtën gjë qëllimisht, dhe një profil që përjashton një aplikacion nuk është rrjedhje kur aplikacioni më pas funksionon.

Edhe IPv4, IPv6 dhe DNS mund të ndryshojnë. Një filtër që trajton IPv4 mund të lërë IPv6 ose një zgjidhës DNS privat jashtë vetes, kështu që një pjesë e trafikut të aplikacionit ndjek një rrugë që rregullat tuaja nuk e përshkruan kurrë. Kontrolloni cili aplikacion zotëron tani VPN-in dhe çfarë thotë lista e përjashtimeve përpara se të rishkruani diçka:

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

Provoni një kërkesë të re dhe shënoni katër fakte

Zgjidhni një kërkesë të padëmshme, kryejeni një herë dhe shënoni katër fakte: rregullin në fuqi, UID-në e aplikacionit, gjendjen e rrjetit dhe orën. Më pas kontrolloni nëse filtri juaj e regjistroi rrjedhën dhe nëse destinacioni ose porta e kalimit panë të njëjtën lidhje. Një rrjedhë e identifikuar në të dy anët është provë; një total i përgjithshëm nuk është.

Një përfundim i mbrojtshëm emërton çfarë u refuzua dhe cili vëzhgim e konfirmoi. «Numëruesi u rrit» nuk është gjetje, dhe «të gjithë numëruesit e përdorimit janë të rremë» gjithashtu jo. Një parullë për shtresën OSI nuk e zgjidh këtë: përgjigjja e ndershme është se numëruesi dhe bllokimi mund të jenë të dy të saktë ndërsa përshkruajnë gjëra të ndryshme. Referenca NetworkStatsManager e Android dokumenton si pyeten dhe atribuohen këto kova.