ब्लॉक किया गया Android ऐप फिर भी नेटवर्क उपयोग क्यों दिखाता है
उपयोग काउंटर बाइट्स को एक सीमा पर मापता है, सफल अनुरोध नहीं। समय-विंडो, UID आरोपण और यह जाँचें कि VPN सेवा किस ऐप के पास है।
आप अपने 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 संदर्भ दस्तावेज़ित करता है कि ये बकेट कैसे पूछे और आरोपित किए जाते हैं।