Bakit ang naka-block na Android app ay nagpapakita pa rin ng paggamit ng network

Hinaharang mo ang isang app sa iyong Android VPN firewall, tumitigil ito sa paggana, at patuloy na umaakyat ang row ng paggamit nito. Ang nakakahikayat na konklusyon ay tumagas ang block, o sira ang counter. Wala sa dalawa ang sumusunod. Sinasabi ng talaan ng paggamit na ang mga byte ay iniatas sa identity na iyon sa isang punto ng pagmamasid; wala itong sinasabi tungkol sa kung tinanggap ng isang malayong serbisyo ang kahilingan. Kapag alam mo kung aling hangganan ang sinukat at kung aling identity ito iniatas, hindi na nagkakasalungatan ang dalawang obserbasyon.

Sumusukat ang counter ng bytes, hindi ng paghahatid

Iniaatas ng Android ang trapiko sa isang UID at binibilang ito sa magkabilang direksyon, at ginagawa ito sa hangganan ng interface, hindi sa sandaling magtagumpay ang kahilingan ng app.

Ang tinanggihang pagtatangkang kumonekta ay gumagalaw pa rin ng mga packet: ang SYN, ang reset o ang mga sumusunod na retransmission, kasama ang DNS query na nauna sa dalawa. Umiiral ang mga byte na iyon kahit walang naipadala, at sa ilang landas binibilang ang mga ito bago magpasya ang anumang filter kung ano ang gagawin sa mga ito.

Kaya lumalaki ang row ng naka-block na app habang bumabagsak ang bawat kahilingan. Sinasagot ng counter ang «ilang byte ang iniatas sa identity na ito», hindi ang «naabot ba ng identity na ito ang internet». Hindi kayang ipagkaiba ng graph ang tinanggap na stream sa magalang na tinanggihang handshake, at hindi rin kaya ng kabuuang nagsasama ng dalawang direksyon.

Ang attribution ay sumusunod sa UID, hindi sa icon

Ang row ay bawat UID, at isang UID ay maaaring hatian ng higit sa isang package, habang ang nakikitang app ay maaaring magpasa ng trabaho sa hiwalay na component na tumatakbo sa sarili nitong identity. Isang browser tab na iginuhit ng shared WebView process, isang background sync service, o isang companion package na naka-install sa tabi ng pangunahing app ay gumagawa ng trapikong maaaring ipakita ng usage screen sa ilalim ng pangalang hindi mo inaasahan, o sa ilalim ng app na hinarang mo. Ang naka-block na package at ang helper na nagdadala ng mga kahilingan nito ay dalawang magkaibang paksa, at sakop lamang ng patakaran ang isa sa kanila.

Kapag mukhang mali ang mga numero, ihambing ang UID at hindi ang label. Ang usage API ay tinatanong sa pamamagitan ng UID, at ipiniprint ng adb shell dumpsys package <package> | grep userId= ang numerong ihahambing, kaya ang dalawang entry na may parehong UID ay iisang identity mula sa pananaw ng counter.

Maaaring mas maaga ang time window kaysa sa iyong patakaran

Ang data ng paggamit ay kinokolekta sa mga bucket at pinipiling tanungin nang pana-panahon, hindi live na naka-stream. Ang arawang kabuuan ay maaaring kabilangan ng mga minuto bago mo i-enable ang block, isang background sync mula sa nakaraang oras, o trapikong nasa byahe na. Ang paghahambing ng cumulative na kabuuan sa isang tinanggihang kahilingan at pagtawag sa pagkakaiba na leak ay pagkakamali sa pagsukat, hindi natuklasan ng firewall.

Gumamit ng mas maikling window at malinis na simula. Itala ang timestamp kapag binago mo ang patakaran, maghintay ng isang interval ng koleksyon, pagkatapos ay tingnan lamang ang data pagkatapos nito. Kung patuloy na tumataas ang kabuuan sa window na nagsisimula pagkatapos ng patakaran, mayroon kang dapat siyasatin; kung tumitigil ito, ang naunang paglaki ay history na ipinapakita.

Maaaring hindi ang VPN service ang na-configure mo

Ang VPN firewall ay nakakakita lamang ng trapikong dinadala ng sarili nitong serbisyo. Kung may ibang VPN app na magsimula at kumuha ng aktibong koneksyon, wala na ang filter mo sa landas habang umiiral pa ang interface nito sa mga setting. Ginagawa rin ito ng mga per-app bypass list nang sinasadya, at ang profile na nagbubukod sa isang app ay hindi leak kapag gumana na ang app.

Maaari ring magkaiba ang IPv4, IPv6 at DNS. Ang filter na humahawak ng IPv4 ay maaaring mag-iwan ng IPv6 o isang pribadong DNS resolver sa labas nito, kaya bahagi ng trapiko ng app ay sumusunod sa landas na hindi kailanman inilarawan ng iyong mga patakaran. Suriin kung aling app ang may-ari ng VPN ngayon at ano ang sinasabi ng exclusion list bago ka magsulat muli ng anuman:

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

Subukan ang isang bagong kahilingan at itala ang apat na katotohanan

Pumili ng hindi mapanganib na kahilingan, gawin ito nang isang beses, at isulat ang apat na katotohanan: ang patakarang umiiral, ang UID ng app, ang kalagayan ng network at ang oras. Pagkatapos ay suriin kung naitala ng filter mo ang daloy, at kung nakita ng destinasyon o gateway ang parehong koneksyon. Ang isang daloy na nakilala sa magkabilang panig ay ebidensya; ang pinagsama-samang kabuuan ay hindi.

Ang maipagtatanggol na konklusyon ay nagbabanggit kung ano ang tinanggihan at aling obserbasyon ang nagpatunay nito. Ang «tumaas ang counter» ay hindi natuklasan, at ang «lahat ng counter ng paggamit ay peke» ay hindi rin. Hindi ito nilulutas ng isang slogan tungkol sa OSI layer: ang tapat na sagot ay maaaring tama ang counter at ang block nang sabay habang naglalarawan sila ng magkaibang bagay. Ang sanggunian ng NetworkStatsManager ng Android ay nagdodokumento kung paano tinatanong at iniaatas ang mga bucket na iyon.