Group24 आणि MODP3072 दोन्ही की-एक्स्चेंज गटाची नावे आहेत, आणि ते वेगवेगळ्या ताकदीचा एकच गट नाहीत। Group24 2048-बिट मॉड्युलसला 256-बिट मूळ-क्रम उपगटासोबत एकत्र करतो, तर MODP3072 हा 3072 बिटांचा 15 वा गट आहे। दुसरा निर्दिष्ट असताना एक निवडणे हे आवश्यकता पूर्ण करण्याऐवजी बदलते। निकाल चार गोष्टी ठरवतात, आणि त्यापैकी कोणतीही सारखे दिसणाऱ्या नावावर विश्वास ठेवण्याची मागणी करत नाही।

क्रमांक नोंदवहीतील नोंद आहे, श्रेणी नाही

IANA की-एक्स्चेंज गटांना त्यांच्या नोंदणीच्या क्रमाने क्रमांक देतो, त्यामुळे मोठा क्रमांक म्हणजे नंतरची नोंदवही नोंद, अधिक मजबूत गट नाही। गट 14 हा 2048-बिट MODP आहे, गट 15 हा 3072-बिट MODP आहे, आणि गट 24 2048-बिट मॉड्युलसला 256-बिट मूळ-क्रम उपगटासोबत एकत्र करतो। ओळखकर्ता आकार-श्रेणी म्हणून वाचल्याने 24 ला 15 पेक्षा मोठे मानण्याची तीच चूक होते। नाव एक लेबल आहे, आणि त्यामागील पॅरामीटर्स हेच वाटाघाटी प्रत्यक्षात वापरते।

IANA groupWhat the group isExpressible as Windows DHGroupWhat a mismatch looks like
14A 2048-bit finite-field modulusGroup14The gateway reports modp2048, which is the same group in other vocabulary
15A 3072-bit finite-field modulusNot in the documented enumerationYou cannot request it from this parameter; a gateway reporting modp3072 was configured elsewhere
24A 2048-bit modulus with a 256-bit prime-order subgroupGroup24The gateway reports modp2048s256, so the two names differ while describing one group
20The NIST P-384 curveECP384The gateway reports ecp384, and that 384 counts a field size rather than a modulus

लंबवृत्तीय वक्र गट आपली स्वतंत्र गोंधळ जोडतात, कारण वक्राची बिट-संख्या क्षेत्राचे वर्णन करते, मॉड्युलसचे नाही। P-384 ची 3072-बिट मर्यादित-क्षेत्र गटाशी तुलना करणे, जणू संख्या एकच गोष्ट मोजत आहेत, तुम्हाला काहीही सांगत नाही।

Windows ची गणना काय व्यक्त करू शकते

IKE नोंदवही आणि Windows क्लायंट पॅरामीटर वेगवेगळ्या शब्दसंग्रहाचे वेगवेगळे इंटरफेस आहेत। Microsoft चे VpnClient cmdlet संदर्भ सांगतात की DHGroup None, Group1, Group2, Group14, ECP256, ECP384 आणि Group24 स्वीकारतो। Group15 त्या दस्तऐवजीकृत संचात येत नाही, याचा अर्थ पॅरामीटर तुमच्याकडून मागितलेला गट व्यक्त करू शकत नाही। ही इंटरफेसची मर्यादा आहे, प्रोटोकॉल कोणत्या गटांना समर्थन देतो याचे विधान नाही।

यादीत नसलेले स्पेलिंग, पूर्णांक किंवा कॉपी केलेली धोरण स्ट्रिंग देणे गणना वाढवत नाही। तुम्ही प्रत्यक्षात तैनात करत असलेल्या Windows आवृत्तीसाठी संदर्भ तपासा, आणि गट उपलब्ध नसल्यास प्रामाणिक परिणाम दुसरे मंजूर धोरण किंवा दुसरा क्लायंट आहे।

DHGroup, PfsGroup आणि प्रमाणपत्र प्रकार वेगळे ठेवा

DHGroup IKE की-एक्स्चेंजसाठी गट निवडतो, आणि PfsGroup त्यानंतर येणाऱ्या संरक्षित-ट्राफिक संलग्नतांसाठी पुढे गोपनीयता नियंत्रित करतो। ही वेगळी फील्ड आहेत, त्यामुळे एक योग्यरित्या सेट केल्याने दुसऱ्याबद्दल काहीही सांगत नाही। प्रमाणपत्राची RSA किंवा ECDSA की तिसरा गुणधर्म आहे, आणि ती प्रमाणीकरणाशी संबंधित आहे, क्षणिक देवघेवीशी नाही। त्यामुळे एक प्रोफाइल एका स्तरात योग्य आणि दुसऱ्यात चुकीचे असू शकते, आणि यशस्वी कनेक्शन कोणते ते उघड करणार नाही।

विशिष्ट प्रमाणपत्र प्रकाराने प्रत्येक IKEv2 कनेक्शनवर ECP गट लादला अशा अहवालांमध्ये सेटिंग्जचे एक संयोजन वर्णन केले जाते। ते प्रोटोकॉलचा नियम स्थापित करत नाहीत, आणि त्यांना नियम मानणे हा स्थानिक विचित्रता धोरण होण्याचा मार्ग आहे।

गेटवेने वाटाघाटी केलेला गट वाचा

VpnClient मॉड्यूल Set-VpnConnectionIPsecConfiguration फक्त-लेखन इंटरफेस म्हणून देते, आणि होस्टवर ते धोरण परत वाचणारा कोणताही जुळणारा Get- cmdlet नाही। तुम्ही लागू केलेली DHGroup आणि PfsGroup मूल्ये नोंदवा, नंतर गेटवेवर देवघेवीने प्रत्यक्षात काय वापरले ते वाचा। आदेश नवीन कनेक्शननंतर चालवा, जुनी संलग्नता पुन्हा वापरणाऱ्या पुनर्कनेक्शननंतर नाही।

swanctl --list-sas
ipsec statusall

प्रोफाइल Group24 नोंदवत असताना गेटवे modp2048s256 नोंदवत असेल तर ते सुसंगत आहे, कारण ते दोन शब्दसंग्रहांत एकच गट आहे। गेटवे modp3072 नोंदवत असताना प्रोफाइल Group24 म्हणत असेल तर ते सुसंगत नाही, आणि एक टोक तुम्ही मानता ते अंमलात आणत नाही। प्रमाणपत्राची ओळ स्वतंत्र प्रमाणीकरण प्रश्नाचे उत्तर देते, आणि PFS फील्ड तिसऱ्याचे। अनुपालन टीप लिहिण्यापूर्वी तिन्हींची तुलना करा।

मागितलेला गट, वाटाघाटी झालेला गट आणि सेटिंग स्वीकारणारा किंवा नाकारणारा इंटरफेस नोंदवा। तोच त्रिक समीक्षकाला हवा असतो, आणि त्यातील काहीही धोरणाच्या नावावरून अनुमानित करता येत नाही।

संबंधित लेख