Windows आणि FortiGate वर IKEv2: लोक एकत्र करतात अशा तीन सेटिंग्ज
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 ची स्वाक्षरी की जारी करणाऱ्याच्या स्वतःच्या प्रक्रियेकडे ठेवा, आणि कोणते उपकरण कोणती की ठेवते ते नोंदवा। लेखापरीक्षण विचारते तेव्हा कोण कोणाचे रूप धारण करू शकले असते, तेव्हा मालकांचे छोटे तक्ते अल्गोरिदमच्या लांब तक्त्यापेक्षा अधिक मूल्यवान असते। कोणीही केवळ साठ्यासाठी आहे हे माहीत असलेली की आयात करत नाही। घटनेनंतर नाही, आधी साठा लिहा।