IKEv2 विंडोज़ और FortiGate पर: तीन सेटिंग्स जिन्हें लोग एक साथ मिला देते हैं
IKE कुंजी विनिमय, CHILD SA सुरक्षा और पीयर प्रमाणीकरण तीन अलग पंक्तियाँ हैं। दो संवादों में ग्रुप संख्या मेल खाने से वे एक नहीं हो जातीं।
Windows क्लाइंट और FortiGate गेटवे के बीच IKEv2 समझौता बार-बार विफल होता रहता है, और बेमेल संख्या की खोज संख्याओं की और लंबी सूची बनाती है। सूची तभी संभालने योग्य बनती है जब उसे तीन पंक्तियों में बाँटा जाए जो स्वतंत्र रूप से विफल होती हैं: वह कुंजी विनिमय जो IKE की रक्षा करता है, CHILD SA पर लगाया गया संरक्षण, और वह प्रमाणीकरण जो सिद्ध करता है कि प्रत्येक पक्ष कौन है। ग्रुप संख्याएँ उनमें से दो पंक्तियों में दिखाई देती हैं और अलग-अलग अर्थ रखती हैं।
तीन पंक्तियाँ जो स्वतंत्र रूप से विफल होती हैं
पहली पंक्ति IKE के भीतर का कुंजी विनिमय है, जो वह कुंजियाँ बनाता है जो बातचीत की रक्षा करती हैं। दूसरी CHILD SA के लिए प्रस्ताव है, जो टनल द्वारा ले जाए जाने वाले ट्रैफ़िक की रक्षा करता है। तीसरी प्रमाणीकरण है, जो तय करता है कि प्रत्येक पक्ष क्या प्रस्तुत करता है और दूसरा पक्ष उसे कैसे सत्यापित करता है।
विफलताएँ अलग-अलग जगहों पर होती हैं। विनिमय की विफलता किसी टनल के बनने से पहले ही बातचीत रोक देती है। CHILD SA की विफलता प्रमाणीकरण सफल होने के बाद होती है, कभी-कभी केवल कुंजी नवीनीकरण पर। प्रमाणीकरण की विफलता लॉग में विनिमय की विफलता जैसी दिख सकती है, अगर आप केवल पहली त्रुटि पढ़ते हैं।
पंक्तियों को अलग करना लेखा-जोखा नहीं है। यह बदलता है कि कौन-सी सेटिंग बदलने योग्य है, और यह इस पूरे क्षेत्र का सबसे महँगा कदम रोकता है, अर्थात् प्रस्ताव की असंगति ठीक करने के लिए काम कर रहे प्रमाणपत्रों को फिर से बनाना। एक पंक्ति का बदलना कभी भी अन्य दो को अपने साथ बदलने के लिए बाध्य नहीं करना चाहिए। यही स्वतंत्रता उन्हें अलग-अलग लिखने का पूरा उद्देश्य है।
Windows के दो फ़ील्ड क्या नियंत्रित करते हैं
Windows दो फ़ील्ड अलग रखता है: DHGroup स्वयं IKE विनिमय को कॉन्फ़िगर करता है, जबकि PfsGroup उस IPsec नीति को कॉन्फ़िगर करता है जो टनल के भीतर ट्रैफ़िक की रक्षा करती है। वे अलग-अलग चरणों के हैं। Windows के IKE फ़ील्ड की तुलना FortiGate के चरण 2 मान से करना गलत जोड़ी की जाँच करना है, और संख्याएँ मेल खा सकती हैं जबकि अंतर्निहित विनिमय अभी भी विफल हो।
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAदूसरा और तीसरा कमांड वे सुरक्षा संबद्धताएँ बताते हैं जो वास्तव में मौजूद हैं, और यह उस उत्तर के सबसे निकट है जो कोई क्लाइंट आपको दे सकता है। मुख्य मोड संबद्धता होना पर तेज़ मोड संबद्धता न होना CHILD SA की समस्या है, और यह प्रमाणपत्र की समस्या नहीं बल्कि चरण 2 की असंगति का लक्षण है।
एक प्रयास में क्या पेश किया गया और क्या चुना गया, यह दर्ज करें। जिस प्रस्ताव-सूची में एक स्वीकार्य प्रस्ताव हो और चुना गया प्रस्ताव गेटवे की नीति से मेल न खाए, वह कॉन्फ़िगरेशन असहमति है, अंतर-संचालनीयता का रहस्य नहीं।
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
दीर्घवृत्तीय वक्र का ग्रुप आपकी हस्ताक्षर कुंजी नहीं चुनता
इस क्षेत्र का सबसे ज़िद्दी गलत अनुमान यह है कि दीर्घवृत्तीय वक्र का DH ग्रुप चुनने के लिए दीर्घवृत्तीय वक्र का प्रमाणपत्र आवश्यक है। DH ग्रुप कुंजी विनिमय की सामग्री देता है; हस्ताक्षर एल्गोरिद्म पर प्रमाणीकरण ढाँचा बातचीत करता है, और IKEv2 में ये दो अलग निर्णय हैं।
RFC 7427 ठीक इसलिए मौजूद है कि ये निर्णय पहले आपस में उलझे हुए थे, और यह परिभाषित करता है कि हस्ताक्षर एल्गोरिद्म कुंजी विनिमय से स्वतंत्र रूप से कैसे घोषित और चुने जाते हैं। कोई गेटवे एक ही समय में वक्र ग्रुप और हस्ताक्षर योजनाओं का चयन दोनों का समर्थन कर सकता है।
इसलिए जब ग्रुप बदलने के बाद बातचीत विफल हो, तो प्रमाणपत्र की कुंजी का प्रकार देखने से पहले प्रमाणीकरण विधि देखें। प्रमाणपत्र बदलना एक धीमा, जोखिम भरा कार्य है जो शायद ही कभी उत्तर होता है, और इसे पहले करना यह जानने की आपकी क्षमता नष्ट कर देता है कि किस बदलाव ने वास्तव में मदद की। प्रमाणपत्र भंडार को छूने से पहले प्रमाणीकरण पंक्ति पढ़ें।
दोनों को समझौता पत्रक की अलग पंक्तियों में रखें और गलती लुभावनी होना बंद कर देगी। एक पंक्ति ग्रुप सूचीबद्ध करती है, दूसरी हस्ताक्षर योजनाएँ और पहचान, और कोई भी दूसरे के बारे में साक्ष्य नहीं है।
हर निजी कुंजी को उसके वास्तविक स्वामी के पास रखें
जो गेटवे अपना प्रमाणपत्र प्रस्तुत करता है उसे उससे मेल खाने वाली निजी कुंजी चाहिए। जो पीयर श्रृंखला सत्यापित करता है उसे CA प्रमाणपत्र चाहिए, और विशेष रूप से CA की हस्ताक्षर कुंजी की आवश्यकता नहीं है। इन तीन तत्वों को मिलाना ही वह तरीका है जिससे लोग प्रमाणपत्र को दूसरी श्रेणी में दिखाने के लिए VPN उपकरण में CA की निजी कुंजी आयात करते हैं।
FortiOS पर भूमिकाएँ अलग हैं: अपनी कुंजी के साथ स्थानीय प्रमाणपत्र, पीयर की पहचान के लिए उपयोग किया जाने वाला दूरस्थ प्रमाणपत्र, और दूरस्थ CA प्रविष्टि जो उस CA द्वारा हस्ताक्षरित प्रमाणपत्रों में विश्वास स्थापित करती है। निजी कुंजी के बिना दूरस्थ CA प्रविष्टि अपूर्ण नहीं है; वह अपने उद्देश्य के लिए सही है।
आयातित CA हस्ताक्षर कुंजियाँ उस उपकरण को पढ़ सकने वाले हर व्यक्ति के अधिकार को बढ़ाती हैं। वे सामान्य पीयर सत्यापन भी हल नहीं करतीं, क्योंकि सत्यापन को सार्वजनिक प्रमाणपत्र और विश्वास का निर्णय चाहिए, नई प्रमाणपत्र बनाने की क्षमता नहीं।
CA की हस्ताक्षर कुंजी को जारीकर्ता की अपनी प्रक्रिया के पास रखें, और दर्ज करें कि कौन-सा उपकरण कौन-सी कुंजी रखता है। जब ऑडिट पूछे कि कौन किसका रूप धारण कर सकता था, तब स्वामियों की छोटी तालिका एल्गोरिद्म की लंबी तालिका से अधिक मूल्यवान है। कोई ऐसी कुंजी आयात नहीं करता जिसे वह जानता है कि केवल सूची के लिए है। घटना से पहले सूची लिखें, बाद में नहीं।