एकभन्दा बढी क्लाइन्टका लागि उपयुक्त IKEv2 सेटिङको योजना बनाउनुहोस्
काम गर्ने डेस्कटप प्रोफाइलले एउटै क्लाइन्ट परीक्षण गरेको छ। पहिचान सम्झौतामा सहमत हुनुहोस्, समर्थित प्रतिच्छेदन छान्नुहोस्, त्यसपछि प्रत्येक प्लेटफर्मका लागि नवीकरण र स्लिप परीक्षण गर्नुहोस्।
एउटा डेस्कटपमा काम गर्ने प्रोफाइल एउटा क्लाइन्टको सफल परीक्षण हो। यो क्रस-प्लेटफर्म परिनियोजन होइन, र यसलाई त्यसरी मान्दा परिचित सहायता ढाँचा बन्छ: Windows जोडिन्छ, फोन पहिचान जाँचमा असफल हुन्छ, र व्यवस्थापित ल्यापटप हरेक पटक ब्युँझँदा फेरि जोडिन्छ। भिन्नताहरू वास्तविक छन् र अधिकांश अनुमान गर्न सकिने छन्, त्यसैले योजना स्क्रिनसट होइन, म्याट्रिक्स हुनुपर्छ।
पहिले पहिचान सम्झौता निर्धारण गर्नुहोस्
एल्गोरिदमबारे छलफल गर्नुअघि सर्भर पहिचान, प्रमाणपत्रमा विश्वास र क्लाइन्ट प्रमाणीकरण विधि को दस्तावेजीकरण गर्नुहोस्। यी तीनले क्लाइन्ट प्रमाणीकरण गर्न सक्छ कि सक्दैन भन्ने निर्धारण गर्छन्, र प्लेटफर्महरूले यिनै भागहरूलाई फरक तरिकाले व्यक्त गर्छन्।
प्रत्येक प्लेटफर्मले अपेक्षित पहिचानकर्तालाई कसरी नाम दिन्छ र विषयका वैकल्पिक नामहरूलाई कसरी व्यवस्थापन गर्छ भनी जाँच्नुहोस्। एउटा क्लाइन्टमा सर्भर नाम स्वीकार्ने प्रोफाइलले अर्कोमा त्यही प्रमाणपत्र अस्वीकार गर्न सक्छ, किनकि पहिचानकर्ता फिल्ड फरक मानबाट भरिन्छ।
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
त्यसपछि क्रिप्टोग्राफिक प्रतिच्छेदन छान्नुहोस्
प्रत्येक समर्थित क्लाइन्टले प्रस्ताव गर्न सक्ने प्रस्तावहरू तुलना गर्नुहोस् र गेटवेले पनि अनुमति दिने आधुनिक प्रतिच्छेदन छान्नुहोस्। एउटा पुरानो उपकरण जोडिनका लागि अत्यधिक ठूलो पुरानो सूची सक्षम नगर्नुहोस्, किनकि त्यो सूची पछि आउने सबैका लागि गेटवेको पूर्वनिर्धारित बन्छ। प्रत्येक पुरानो विकल्प अझै किन छ त्यो लेख्नुहोस्। त्यसलाई आवश्यक पर्ने उपकरण कसैले नाम दिन सक्दैन भने, त्यो आवश्यकता होइन।
योजनामा IKE र CHILD सेटिङहरू अलग राख्नुहोस्। IKE आदानप्रदानका लागि स्वीकार्य प्रस्ताव संरक्षित ट्राफिकका लागि स्वतः स्वीकार्य हुँदैन, र दुवैको वार्ता अलग हुन्छ। एउटा तहमा प्रस्ताव स्वीकार्ने गेटवेले अर्को तहमा त्यसलाई अस्वीकार गर्न सक्छ, र लगले पहिलो तह सफल भएजस्तो देखिने असफलता देखाउनेछ।
प्रमाणित प्रक्रियाबाट प्रमाणहरू उपलब्ध गराउनुहोस्, र प्रयोगकर्ता पासवर्ड, साझा गोप्य र क्लाइन्टको निजी कुञ्जी तिनका आफ्नै फिल्डमा राख्नुहोस्। एउटै नामका बाकसमा प्रयास र त्रुटि नै काम गर्ने परीक्षणलाई पुनरुत्पादन गर्न नसकिने परीक्षण बनाउने बाटो हो।
स्थिर अवस्था होइन, जीवनचक्र परीक्षण गर्नुहोस्
प्रत्येक क्लाइन्टका लागि प्रारम्भिक प्रमाणीकरण, इच्छित अनुप्रयोग, DNS समाधान र ठेगाना-परिवार कभरेज परीक्षण गर्नुहोस्। त्यसपछि मात्र पछि देखिने भागहरू अभ्यास गर्नुहोस्: नवीकरण, स्लिप र सामान्य नेटवर्क परिवर्तन।
MOBIKE समर्थन र पुनःप्रमाणीकरण व्यवहार भर्खरै नापिएको स्थिर नतिजाभन्दा फरक हुन सक्छ। त्यो समयको घटना र संबद्धताको स्थिति अभिलेख गर्नुहोस्, इन्टरफेस अन्तमा जोडिएको देखिन्छ कि भन्ने मात्र होइन।
VPN उपलब्ध नहुँदा सिधा ट्राफिकले के गर्न सक्छ त्यो परिभाषित गर्नुहोस्। यो क्लाइन्ट फेरि जोडिन्छ कि भन्नेबाट अलग नीति निर्णय हो, र अधिकांश परिनियोजनहरू पहिलोलाई बेवास्ता गर्दै दोस्रो प्रश्नको उत्तर दिन्छन्। उत्तर प्रोफाइल नामहरूको छेउमा परिनियोजन टिप्पणीमा लेख्नुहोस्। कसैलाई अवरोधको समयमा त्यो चाहिनेछ, र पुनः निर्माण गर्न समय हुनेछैन।
एउटा प्लेटफर्म सहमत नहुँदा सर्भर पहिचान जाँच प्रयोग गर्नुहोस्
जब प्रोफाइल एउटा प्लेटफर्ममा काम गर्छ र अर्कोले त्यसको नाम अस्वीकार गर्छ, क्लाइन्टले वास्तवमा पठाएको पहिचानकर्तालाई प्रमाणपत्रले बोकेका पहिचानकर्ताहरूसँग तुलना गर्नुहोस्। यो तुलनाले यीमध्ये अधिकांश केसहरू सिफर सूची बदल्नुभन्दा छिटो समाधान गर्छ।
परीक्षण गरिएको म्याट्रिक्सलाई कन्फिगरेसन स्रोत र अद्यावधिक प्रक्रियासँगै राख्नुहोस्। पुरानो क्लाइन्टको समर्थन सकिएपछि, अर्को अडिटले भेट्न गेटवेमा कमजोर उपयुक्तता सेटिङ लुकाएर राख्नुको सट्टा त्यसको अपवाद जानाजानी हटाउनुहोस्। strongSwan का IKEv2 कागजात आदानप्रदान कसरी कन्फिगर हुन्छन् भन्ने उपयोगी सन्दर्भ हो।