तुम्ही तुमच्या 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 संदर्भ हे नोंदवतो की ती बादली कशी विचारली आणि आरोपित केली जातात.

संबंधित लेख