iPhone पर IKEv2 प्रमाणपत्र सेटअप: मैन्युअल बनाम प्रबंधित नामांकन

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

पहला चरण: नामांकन का रास्ता चुनें

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

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

दूसरा चरण: अपने चुने हुए रास्ते के लिए एल्गोरिदम चुनें

मैन्युअल रूप से कॉन्फ़िगर किए गए iPhone के लिए, strongSwan के iOS अंतर-संचालनीयता नोट्स RSA सर्वर प्रमाणपत्र की सलाह देते हैं, क्योंकि मैन्युअल क्लाइंट ECDSA सर्वर प्रमाणपत्र स्वीकार नहीं कर सकता; वही नोट्स macOS को अलग से देखते हैं। इसे समर्थित क्लाइंट समूह के लिए मार्गदर्शन पढ़ें, Apple उपकरणों के बारे में स्थायी कानून नहीं। प्रबंधित प्रोफ़ाइल के पास अधिक जगह है: यह प्रमाणपत्र प्रकार स्पष्ट रूप से चुन सकती है, जिसमें ECDSA क्लाइंट पहचान भी शामिल है, जब पेलोड और गेटवे दोनों इसका समर्थन करते हैं।

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

तीसरा चरण: प्रोफ़ाइल फ़ील्ड को अलग-अलग चीज़ों के रूप में पढ़ें

समान नाम की कई कुंजियाँ अलग-अलग ऑब्जेक्ट का वर्णन करती हैं। दूरस्थ पता वह होस्ट है जिसे फ़ोन डायल करता है। दूरस्थ पहचानकर्ता वह IKE पहचान है जिसे वह गेटवे से प्रस्तुत करने की अपेक्षा करता है। पेलोड का प्रमाणपत्र संदर्भ क्लाइंट क्रेडेंशियल की ओर इंगित करता है, और प्रमाणपत्र प्रकार फ़ील्ड IKEv2 मशीन प्रमाणीकरण के लिए उपयोग किया जाने वाला प्रकार चुनता है। इनमें से कोई भी CA का हस्ताक्षर एल्गोरिदम नहीं है, हालाँकि शब्द एक-दूसरे से मिलते हैं।

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

चौथा चरण: गेटवे की पहचान को उसके प्रमाणपत्र से मिलाएँ

स्पष्ट गेटवे नाम का उपयोग करें, जैसे vpn.example.com और सर्वर प्रमाणपत्र में मेल खाता वैकल्पिक विषय नाम रखें। strongSwan का Apple मार्गदर्शन सर्वर प्रमाणीकरण के लिए विस्तारित कुंजी उपयोग की भी अपेक्षा करता है। RSA या ECDSA चुनने से इसमें कुछ नहीं बदलता: एल्गोरिदम नाम की बेमेल, अनुपस्थित EKU या अधूरी श्रृंखला को ठीक नहीं कर सकता।

विश्वास एंकर का वितरण पहचान का दावा करने से अलग कार्य है। फ़ोन को ऐसी प्रमाणपत्र श्रृंखला चाहिए जिसे वह मान्य कर सके, और उसे उस नाम की अपेक्षा करने के लिए कॉन्फ़िगर करना होगा जो आपने वास्तव में प्रमाणपत्र में रखा है।

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

पाँचवाँ चरण: क्लाइंट पहचान को CA विश्वास से अलग करें

क्लाइंट प्रमाणपत्र और उसकी निजी कुंजी वही ऑब्जेक्ट नहीं हैं जो CA प्रमाणपत्र है जिस पर फ़ोन भरोसा करता है। CA प्रमाणपत्र को PKCS#12 पहचान के अंदर बंडल करना उसे हर समर्थित उपकरण पर स्वचालित रूप से विश्वास एंकर के रूप में स्थापित नहीं करता, इसलिए विश्वास वितरण को अपने सत्यापन वाला अलग चरण मानें।

यदि डिज़ाइन इसके बजाय पासवर्ड-आधारित EAP का उपयोग करता है, तो फ़ोन को इच्छित खाता प्रमाणीकरण के साथ सर्वर सत्यापन चाहिए। यह रास्ता पूरी फ़्लीट को एक साझा क्लाइंट निजी कुंजी भेजने को उचित नहीं ठहराता, जो अलग डिज़ाइन है और इसका विफलता मोड कहीं अधिक खराब है।

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