एकापेक्षा जास्त क्लायंटसाठी योग्य 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 दस्तऐवजीकरण देवाणघेवाणी कशा कॉन्फिगर होतात यासाठी उपयुक्त संदर्भ आहे।