एक से अधिक क्लाइंट के अनुकूल 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 दस्तावेज़ीकरण इस बात के लिए उपयोगी संदर्भ है कि आदान-प्रदान कैसे कॉन्फ़िगर होते हैं।