प्रबंधित कार्य ऐप के लिए VPN और प्रॉक्सी स्थिति कैसे पढ़ें

प्रबंधित फ़ोन पर एक कार्य ऐप विफल होता है, कोई VPN टॉगल देखता है, उसे चालू पाता है और पथ को स्वस्थ घोषित कर देता है। इनमें से अधिकांश निदान यहीं रुक जाते हैं, और यह बहुत जल्दी है: सक्रिय VPN ट्रांसपोर्ट यह नहीं कहता कि इस ऐप के अनुरोधों ने उसका उपयोग किया, और जो प्रॉक्सी वास्तव में लागू होता है वह प्रति-ऐप हो सकता है या सेटिंग्स में दिखने के बजाय PAC फ़ाइल द्वारा चुना जा सकता है। जिस विशिष्ट ऐप और प्रोफ़ाइल को आप डीबग कर रहे हैं उसी से शुरू करें, फिर प्लेटफ़ॉर्म का अपना पथ-दृष्टिकोण पढ़ें।

ऐप और उसकी प्रोफ़ाइल से शुरू करें

कार्य बैज वाला ऐप आमतौर पर अपनी नेटवर्क नीति वाली अलग प्रोफ़ाइल में चलता है। उसी फ़ोन पर निजी ब्राउज़र उसका प्रमाण नहीं है, और अलग प्रबंधन वाले सहकर्मी के डिवाइस का परिणाम भी नहीं है। कुछ भी पढ़ने से पहले नोट करें कि ऐप किस प्रोफ़ाइल का है।

सेटिंग्स में, कॉन्फ़िगर की गई VPN प्रविष्टियाँ सूचीबद्ध करें और नोट करें कि प्रत्येक किसकी है। सैमसंग बिल्ड में रिलीज़ के बीच मेनू लेबल बदल जाते हैं, इसलिए प्रविष्टि का वर्णन करें, उस तक के पथ का नहीं। धूसर या प्रबंधित प्रविष्टि उसकी है जो डिवाइस का प्रशासन करता है; उसे प्रयोग के तौर पर बंद करना उस चीज़ को बदल देता है जिसे आप मापना चाहते हैं और नीति के विरुद्ध हो सकता है।

प्लेटफ़ॉर्म जो स्थिति बताता है उसे पढ़ें

अपने सपोर्ट टूलिंग में किसी मौजूदा गतिविधि के भीतर, API 23 या बाद में, नेटवर्क स्थिति एक भी बाइट भेजे बिना पढ़ी जा सकती है। इस कॉल को क्षमताएँ पढ़ने के लिए सामान्य ACCESS_NETWORK_STATE मैनिफ़ेस्ट अनुमति चाहिए।

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

हर मान एक संकीर्ण प्रश्न का उत्तर देता है। सक्रिय नेटवर्क उस क्षण कॉल करने वाली प्रक्रिया का डिफ़ॉल्ट नेटवर्क है। क्षमता जाँच बताती है कि वह डिफ़ॉल्ट नेटवर्क VPN-समर्थित है या नहीं। प्रॉक्सी कॉल प्रभावी डिफ़ॉल्ट HTTP प्रॉक्सी की सूचना देती है, और लौटाई गई वस्तु स्थिर प्रॉक्सी या PAC स्क्रिप्ट का वर्णन कर सकती है।

अगर आपको डिफ़ॉल्ट के बजाय प्रति-नेटवर्क दृश्य चाहिए, तो उसी नेटवर्क के लिंक गुण पढ़ें और cm.getLinkProperties(network)?.httpProxy से तुलना करें। डिवाइस प्रबंधन द्वारा स्थापित प्रॉक्सी डिफ़ॉल्ट-प्रॉक्सी कॉल में दिखता है और लिंक गुणों में नहीं दिखता, जो नीति-प्रदत्त प्रॉक्सी को नेटवर्क-प्रदत्त प्रॉक्सी से अलग पहचानने का तेज़ तरीका है।

आउटपुट को सार्वजनिक रिपोर्ट के बजाय अपने सपोर्ट चैनल में रखें। प्रॉक्सी होस्टनाम, PAC URL और आंतरिक प्रत्यय बताते हैं कि आपका संगठन ट्रैफ़िक कैसे रूट करता है, और विफलता का वर्णन करने के लिए इनमें से कोई आवश्यक नहीं है।

हर फ़ील्ड को संकीर्ण रूप से व्याख्यायित करें

शून्य नेटवर्क या शून्य क्षमता वस्तु का अर्थ है कि कॉल करने वाले की नेटवर्क स्थिति उपलब्ध नहीं थी या पढ़ने के दौरान बदल गई। इसका अर्थ यह नहीं कि VPN नहीं है। इसे अज्ञात मानें और ऐप के फ़ोरग्राउंड में आने के बाद फिर पढ़ें, नकारात्मक परिणाम के रूप में नहीं।

VPN ट्रांसपोर्ट सकारात्मक संकेतों में सबसे कमज़ोर है। VpnService रखने वाला कोई भी ऐप एक उत्पन्न करता है, जिसमें वह स्थानीय फ़िल्टरिंग ऐप भी शामिल है जो आपका ट्रैफ़िक कभी कहीं नहीं भेजता। इसलिए सही मान कहता है कि VPN-समर्थित डिफ़ॉल्ट नेटवर्क मौजूद है, यह नहीं कि आपके संगठन का एग्ज़िट उपयोग हुआ और निश्चित रूप से यह नहीं कि निरीक्षण हुआ।

शून्य डिफ़ॉल्ट प्रॉक्सी का अर्थ है कि यह API प्रभावी कॉन्फ़िगरेशन के लिए कोई डिफ़ॉल्ट HTTP प्रॉक्सी नहीं बताता। यह बहुत कम बाहर करता है: ऐप अपनी SOCKS सेटिंग ले जा सकता है, अपना HTTP क्लाइंट बना सकता है, या गेटवे पर ऐसे प्रॉक्सी से चलाया जा सकता है जिसके बारे में डिवाइस कभी नहीं जानता।

PAC वह स्थिति है जो एक-मान वाले उत्तर को हरा देती है। स्क्रिप्ट एक गंतव्य को प्रॉक्सी से भेज सकती है और दूसरे को सीधे, इसलिए एक ही ऐप के एक सेकंड भीतर के दो अनुरोध अलग रास्ते ले सकते हैं। और जो ऐप अपने सॉकेट चुने हुए नेटवर्क से बाँधता है, या bindProcessToNetwork कॉल करता है, वह डिफ़ॉल्ट का पालन करने के लिए बाध्य नहीं है।

यह स्नैपशॉट आपको क्या नहीं बता सकता

यह इतिहास नहीं है। यहाँ कुछ भी दर्ज नहीं करता कि विफल अनुरोध ने कौन-सा रास्ता लिया, और विफलता के बाद सफल पठन विफलता के बारे में प्रमाण नहीं है। यह सूची भी नहीं है: आपको कॉल करने वाली प्रक्रिया का डिफ़ॉल्ट नेटवर्क मिलता है, हर ऐप के निजी कनेक्शन की सूची नहीं।

यह सॉकेट के ऊपर क्या होता है, इस बारे में भी कुछ नहीं कहता। प्रबंधित डिवाइस पर विफल होने वाला TLS हैंडशेक ट्रस्ट-स्टोर की समस्या, पिनिंग बेमेल या ऐसा नाम हो सकता है जिसे प्रॉक्सी अस्वीकार करता है, और इनमें से कोई कनेक्टिविटी-पठन में नहीं दिखता।

इसीलिए दोनों आधे एक साथ मायने रखते हैं: स्नैपशॉट यह सीमित करता है कि कहाँ देखें, और ऐप का अपना निदान बताता है कि वास्तव में क्या विफल हुआ।

इसे उस रूप में रिपोर्ट करें जिसका व्यवस्थापक उपयोग कर सके

प्रभावित ऐप, प्रोफ़ाइल, टाइमस्टैम्प और विफल हुआ ठीक वह चरण दें: नाम समाधान, TCP कनेक्शन, TLS हैंडशेक या HTTP स्थिति। स्नैपशॉट के मान वैसे ही जोड़ें जैसे वे पढ़े गए, शून्यों को शून्य ही लिखें, कुछ नहीं जैसे शब्द के रूप में नहीं। नोट करें कि क्या उसी प्रोफ़ाइल के दूसरे ऐप भी उसी तरह विफल होते हैं, जो ऐप की समस्या को पूरी प्रोफ़ाइल के पथ की समस्या से अलग करता है।

फिर रुकें और पथ के स्वामी को उत्तर देने दें। कॉर्पोरेट प्रमाणपत्र, प्रॉक्सी पता या VPN प्रविष्टि को प्रबंधन हटाने या स्वीकृत मार्ग को दरकिनार करने की अनुमति न मानें; इससे सपोर्ट केस नीति की घटना बन जाता है।

डिफ़ॉल्ट-प्रॉक्सी अनुबंध छोटा है और एक बार पढ़ने योग्य है, क्योंकि यह ठीक-ठीक तय करता है कि कॉल किस प्रॉक्सी की सूचना देती है, और इस स्नैपशॉट की हर अति-पठन इस मान्यता से शुरू होती है कि यह और अधिक बताता है।