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), याचा अर्थ उर्वरित डिव्हाइस सतत कमी होतील आणि अपवाद त्यांच्यासोबतच संपावे.