iOS IKEv2 ते strongSwan: प्रस्ताव निवडला गेला नाही, यादी दुरुस्त करा
«प्रस्ताव निवडला गेला नाही» म्हणजे दोन्ही याद्या कधीच छेदत नाहीत. SHA1 ला SHA-96, modp1024 ला group 2 मध्ये बदला आणि चाइल्ड प्रस्तावही सेट करा.
iPhone टनेल उभारतो, गेटवे काहीच उत्तर देत नाही आणि फोन सामान्य अपयश दाखवतो। strongSwan चा लॉग अधिक नेमका आहे: no proposal chosen। या संदेशाचा अर्थ असा की स्वीकारार्ह सिफर संचांच्या दोन याद्या कधीच एकमेकींना भेटल्या नाहीत, त्यामुळे प्रमाणीकरण सुरू होण्यापूर्वीच देवघेव संपली। ही जुळवणीची समस्या आहे आणि उपाय म्हणजे याद्या एकमेकींना छेदतील असे करणे।
गेटवे आपले धोरण कुठे जाहीर करतो
strongSwan आपले धोरण कॉन्फिगरेशनमध्ये लिहितो आणि शेवटचे उद्गारचिन्ह ते धोरण कसे वाचायचे हे ठरवते। चिन्ह असल्यास यादी पूर्ण आहे: फक्त त्या नोंदी स्वीकारल्या जातील, दुसरे काहीही नाही। चिन्ह नसल्यास तीच ओळ प्राधान्यक्रम बनते आणि डीमन तुम्हाला नको असलेले काहीतरी निवडू शकतो। काहीही भाषांतर करण्यापूर्वी कोणता प्रकार बसवलेला आहे ते विचारा, कारण दोन्ही एकाच क्लायंटशी वेगळे वागतात। चिन्हासह नेमकी ओळ नोंदवा आणि त्याच्याविरुद्ध चाचणी करा।
अधिक रुंद यादी देणारा क्लायंटही पिन केलेल्या गेटवेला जोडू शकतो, जर दोन्ही बाजूंना किमान एक संयोजन असेल। होऊ शकत नाही ते म्हणजे पिन केलेल्या संचाबाहेरची वाटाघाटी।
म्हणूनच दुसऱ्या VPN ॲपमधून कॉपी केलेली प्रोफाइल तुमची चालत नाही तिथे चालू शकते: त्या ॲपने वेगळी यादी पाठवली होती।
नावे जुळली पाहिजेत, सुधारली नाहीत
strongSwan मधून iOS मध्ये मूल्ये हलवताना दोन भाषांतरे लोकांना गुंगवतात। IKE प्रस्तावात SHA1 असे लिहिलेले अखंडता अल्गोरिदम त्याच्या कापलेल्या रूपात प्रवास करते, ज्याला iOS .SHA96 म्हणते। modp1024 असे लिहिलेला Diffie-Hellman गट गट 2 आहे, ज्याला iOS .group2 म्हणते। SHA-256 किंवा गट 14 ने बदलल्यास फक्त जुनी जोडी स्वीकारणाऱ्या गेटवेशी वाटाघाटी होणार नाही। क्लायंटने अधिक मजबूत नाही तर तोच अल्गोरिदम वर्णन करायचा आहे।
ती मूल्ये NEVPNProtocolIKEv2 मध्ये स्पष्टपणे सेट करा। डीफॉल्ट बदलल्या जाणाऱ्या प्रोफाइलपेक्षा रुंद किंवा अरुंद असू शकतात आणि फरक फक्त हँडशेक अयशस्वी झाल्यावर दिसतो।
चाइल्ड प्रस्ताव उशिरा आणि अधिक शांतपणे अयशस्वी होतो
फक्त IKE नाही तर चाइल्ड सुरक्षा संघटनाही कॉन्फिगर करा। फक्त IKE पॅरामीटर जुळल्यास टनेल प्रमाणित होते आणि नंतर वाहतूक वाहत नाही, जे नकारापेक्षा खूपच शांत अपयश आहे। चाइल्डचे कूटबद्धीकरण, अखंडता, गट आणि आयुष्य एकाच टप्प्यात सेट करा। क्लायंटचे आयुष्य गेटवेच्या मूल्याइतके किंवा त्यापेक्षा कमी ठेवा, कारण जास्त लांबीचा आग्रह केल्यास वेगळ्या कारणाने तोच no proposal chosen संदेश मिळतो। तिथली विसंगती लॉगमधील IKE विसंगती सारखीच दिसते।
कॉन्फिगरेशनमध्ये असताना प्रोफाइल प्रमाणपत्रांनी किंवा सामायिक रहस्याने प्रमाणीकरण करते का ते तपासा। प्रस्तावाचा नकार आणि प्रमाणीकरणाचा नकार वेगवेगळ्या ओळींवर दिसतात आणि चुकीचा दुरुस्त करण्यास एक दिवस जातो। प्रत्येक बदलानंतर नवीन कनेक्शनने चाचणी करा, एका वेळी एक चल, कारण कॅशे केलेली स्थिती कोणता पॅरामीटर हलला हे लपवते।
जुना संच फक्त गरज असेपर्यंत ठेवा
SHA-1 ला 1024-बिट गटासह पिन करणे हा पूल आहे, गंतव्य नाही। दोन्ही कालबाह्य आहेत आणि नवीन क्लायंट ते पूर्णपणे नाकारू शकतात, म्हणजे तुमच्या बाजूने कोणताही बदल न करता पुढील उपकरणावर प्रोफाइल अयशस्वी होईल। पिनला तात्पुरता माना आणि नोंदीत तसे लिहा।
strongSwan तुमचे असल्यास आधुनिक प्रस्ताव जोडा आणि जुनी नोंद जुन्या उपकरणांसाठी राहत असताना दोन्ही टोकांना वरच्या दिशेने वाटाघाटी करू द्या। प्रत्येक कनेक्शनने प्रत्यक्षात कोणता संच वापरला हे पाहण्यासाठी डीमनचे स्थिती आउटपुट वाचा। आधुनिक जोडी निश्चित झाल्यावर क्लायंटच्या बाजूचे पिनिंग काढून टाका। टनेल उभे राहणे पुरावा पुरत नाही, कारण तुम्ही निवृत्त करू पाहत असलेल्या संचावरही ते उभे राहू शकते। strongSwan IKEv2 दस्तऐवज प्रस्तावाची वाक्यरचना आणि strict चिन्हाचे वर्णन करतात।