Android 12 और IKEv1 VPN: लॉन्च संस्करण, IKEv2 और तृतीय-पक्ष ऐप्स

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

दो Android 12 फ़ोन एक ही परीक्षण केस नहीं हैं

नए डिवाइसों को पुरानी IKEv1 प्रोफ़ाइल शुरू करने से रोकने वाला AOSP परिवर्तन DEVICE_INITIAL_SDK_INT की तुलना Android S से करता है, यानी API 31। नेटिव स्टार्टअप पथ में योग्य प्रोफ़ाइल किसी भी उपयोगी कनेक्शन से पहले असमर्थित-ऑपरेशन विफलता उठाती है। Android 11 के साथ भेजा गया और बाद में अपडेट हुआ फ़ोन अब भी उस गार्ड को पार करता है; Android 12 के साथ शुरू हुआ मॉडल नहीं।

आप डिबगिंग चालू किए गए डिवाइस पर दोनों संख्याएँ पढ़ सकते हैं:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

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

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

पथ एक: नेटिव स्टैक को वहीं रखें जहाँ वह अब भी चलता है

पुराना स्टैक वही है जो सिस्टम VPN स्क्रीन से IPsec XAuth PSK, IPsec Hybrid RSA और L2TP/IPsec PSK प्रोफ़ाइल पढ़ता है। API 31 से नीचे भेजे गए डिवाइस पर अपग्रेड के बाद भी यह व्यवहार्य पथ रहता है, इसलिए पुराने हैंडसेट पर पायलट सफल हो सकता है जबकि नया हैंडसेट वही प्रोफ़ाइल शुरू नहीं कर पाता।

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

पथ दो: प्लेटफ़ॉर्म IKEv2 प्रोफ़ाइल

IKEv2 के लिए Android का सार्वजनिक प्रोविज़निंग मॉडल एक अलग वस्तु है, नाम बदली हुई IKEv1 प्रोफ़ाइल नहीं। IKEv2 प्रोफ़ाइल के लिए प्लेटफ़ॉर्म API API 30 के साथ आया और गेटवे द्वारा दी जाने वाली प्रमाणीकरण विधि के साथ IKEv2 की अपेक्षा करता है, आमतौर पर प्रमाणपत्र-आधारित या EAP। IKEv1 XAuth या Hybrid से IKEv2 तक कोई तार-संगत अपग्रेड नहीं है: गेटवे को नए प्रोटोकॉल के लिए कॉन्फ़िगर करना होगा और प्रोफ़ाइल को मेल खाती पहचान ले जानी होगी।

यह सबसे लंबे जीवन का पथ है, और यही वास्तविक काम को उजागर करता है। पहचान सत्यापन, उपयोगकर्ता प्रमाणीकरण, DNS, स्प्लिट-टनल रूट और संसाधन प्राधिकरण सभी को माइग्रेशन पार करना होगा; केवल हैंडशेक सफल करना उपयोगकर्ताओं को ऐसी टनल से जोड़े रखता है जो कहीं नहीं पहुँचती।

परिनियोजन आमतौर पर MDM या प्रबंधित कॉन्फ़िगरेशन से होता है, न कि उपयोगकर्ता द्वारा फ़ील्ड लिखने से। अगर वह अधोसंरचना अभी नहीं है, तो माइग्रेशन योजना में उसे शामिल करना होगा, क्योंकि हर डिवाइस पर IKEv2 प्रोफ़ाइल हाथ से फिर से दर्ज करना ऐसा संचालन नहीं है जिसे हेल्प डेस्क निगल सके।

पथ तीन: तृतीय-पक्ष क्लाइंट ऐप

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

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

गेटवे क्या दे सकता है उसके आधार पर चुनें

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

दो बातें योजना को बचाव योग्य बनाती हैं। पहला, हर अपवाद का कारण मॉडल और लॉन्च स्तर के साथ दर्ज करें, ताकि ऑडिटर देख सके कि सीमा प्लेटफ़ॉर्म गार्ड है, न कि बिना व्याख्या की प्राथमिकता। दूसरा, माइग्रेशन को नियोजित कार्य मानें: IKEv1 मानक पथ में अप्रचलित है (RFC 9395), जिसका अर्थ है कि शेष डिवाइस घटते रहेंगे और अपवाद उनके साथ समाप्त होने चाहिए।