ब्लक गरिएको 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 सन्दर्भले ती बाल्टिन कसरी सोधिन्छन् र आरोपित गरिन्छन् भनी अभिलेख गर्छ।