VPN ऐप संपर्क और सुगम्यता मांग रहा है: क्या अनुमति दें

इंस्टॉलर पहले नेटवर्क पहुँच मांगता है, फिर संपर्क, सुगम्यता और प्रमाणपत्र इंस्टॉल। इस काम से केवल पहला अनुरोध जुड़ा है। असली निर्णय दूसरी स्क्रीन पर होता है।

हर अनुरोध को उस सुविधा के सामने परखें जो आपने चुनी है, उस प्लेटफ़ॉर्म पर जिसे आप चलाते हैं। कोई सार्वभौमिक अनुमति सूची हर VPN उत्पाद को नहीं ढकती, और लंबी सूची अपने आप कुछ सिद्ध नहीं करती।

वह एकमात्र अनुमति जो इस काम को सचमुच चाहिए

कोई भी टनल शुरू होने से पहले Android उपयोगकर्ता से सिस्टम संवाद के ज़रिए VPN सेवा को मंज़ूरी मांगता है, और ऐप की सेवा BIND_VPN_SERVICE घोषित करती है ताकि सिस्टम उससे बंध सके। परिचालन रूप से ऐप रूटिंग का काम करता है। सहमति उस व्यक्ति से आती है जिसके हाथ में डिवाइस है, ऐप का नाम बताने वाले संवाद में, और बाद में उसे वापस लेना एक समर्थित कार्रवाई है।

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

अतिरिक्त पहुँच अलग प्रभावों वाली अलग अनुमति है। जो रूटिंग क्लाइंट इसे चाहता है, उसे अपना कारण चाहिए।

जहाँ अतिरिक्त अनुरोधों को अपनी व्याख्या चाहिए

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

इनमें से कोई भी वैध हो सकता है। प्रबंधित डिवाइस और अभिभावकीय नियंत्रण उत्पादों को नीति शक्तियाँ चाहिए हो सकती हैं, और सहायता उपकरण को सेटिंग्स में आपका मार्गदर्शन करने के लिए सुगम्यता चाहिए हो सकती है।

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

अनुरोध और उससे जुड़ी सुविधा लिख लें, फिर निर्णय लें। वही नोट आप इनकार के बाद सुविधा टूटने पर सहायता को दिखाते हैं।

डिवाइस पर अनुरोध पढ़ना

स्टोर सूची इरादा बताती है, जबकि इंस्टॉल किया गया पैकेज वास्तविकता बताता है। कुछ और मंज़ूर करने से पहले पैकेज मैनेजर से पूछें कि क्या घोषित हुआ और क्या दिया गया। यह जोड़ी तब सबसे ज़्यादा मायने रखती है जब सूची और मैनिफ़ेस्ट असहमत हों।

दो क्वेरी इसका अधिकतर हिस्सा ढक लेती हैं:

adb shell dumpsys package com.example.vpn | grep -E "requested permissions|install permissions" -A 30
adb shell cmd appops get com.example.vpn

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

वे स्क्रीन एक मिनट लेती हैं और किसी सॉफ़्टवेयर की ज़रूरत नहीं होती। सुगम्यता, डिवाइस प्रशासन और प्रमाणपत्र भंडार में से हर एक अनुमति रखने वाले ऐप की सूची दिखाता है।

निर्णय लेना, फिर नुकसान सीमित करना

नेटवर्क अनुमति उस क्लाइंट को दें जिसे आपने चुना है, और हर अतिरिक्त अनुरोध को अपना अलग निर्णय मानें। जिनके साथ मिलती सुविधा नहीं है उन्हें अस्वीकार करें, फिर देखें क्या टूटता है। संपर्क पहुँच अस्वीकार होने पर जो रूटिंग क्लाइंट विफल होता है, उसने कभी आपकी ओर से संपर्क नहीं मांगे थे।

एक अनुमति वापस लेने से आम तौर पर ऐप अनइंस्टॉल किए बिना या हर प्रोफ़ाइल तोड़े बिना केवल एक सुविधा बंद होती है। बाद में फिर से कनेक्ट करें और पुष्टि करें कि टनल अब भी बनता है।

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