Android वर VPN जोडलेला आहे का हे कोडमधून कसे तपासावे
Android मध्ये VPN जोडणीची स्थिती देणारा getter नाही. नेटवर्क क्षमता विचारा, ट्रान्सपोर्ट बदलांचे निरीक्षण करा आणि ॲपची संमती, उपकरणाची स्थिती व सर्व्हरचा पुरावा वेगळे ठेवा.
Android ला VPN जोडलेला आहे का असे विचारता येत नाही. VpnService जोडणीची स्थिती देणारा getter उघड करत नाही, आणि स्टेटस बारमधील किल्लीचे चिन्ह सिस्टम काढते, तुमचे ॲप वाचू शकणारे काहीही नाही. तुम्ही करू शकता ते म्हणजे कनेक्टिव्हिटी स्टॅकला अधिक अरुंद प्रश्न विचारणे: या ॲपची रहदारी कोणते नेटवर्क वापरत आहे, आणि ते नेटवर्क VPN ट्रान्सपोर्ट वाहत आहे का. हे पुस्तिका चुकीचे सकारात्मक टाळणाऱ्या क्रमाने तपासण्या घेते, उपकरणावरील शेल आदेशापासून ॲपमध्ये सोडलेल्या कॉलबॅकपर्यंत.
ॲपचा कोड स्पर्श करण्यापूर्वी शेलमधून उपकरण तपासा
प्रथम आधारभूत स्थिती घ्या. adb shell dumpsys connectivity सिस्टमला माहीत असलेले प्रत्येक नेटवर्क छापते, आणि प्रत्येक ब्लॉक त्याचे ट्रान्सपोर्ट सूचीबद्ध करतो, त्यामुळे VPN नेटवर्क त्या यादीत VPN सह दिसते. सर्वांपेक्षा आधी डीफॉल्ट नेटवर्क ब्लॉक वाचा, नंतर तोच ट्रान्सपोर्ट वाहणारी इतर नेटवर्क शोधा.
दोन आउटपुट वेगवेगळ्या प्रश्नांची उत्तरे देतात. VPN नेटवर्क अस्तित्वात आहे का हे तुमचे ॲप ते वापरत आहे का याच्याशी समान नाही, आणि कामाचा प्रोफाइल किंवा दुसरा वापरकर्ता असलेल्या उपकरणावर तुमची प्रक्रिया इंटरनेटशी थेट बोलत असतानाही दोन्ही एकाच वेळी खरे असू शकतात. तुमचे सॉकेट काय करतात हे सक्रिय नेटवर्कची ओळ ठरवते.
ॲप वापरत असलेल्या नेटवर्कची विचारणा करा
कोडमध्ये क्षमता चाचणी चार ओळींची आहे. मॅनिफेस्टमध्ये ACCESS_NETWORK_STATE मागा, नंतर सक्रिय नेटवर्कच्या क्षमता VPN ट्रान्सपोर्टशी तुलना करा:
ConnectivityManager cm = (ConnectivityManager)
context.getSystemService(Context.CONNECTIVITY_SERVICE);
Network active = cm.getActiveNetwork();
NetworkCapabilities caps = cm.getNetworkCapabilities(active);
boolean vpnInUse = caps != null
&& caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);
उत्तर मुद्दाम अरुंद आहे: ॲपचे डीफॉल्ट नेटवर्क सध्या VPN आहे का. कोणते VPN, ते तुमचे आहे का, किंवा बोगदा पलीकडच्या टोकापर्यंत पोहोचतो का याबद्दल ते काहीही सांगत नाही. true ला “रहदारी कोणत्यातरी बोगद्यातून बाहेर जाते” असे समजा आणि तुमची स्वतःची नोंद वेगळी ठेवा. तीन गोष्टी गुपचूप एकाच वेळी सूचित करणारा बुलियन म्हणजे वापरकर्ता VPN मधून ब्राउझ करत असताना सेटिंग्ज स्क्रीन VPN बंद असल्याचे का नोंदवते याचे कारण.
उलट, कोणतेही VPN नेटवर्क अस्तित्वात आहे का हे जाणून घ्यायचे असेल तर cm.getAllNetworks() वर पुनरावृत्ती करा आणि प्रत्येक क्षमता संच तपासा. इतर ॲप्सना व्यापणाऱ्या पण तुमच्यास न व्यापणाऱ्या ॲप-विशिष्ट VPNवर चालणाऱ्या उपकरणावर दोन उत्तरे वेगळी पडतात, आणि तेच वेगळेपण स्पष्टपणे सुरू असलेला VPN ॲपला दिसत नाही अशा बहुतेक बग अहवालांचा स्रोत आहे.
पोलिंगऐवजी बदलांचे निरीक्षण करा
टाइमरवर पोलिंग करणे या प्रश्नासाठी चुकीचा आकार आहे, कारण स्थिती बदल घटना म्हणून येतात. VPN ट्रान्सपोर्टशी जुळणारी विनंती नोंदवा आणि जुळणारे नेटवर्क दिसल्यास, नाहीसे झाल्यास किंवा बदलल्यास फ्रेमवर्कने तुम्हाला सांगावे:
NetworkRequest request = new NetworkRequest.Builder()
.addTransportType(NetworkCapabilities.TRANSPORT_VPN)
.removeCapability(NetworkCapabilities.NET_CAPABILITY_NOT_VPN)
.build();
cm.registerNetworkCallback(request, callback);
VPN नेटवर्क कधीही NET_CAPABILITY_NOT_VPN वाहत नाही, त्यामुळे स्पष्ट काढणे हेतू नोंदवते. त्याशिवायही विनंती जुळते, पण पुढील व्यक्तीला कोड वाचताना ते स्वतः हेरावे लागते.
नोंदणी निरीक्षण आवश्यक असलेल्या व्याप्तीची आहे, सहसा स्क्रीन किंवा फोरग्राउंड सेवा. onStop किंवा onDestroy मध्ये नोंदणी रद्द करा, आणि आधीच गेलेल्या ॲक्टिव्हिटीला कॉलबॅक जोडून ठेवू नका. दृश्य घटक नसलेले ॲप कायमस्वरूपी निरीक्षकासाठी वाईट यजमान आहे, आणि विसरलेले कॉलबॅकच कॉन्फिगरेशन बदलानंतर कोसळतात.
तीन प्रश्न वेगळे ठेवा
या क्षेत्रातील बहुतेक गोंधळ तीन वेगवेगळ्या तपासण्यांना एक मानण्यातून येतो. त्या वेगळ्या API वापरतात, आणि एक खरे असताना इतर खोटे असू शकतात.
| Question | How you answer it | What a yes means |
|---|---|---|
| Did the user grant VPN consent to my app? | VpnService.prepare() returns null | Consent exists; the tunnel may still be down |
| Is the device sending default traffic through a VPN? | TRANSPORT_VPN on the active network | Something is tunneling, not necessarily your app |
| Did this request arrive through the VPN? | Source address seen by the server | Proof for that connection, nothing wider |
तिसरी ओळ लोक क्लायंटवर उत्तर देण्याचा प्रयत्न करतात ती आहे, आणि तिथे उत्तर देता येत नाही. VPN क्लायंटना स्वतःचा पत्ता पूल द्या आणि सर्व्हरवर स्रोत पत्ता वाचा; सत्राच्या मध्यात वापरकर्त्याने बोगदा बदलला तरी टिकणारा हाच एकमेव पुरावा आहे.
चुकीचे सकारात्मक वगळणारा पडताळणी क्रम
अजूनही प्रचलित असलेला जुना नमुना कोड getNetworkInfo(ConnectivityManager.TYPE_VPN) ला कॉल करतो. तो कॉल डेप्रिकेटेड आहे, आणि अनेक आवृत्त्यांमध्ये VPN जोडलेला असतानाही null परत देत असे, म्हणूनच कॉपी केलेले तुकडे कार्यरत उपकरणावर तुटलेले दिसतात. क्षमता तपासण्या हा सापळा टाळतात आणि Android 5.0 पासून सारख्याच वागतात. अजूनही तो कॉल करणारा कोडबेस सांभाळत असाल तर फॉलबॅकमध्ये गुंडाळण्याऐवजी कॉलच बदला, कारण चुकीचे उत्तर प्रथम निर्माण करणारा तोच फॉलबॅक होता.
एका शॉर्टकटला इशारा हवा. बाह्य सेवा नोंदवते तो सार्वजनिक पत्ता VPN च्या निर्गम पत्त्याशी तुलना करणे मार्गाबद्दल काहीतरी सिद्ध करते, पण प्रत्येक तपासणीत तृतीय-पक्ष विनंती जोडते, ती सेवा सुरू राहण्यावर अवलंबून असते, आणि कॅशे होऊ शकते किंवा अडवली जाऊ शकते. ती हाताने करायचे निदान म्हणून ठेवा, ॲपमधील स्थिती तपासणी म्हणून कधीही नाही.
या क्रमाने तपासण्या करा आणि वापरकर्त्याच्या अहवालाशी विसंगत पडणाऱ्या पहिल्यावर थांबा: शेलमधील ट्रान्सपोर्ट यादी, सक्रिय नेटवर्क क्षमता, बोगदा सुरू-बंद करतानाच्या कॉलबॅक घटना, नंतर सर्व्हर-बाजूचा स्रोत पत्ता. चारही जुळले तरी ॲप चुकीचे वागत असेल, तर बग Android च्या नेटवर्क दृष्टिकोनात नाही, तुमच्या स्वतःच्या स्थिती यंत्रात आहे.