iOS IKEv2 बाट strongSwan: कुनै प्रस्ताव छानिएको छैन, सूची सुधार्नुहोस्

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 चिन्हको वर्णन गर्छ।