Mac IKEv2 प्रोफ़ाइल: दोनों SA शब्दकोश सेट करें, फिर परीक्षण करें
जब वह शब्दकोश अनुपस्थित होता है तो IKE पैरामीटर Child SA द्वारा विरासत में मिलते हैं। दोनों भरें, नामों का अनुवाद करें और जाँचें कि सहकर्मियों ने वास्तव में क्या बातचीत की।
सफल कनेक्शन केवल यह सिद्ध करता है कि दोनों सिरों ने मानों का ऐसा समूह पाया है जिसे वे स्वीकार करते हैं। एक प्रबंधित Mac IKEv2 प्रोफ़ाइल में सुरक्षा-संबद्धता के दो शब्दकोश होते हैं, गेटवे की अपनी प्रस्ताव-सूची होती है, और कनेक्शन उसी प्रतिच्छेद पर सफल होता है जिसे दोनों पक्ष अनुमति देते हैं। नीचे दिए गए जाँच क्रम से करें, और दूसरा सिफ़र जोड़कर यह देखने के बजाय कि वह मदद करता है या नहीं, वहीं रुकें जहाँ दोनों सिरे असहमत हों। हर चरण प्रोफ़ाइल की अलग परत को बाहर करता है।
कोई मान संपादित करने से पहले दोनों शब्दकोश जाँचें
VPN पेलोड की IKEv2 सेटिंग्स में, IKESecurityAssociationParameters IKE संबंध का वर्णन करता है और ChildSecurityAssociationParameters Child SA का वर्णन करता है। Apple की स्कीमा कहती है कि दूसरा शब्दकोश न होने पर IKE पैरामीटर Child SA पर भी लागू होते हैं। वह विरासत सुविधाजनक है, और ठीक इसी तरह प्रोफ़ाइल में ऐसे मान रह जाते हैं जिन्हें किसी ने सचेत रूप से नहीं चुना।
<key>IKESecurityAssociationParameters</key>
<dict>
<key>EncryptionAlgorithm</key><string>AES-256</string>
<key>IntegrityAlgorithm</key><string>SHA-256</string>
<key>DiffieHellmanGroup</key><integer>14</integer>
<key>LifeTimeInMinutes</key><integer>1440</integer>
</dict>
मान मेल खाने पर भी दोनों पंक्तियाँ परिनियोजन रिकॉर्ड में लिखें। तब समीक्षक देख सकता है कि Child SA पर विचार किया गया था, न कि संयोगवश विरासत में मिला, और एक पंक्ति में बाद का परिवर्तन दूसरी को चुपचाप नहीं बदलता।
कोई स्ट्रिंग कॉपी करने से पहले जाँचें कि हर कुंजी का क्या अर्थ है
चारों कुंजियाँ किसी दूसरे उत्पाद की प्रस्ताव-स्ट्रिंग से विनिमेय नहीं हैं। एल्गोरिदम के नाम कार्यान्वयन-विशिष्ट हैं, इसलिए Apple के फ़ील्ड में strongSwan प्रस्ताव चिपकाने के बजाय चुने गए सेट का अनुवाद हर पक्ष के प्रलेखित वाक्य-विन्यास से करें।
| Key | Holds | Common mistake |
|---|---|---|
| EncryptionAlgorithm | Cipher for that association | Assuming an AEAD name also sets integrity |
| IntegrityAlgorithm | Integrity for the chosen suite | Leaving it set for an AEAD suite that does not use one |
| DiffieHellmanGroup | Numeric group identifier | Reading the number as key size in bits |
| LifeTimeInMinutes | Association lifetime | Setting it shorter than the gateway's renewal margin |
«सबसे बड़ी समूह संख्या इस्तेमाल करें» चयन की विधि नहीं है। समूह पहचानकर्ता भिन्न संरचनाओं को नाम देते हैं, और बड़ी संख्या का अर्थ सहज रूप से उसी चीज़ का अधिक मज़बूत संस्करण नहीं है। गेटवे के स्वामी से पूरा संयोजन स्वीकृत कराएँ, क्योंकि सेट समग्र रूप से वैध या अवैध होता है। अस्वीकृत समूह के साथ स्वीकृत सिफ़र अस्वीकृत प्रस्ताव है, और वह या तो विफल होगा या चुपचाप ऐसी चीज़ पर लौट जाएगा जिसे किसी पक्ष ने प्रलेखित नहीं किया।
पुराने एल्गोरिदम को सेवानिवृत्त करने वाली संस्करण-सीमाएँ जाँचें
Apple की पेलोड स्कीमा DES, 3DES, SHA1-96, SHA1-160 और Diffie-Hellman समूह 1, 2 और 5 को 26 से पहले के macOS संस्करणों तक सीमित करती है। पुराने परिनियोजन से लाई गई प्रोफ़ाइल में अभी भी उनमें से कोई मान हो सकता है और वह अभी भी पुराने गेटवे से जुड़ सकती है, और यही वह स्थिति है जहाँ कार्यशील कॉन्फ़िगरेशन सेवानिवृत्ति की तारीख छिपा देता है।
प्रोफ़ाइल बनाने से पहले समर्थित Mac संस्करण और गेटवे की बनाए रखी गई प्रस्ताव-नीति प्राप्त करें। फिर प्रतिच्छेद चुनें और दर्ज करें कि शेष विकल्प क्यों बाहर किए गए। «गेटवे पुराने क्लाइंट के लिए अभी भी समूह 2 देता है» वाला नोट इतिहास-रहित सिफ़र सूची से अधिक मूल्यवान है। उस नोट के बिना अगला समीक्षक जानबूझकर किए गए अपवाद और चूक के बीच अंतर नहीं कर सकता।
प्रमाणीकरण को उसकी अलग पंक्ति में जाँचें
किसी प्रस्ताव पर सहमति गलत सर्वर पहचान को ठीक नहीं करती। गेटवे की पहचान, प्रमाणपत्र पर भरोसा और उपयोगकर्ता या डिवाइस के क्रेडेंशियल अलग-अलग निर्णय हैं, और एल्गोरिदम पूरी तरह संरेखित होने पर भी हर एक विफल हो सकता है। प्रमाणपत्र का हस्ताक्षर एल्गोरिदम बदलना IKE एन्क्रिप्शन एल्गोरिदम चुनने के समान कार्य नहीं है, हालाँकि दोनों एक ही समीक्षा में दिखाई देते हैं।
अपेक्षित सर्वर पहचान को रिकॉर्ड में प्रस्ताव के पास रखें। प्रमाणपत्र परिवर्तन के बाद कनेक्शन विफल होने पर वह जोड़ी अगले व्यक्ति को बताती है कि पहले बातचीत हिली या भरोसे का निर्णय।
एक संशोधन परिनियोजित करें और देखें कि क्या बातचीत हुई
संगठन के समर्थित वितरण कार्यप्रवाह का उपयोग करें और प्रोफ़ाइल पहचानकर्ता, संशोधन, लक्ष्य Mac संस्करण और मेल खाती गेटवे नीति दर्ज करें। जो डिवाइस जुड़ नहीं सकते उन्हें प्रलेखित पुनर्प्राप्ति पथ दें, और ऐसी दूसरी समान नाम वाली प्रोफ़ाइल बनाने से बचें जिसका स्वामित्व कोई स्थापित न कर सके।
स्वीकृति के दौरान, स्वीकृत निदान के माध्यम से स्थापित कॉन्फ़िगरेशन और बातचीत किए गए IKE और Child संबंधों का निरीक्षण करें। फिर नियंत्रित नवीनीकरण बाध्य करें, क्योंकि पहला कनेक्शन केवल यह सिद्ध करता है कि प्रारंभिक बातचीत काम कर गई; जीवनकाल की असंगति आमतौर पर पहले कुंजी-परिवर्तन पर दिखती है, परिनियोजन स्वीकृत होने के बहुत बाद।
स्वीकृत सेट को संशोधन रिकॉर्ड के साथ रखें। तब अगले macOS अपडेट या गेटवे परिवर्तन के पास तुलना के लिए आधार-रेखा होती है, न कि ऐसी प्रोफ़ाइल जो आज महज़ संयोग से जुड़ती है।