व्यवस्थापित कार्य ॲपसाठी 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 धारण करणारे कोणतेही ॲप एक तयार करते, तुमची रहदारी कुठेही न पाठवणारे स्थानिक फिल्टरिंग ॲपही। त्यामुळे true मूल्य सांगते की VPN-आधारित डीफॉल्ट नेटवर्क अस्तित्वात आहे, तुमच्या संस्थेचे एक्झिट वापरले गेले असे नाही आणि तपासणी झाली असे मुळीच नाही।

शून्य डीफॉल्ट प्रॉक्सी म्हणजे हे API प्रभावी कॉन्फिगरेशनसाठी कोणताही डीफॉल्ट HTTP प्रॉक्सी नोंदवत नाही। ते फार कमी वगळते: ॲप स्वतःचे SOCKS सेटिंग घेऊन जाऊ शकते, स्वतःचा HTTP क्लायंट अंमलात आणू शकते, किंवा गेटवेवरील अशा प्रॉक्सीने चालवले जाऊ शकते ज्याची उपकरणाला कधीही माहिती नसते।

PAC ही अशी परिस्थिती आहे जी एक-मूल्य उत्तराला हरवते। स्क्रिप्ट एक गंतव्य प्रॉक्सीमधून पाठवू शकते आणि दुसरे थेट, त्यामुळे एकाच ॲपच्या एका सेकंदातील दोन विनंत्या वेगळ्या मार्गांनी जाऊ शकतात। आणि जे ॲप आपले सॉकेट निवडलेल्या नेटवर्कला बांधते, किंवा bindProcessToNetwork कॉल करते, ते डीफॉल्टचे पालन करण्यास बांधील नाही।

हे स्नॅपशॉट तुम्हाला काय सांगू शकत नाही

हे इतिहास नाही। अयशस्वी विनंतीने कोणता मार्ग घेतला हे इथे काहीही नोंदवत नाही, आणि अयशस्वी नंतरचे यशस्वी वाचन अयशस्वीबद्दल पुरावा नाही। ही यादीही नाही: तुम्हाला कॉल करणाऱ्या प्रक्रियेचे डीफॉल्ट नेटवर्क मिळते, प्रत्येक ॲपच्या खाजगी जोडण्यांची यादी नाही।

सॉकेटच्या वर काय होते याबद्दलही ते काहीही सांगत नाही। व्यवस्थापित उपकरणावर अयशस्वी होणारी TLS हातमिळवणी ट्रस्ट-स्टोअर समस्या, पिनिंग विसंगती किंवा प्रॉक्सी नाकारणारे नाव असू शकते, आणि त्यापैकी काहीही कनेक्टिव्हिटी-वाचनात दिसत नाही।

म्हणूनच दोन्ही अर्धे एकत्र महत्त्वाचे आहेत: स्नॅपशॉट कुठे पाहावे हे अरुंद करतो, आणि ॲपचे स्वतःचे निदान प्रत्यक्षात काय अयशस्वी झाले ते सांगते।

प्रशासक वापरू शकेल अशा स्वरूपात त्याची नोंद करा

प्रभावित ॲप, प्रोफाइल, टाइमस्टॅम्प आणि अयशस्वी झालेला नेमका टप्पा द्या: नाव निराकरण, TCP जोडणी, TLS हातमिळवणी किंवा HTTP स्थिती। स्नॅपशॉटची मूल्ये वाचली तशीच जोडा, शून्य शून्य म्हणूनच लिहा, काहीही नाही अशा शब्दाप्रमाणे नाही। त्याच प्रोफाइलमधील इतर ॲपही त्याच पद्धतीने अयशस्वी होतात का ते नोंदवा, जे ॲपची समस्या संपूर्ण प्रोफाइलच्या मार्गाच्या समस्येपासून वेगळी करते।

मग थांबा आणि मार्गाच्या मालकाला उत्तर देऊ द्या। कॉर्पोरेट प्रमाणपत्र, प्रॉक्सी पत्ता किंवा VPN नोंद व्यवस्थापन काढण्याची किंवा मंजूर मार्ग टाळण्याची परवानगी मानू नका; त्यामुळे सपोर्ट केस धोरण घटनेत बदलते।

डीफॉल्ट-प्रॉक्सी करार छोटा आहे आणि एकदा वाचण्यासारखा आहे, कारण तो नेमके ठरवतो की कॉल कोणत्या प्रॉक्सीची नोंदवतो, आणि या स्नॅपशॉटचे प्रत्येक अतिवाचन तो अधिक नोंदवतो अशा गृहीतकाने सुरू होते।