iOS IKEv2 से strongSwan: कोई प्रस्ताव नहीं चुना गया, सूची ठीक करें

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

गेटवे अपनी नीति कहाँ बताता है

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

चौड़ी सूची देने वाला क्लाइंट भी पिन किए गए गेटवे से जुड़ सकता है, बशर्ते एक संयोजन दोनों ओर दिखे। जो नहीं हो सकता वह है पिन किए गए सेट के बाहर बातचीत।

इसीलिए किसी अन्य VPN ऐप से कॉपी किया गया प्रोफ़ाइल वहाँ काम कर सकता है जहाँ आपका नहीं करता: उस ऐप ने अलग सूची भेजी थी।

नाम मेल खाने चाहिए, बेहतर नहीं होने चाहिए

दो अनुवाद लोगों को strongSwan से iOS में मान ले जाते समय फँसाते हैं। IKE प्रस्ताव में SHA1 लिखा अखंडता एल्गोरिदम अपने कटे हुए रूप में जाता है, जिसे iOS .SHA96 कहता है। modp1024 लिखा Diffie-Hellman समूह group 2 है, जिसे iOS .group2 कहता है। SHA-256 या group 14 रखने से उस गेटवे से बातचीत नहीं होगी जो केवल पुरानी जोड़ी स्वीकार करता है। क्लाइंट को वही एल्गोरिदम बताना है, उससे मज़बूत नहीं।

उन मानों को NEVPNProtocolIKEv2 में स्पष्ट रूप से सेट करें। डिफ़ॉल्ट उस प्रोफ़ाइल से चौड़े या संकरे हो सकते हैं जिसे आप बदल रहे हैं, और अंतर केवल तब दिखता है जब हैंडशेक विफल होता है।

child प्रस्ताव बाद में और अधिक चुपचाप विफल होता है

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

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

पुराना सूट केवल तभी तक रखें जब तक ज़रूरत हो

1024-bit समूह के साथ SHA-1 को पिन करना एक पुल है, मंज़िल नहीं। दोनों अप्रचलित हैं, और नए क्लाइंट उन्हें सीधे मना कर सकते हैं, यानी प्रोफ़ाइल अगले डिवाइस पर आपकी ओर किसी बदलाव के बिना विफल होगा। पिन को अस्थायी मानें और रिकॉर्ड में ऐसा लिखें।

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