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

हर कॉल पर मैं यह नियम इस्तेमाल करता हूँ: स्थिति का नाम लें, उसके मालिक का नाम लें, फिर सिर्फ़ उसी मालिक की प्रति हटाएँ। इस पेज का बाकी हिस्सा इस बारे में है कि कौन-सा Android घटक कौन-से बाइट रखता है।

Android VPN प्रोफ़ाइल वास्तव में कहाँ रहती है

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

VpnService प्लंबिंग है, स्टोरेज नहीं। क्लाइंट एक बार सहमति माँगता है, tun इंटरफ़ेस बनाता है और खुद पैकेट खिसकाता है, इसलिए प्लेटफ़ॉर्म को कभी प्रोफ़ाइल फ़ॉर्मेट समझने की ज़रूरत नहीं पड़ती। इसीलिए दूसरे फ़ोन से कॉपी की गई कॉन्फ़िगरेशन फ़ाइल अक्सर खाली प्रोफ़ाइल के रूप में आयात होती है या सत्यापन में विफल रहती है।

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

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

कैश, स्टोरेज, नेटवर्क रीसेट, फैक्ट्री रीसेट

चारों क्रियाएँ इन सीमाओं से मेल खाती हैं। कुछ भी टैप करने से पहले उस स्थिति की पंक्ति पढ़ें जिस पर आपको शक है।

OperationWhat it removesWhat survives
Clear cacheTemporary files, including any diagnostic bundle the client wrote thereProfile, credentials, enrollment
Clear storageThe app's preferences, databases and saved profileKeyChain entries, other apps, device policy
Network resetWi-Fi, mobile and Bluetooth registrations, and on most builds the saved VPN entriesApp data, KeyChain, work profile
Factory resetThe user data partition, accounts and device-bound keysNothing on the device

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

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

सेटिंग्स में नेटवर्क रीसेट पूरे डिवाइस के लिए है, और इसका सटीक दायरा निर्माता और Android संस्करण के साथ बदलता है। आपके बिल्ड पर पुष्टि संवाद ही इस बात का एकमात्र विश्वसनीय कथन है कि यह क्या भूल जाएगा।

पहले वापसी का रास्ता लिखें

किसी भी विनाशकारी कदम से पहले पाँच चीजें लिखें: क्लाइंट संस्करण, प्रोफ़ाइल नाम, गेटवे पता, सेवा का मालिक और वह सटीक चरण जहाँ कनेक्शन विफल होता है।

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

फिर पुष्टि करें कि कनेक्शन कैसे फिर बनेगा। प्रदर्शित नाम और होस्टनाम तब पर्याप्त नहीं होते जब प्रोफ़ाइल क्लाइंट प्रमाणपत्र, प्रबंधित कॉन्फ़िगरेशन या इस डिवाइस से बँधे MFA नामांकन पर निर्भर थी।

वह बूटस्ट्रैप लॉकआउट जिसकी कोई योजना नहीं बनाता

एक विफलता मोड अपने अलग अनुभाग का हक़दार है। अगर प्रोफ़ाइल डाउनलोड करने की एकमात्र जगह कोई आंतरिक पोर्टल है जो उसी टनल से पहुँचता है जिसे आप हटाने वाले हैं, तो स्टोरेज साफ़ करना ऐप के भीतर निकलने का कोई रास्ता न छोड़ने वाली बंद गली बना देता है।

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

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

फिर से बनी टनल सत्यापित करें

प्रोफ़ाइल लौटने के बाद क्रम से परखें: नाम विश्लेषण, किसी ज्ञात आंतरिक होस्ट से TCP कनेक्शन, और वह विफलता-अवरोध व्यवहार जिस पर आप वास्तव में निर्भर हैं। क्रम मायने रखता है क्योंकि टनल उठ भी सकती है और फिर भी DNS लीक कर सकती है।

स्टेटस बार में कुंजी आइकन साबित करता है कि इंटरफ़ेस मौजूद है, इससे ज़्यादा नहीं।

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

संबंधित लेख