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

फ़ाइल आसान हिस्सा है। बाकी दो तय करते हैं कि माइग्रेशन काम करेगा या नहीं।

एक्सपोर्ट की गई प्रोफ़ाइल में असल में क्या होता है

विश्वास करने से पहले फ़ाइल को टेक्स्ट एडिटर में खोलें। OpenVPN प्रोफ़ाइल एक छोटी कॉन्फ़िगरेशन भाषा है: remote, proto, data-ciphers, और अक्सर इनलाइन <ca>, <cert>, <key> या <tls-crypt> ब्लॉक जो क्लाइंट अपने TLS स्टैक को देता है। WireGuard कॉन्फ़िग ज़्यादा सपाट है: [Interface] में PrivateKey और Address होते हैं, फिर हर एंडपॉइंट के लिए एक [Peer] जो PublicKey, AllowedIPs और Endpoint ले जाता है। IKEv2 .mobileconfig के रूप में आता है, जिसमें कुंजी ब्लॉक के बजाय पेलोड डिक्शनरी होती हैं।

उस पाठ में से कोई भी अकेला क्रेडेंशियल नहीं है। क्रेडेंशियल निजी कुंजी है, और हर फ़ॉर्मैट उसे इनलाइन चिपकाता है या ऐसे उपनाम की ओर इशारा करता है जो केवल उसे बनाने वाले क्लाइंट के भीतर ही हल होता है।

Android पर कुंजी असल में कहाँ रहती है

Android ऐप डेटा को /data/data/<package> के अंतर्गत रखता है, जिसे केवल उसी ऐप का UID पढ़ सकता है। बिना root वाले फ़ोन से दूसरे ऐप की निजी डायरेक्टरी कॉपी करने का कोई समर्थित तरीका नहीं है, और Android 12 के इसे बंद करने तथा क्लाइंट्स द्वारा allowBackup="false" घोषित करना शुरू करने के बाद adb backup सामान्य उत्तर नहीं रहा। इसलिए Android क्लाइंट से एक्सपोर्ट का अर्थ है जो वह क्लाइंट लागू करता है, फ़ाइल सिस्टम की कॉपी नहीं।

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

यह टूटा हुआ एक्सपोर्ट नहीं है। यह वह गुण है जो प्लेटफ़ॉर्म से माँगा गया था।

प्रोफ़ाइल क्या पार नहीं ले जा सकती

वस्तुओं को उसके सामने रखें जो कोई गंतव्य स्वीकार करेगा:

वस्तुजाती है?क्यों
प्रोटोकॉल और एंडपॉइंटहाँ, अगर गंतव्य क्लाइंट इसे समझता हैप्रोफ़ाइल में सादा पाठ
CA प्रमाणपत्र और होस्टनाम जाँचआमतौर परसार्वजनिक सामग्री, लेकिन होस्टनाम को अब भी प्रमाणपत्र से मेल खाना चाहिए
क्लाइंट प्रमाणपत्रहाँ, जब तक यह प्रति डिवाइस बँधा न होप्रमाणपत्र पोर्टेबल हैं; जारीकर्ता तय करता है कि एक को कितने डिवाइस इस्तेमाल कर सकते हैं
निजी कुंजीकेवल अगर Keystore के बाहर बनी होहार्डवेयर-समर्थित कुंजियाँ एक्सपोर्ट नहीं हो सकतीं, केवल बदली जा सकती हैं
खाता, MFA, SSO सत्रनहींटोकन समाप्त हो जाते हैं और उसी डिवाइस से बँधे रहते हैं जिसने उन्हें पाया
रूट, DNS और ऐप स्कोपकेवल कॉन्फ़िगरेशन टेक्स्ट के रूप मेंAndroid कनेक्ट करते समय VpnService.Builder के ज़रिए इन्हें लागू करता है
स्प्लिट-टनल ऐप सूचीशायद ही कभीपैकेज नाम डिवाइसों में अलग होते हैं, और सूची क्लाइंट की स्थिति है

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

आयात एक पार्स है, फिर सहमति का अनुरोध

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

फिर एक प्राधिकरण कदम आता है जिसे कोई फ़ाइल नहीं छोड़ सकती। टनल स्थापित करने से पहले Android चाहता है कि ऐप VpnService.prepare() को कॉल करे और आपकी सहमति ले, इसलिए अभी-अभी आयातित प्रोफ़ाइल एक बार सिस्टम डायलॉग दिखाती है। फिर टनल स्पष्ट रूप से addAddress, addRoute, addDnsServer, और प्रति-ऐप रूटिंग के लिए addAllowedApplication या addDisallowedApplication के ज़रिए बनाई जाती है। इनमें से कोई भी एंडपॉइंट से निहित नहीं है, इसलिए वही प्रोफ़ाइल दो क्लाइंट्स में अलग प्रभावी रूट सेट बना सकती है।

प्रमाणपत्र-आधारित सेटअप एक और शाखा जोड़ते हैं। जब सर्वर किसी विशिष्ट डिवाइस को प्रमाणपत्र जारी करता है, जैसे MDM और SCEP नामांकन करते हैं, तो दूसरे फ़ोन पर उसका पुनः उपयोग या तो तब तक काम करता है जब तक सर्वर प्रति पहचान एक सत्र लागू न करे, या TLS हैंडशेक पर विफल हो जाता है। पुनः उपयोग की योजना बनाने से पहले जारीकर्ता की नीति जाँचें।

पुराने को हटाने से पहले नए डिवाइस को सत्यापित करें

पुराने फ़ोन को तब तक जुड़ा रखें जब तक नया हरे आइकन से बेहतर कुछ पास न कर ले। नए डिवाइस से एग्रेस पता और उसने असल में जो DNS रिज़ॉल्वर इस्तेमाल किया, उसकी पुष्टि करें। अगर split tunneling मायने रखता है, तो एक ऐप चलाएँ जिसे टनल से बचना चाहिए और एक जिसे नहीं, फिर देखें कौन-सा आपके ISP तक पहुँचता है।

एक जाँच एग्रेस पता तय कर देती है। फ़ोन ब्राउज़र में https://ifconfig.me खोलें, फिर उसी Wi-Fi पर लैपटॉप से curl -s https://ifconfig.me चलाएँ और दोनों उत्तरों की तुलना उस पते से करें जो आपके प्रदाता ने दिया था।

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

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

कुछ भी मिटाने से पहले चेकलिस्ट चलाएँ: नया डिवाइस कनेक्ट होता है, एग्रेस पता और DNS मेल खाते हैं, प्रति-ऐप स्कोप वही है जो आप चाहते थे, पुरानी पहचान रद्द है, और रखी कोई भी कॉन्फ़िग फ़ाइल एन्क्रिप्टेड स्टोरेज में है।

संबंधित लेख