બ્લોક કરેલી 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 રિઝોલ્વરને તેની બહાર રાખી શકે છે, તેથી એપના ટ્રાફિકનો ભાગ એવા માર્ગે જાય છે જે તમારા નિયમોએ ક્યારેય વર્ણવ્યો નહોતો. કંઈ પણ ફરીથી લખતા પહેલાં તપાસો કે કઈ એપ હાલમાં VPNની માલિક છે અને બાકાત સૂચિ શું કહે છે:

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

એક નવી વિનંતિ અજમાવો અને ચાર તથ્યો નોંધો

એક નિર્દોષ વિનંતિ પસંદ કરો, એક વાર કરો, અને ચાર તથ્યો લખો: અમલમાં રહેલો નિયમ, એપનું UID, નેટવર્ક સ્થિતિ અને સમય. પછી તપાસો કે તમારા ફિલ્ટરે પ્રવાહ નોંધ્યો છે અને લક્ષ્ય કે ગેટવેએ એ જ કનેક્શન જોયું છે. બંને બાજુ ઓળખાયેલો એક પ્રવાહ પુરાવો છે; એકત્રિત કુલ નથી.

સમર્થનીય નિષ્કર્ષ જણાવે છે કે શું નકારવામાં આવ્યું અને કયા અવલોકને તેની પુષ્ટિ કરી. «કાઉન્ટર વધ્યું» એ શોધ નથી, અને «બધા વપરાશ કાઉન્ટર નકલી છે» પણ નથી. OSI સ્તરનો સૂત્ર આ નક્કી કરતો નથી: પ્રામાણિક જવાબ એ છે કે કાઉન્ટર અને બ્લોક બંને સાચા હોઈ શકે છે જ્યારે તેઓ અલગ વસ્તુઓ વર્ણવે છે. Androidનો NetworkStatsManager સંદર્ભ દસ્તાવેજ કરે છે કે તે બકેટ કેવી રીતે પૂછાય છે અને આરોપાય છે.