Windows और strongSwan: IKE प्रस्ताव में चारों ट्रांसफ़ॉर्म मिलाना
जब दोनों पक्ष कुंजी-विनिमय समूह पर असहमत हों तो साझा साइफ़र पर्याप्त नहीं है। चारों ट्रांसफ़ॉर्म की तुलना करें, फिर एक सीमित प्रोफ़ाइल नीति लागू करें।
दोनों पक्ष AES का समर्थन करते हैं, दोनों SHA-256 स्वीकार करते हैं, और फिर भी टनल ऊपर नहीं आता। प्रस्ताव उस घटक पर विफल हुआ जिसकी किसी ने तुलना नहीं की थी, आमतौर पर कुंजी-विनिमय समूह। यह मार्गदर्शिका कुछ भी बदलने से पहले वास्तविक विनिमय पढ़ती है, एक सीमित नीति लागू करती है और पिछले पैरामीटर बहाल करने वाला रोलबैक छोड़ती है।
समूह बदलने से पहले विफलता पढ़ें
«नीति मिलान त्रुटि» सारांश है, निदान नहीं। इसका अर्थ है कि परस्पर स्वीकार्य कोई प्रस्ताव नहीं मिला, और यह नहीं बताता कि कौन सा घटक अस्वीकार हुआ। इसे जाँच की शुरुआत मानें, किसी विशेष समूह के बारे में साक्ष्य नहीं।
उत्तर आमतौर पर सर्वर पक्ष के पास होता है। उपयुक्त स्तर पर strongSwan लॉग क्लाइंट से मिला प्रस्ताव और स्वीकार करने के लिए कॉन्फ़िगर किया गया प्रस्ताव सूचीबद्ध करता है, और दोनों सूचियों का अंतर विफल घटक का नाम बताता है।
यह न मानें कि क्लाइंट वही देता है जो कोई पुरानी फ़ोरम पोस्ट कहती है। सक्रिय प्रोफ़ाइल और उसकी स्थापित नीति प्रस्तावित सूची तय करते हैं, और अद्यतन किया गया Windows बिल्ड उस स्क्रीनशॉट से अलग सेट दे सकता है जिससे आप नकल कर रहे हैं।
दोनों सूचियाँ लिख लें। चार ट्रांसफ़ॉर्म स्थितियाँ और एक समूह छोटी सूची है, और इसे पंक्ति दर पंक्ति तुलना करने में किसी भी प्रयोग से कम समय लगता है। चार स्थितियाँ नज़र में रखना आसान है। लॉग फ़ाइल नहीं।
हर ट्रांसफ़ॉर्म की तुलना करें, किसी एक परिचित नाम की नहीं
IKE प्रस्ताव विकल्पों का ऐसा समूह है जिनमें सभी का मेल होना चाहिए। एन्क्रिप्शन वार्ता की रक्षा करता है, अखंडता या कोई PRF उसे प्रमाणित करता है, और Diffie-Hellman समूह ताज़ा कुंजी सामग्री स्थापित करता है। जो प्रस्ताव पहले दो में मेल खाता है और तीसरे में भिन्न है, वह दोनों पक्षों के लिए फिर भी अस्वीकार्य है।
यहाँ जो दो Windows फ़ील्ड भ्रमित होते हैं वे अलग चरणों के हैं। DHGroup IKE कुंजी-विनिमय पर लागू होता है, जबकि PfsGroup ट्रैफ़िक की रक्षा करने वाले चाइल्ड एसोसिएशन पर लागू होता है। दूसरे को बदलना पहले की विफलता नहीं सुधार सकता।
समूहों के नाम कार्यान्वयनों में अलग होते हैं, और यह भ्रम का अलग स्रोत है। strongSwan modp2048 और ecp256 लिखता है, जबकि Windows Group14 और ECP256 जैसे गणना-नाम उपयोग करता है, इसलिए तुलना से पहले अनुवाद करना पड़ता है। दोनों नामों के साथ दो स्तंभों वाला नोट रखें। तब अगली असंगति सेकंडों में वर्गीकृत हो जाती है।
| Transform | Windows parameter | strongSwan name | Failure it causes |
|---|---|---|---|
| Encryption | CipherTransformConstants | aes, aes256gcm and similar | No common proposal at all |
| Integrity or PRF | AuthenticationTransformConstants | sha256, sha512 and similar | Proposal rejected after encryption matches |
| Key-exchange group | DHGroup | modp2048, ecp256 | Exchange fails during key establishment |
| Child SA protection | PfsGroup | esp proposal groups | Tunnel negotiates, data association does not |
एक पूरी और सीमित नीति लागू करें
मूल IKEv2 प्रोफ़ाइल के लिए समर्थित साधन प्रति-कनेक्शन IPsec नीति है, जो एक-एक फ़ील्ड के बजाय एक ऑब्जेक्ट के रूप में सेट होती है। पहले पूर्वावलोकन करें, फिर लागू करें, और पिछले पैरामीटर परिवर्तन रिकॉर्ड में रखें।
Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf-WhatIf स्विच स्थानीय परिवर्तन का पूर्वावलोकन करता है और कुछ लागू नहीं करता। यह उपयोगी है और साथ ही आम जाल भी है, क्योंकि पूर्वावलोकन केवल यह सिद्ध करता है कि पैरामीटर स्थानीय cmdlet के लिए वाक्य-रचना की दृष्टि से स्वीकार्य हैं। यह नहीं बताता कि गेटवे परिणामी प्रस्ताव स्वीकार करेगा या नहीं।
वहीं रहते हुए दायरा भी मिलाएँ। सभी उपयोगकर्ताओं के स्टोर में कनेक्शन को संबंधित सभी-उपयोगकर्ता पैरामीटर चाहिए, और उसी प्रदर्शित नाम के साथ प्रति-उपयोगकर्ता प्रोफ़ाइल संपादित करने से कोई दूसरा ऑब्जेक्ट बदलता है जिसे टनल उपयोग नहीं करता।
फिर परीक्षण से पहले strongSwan पक्ष को उसी सेट पर लाएँ। दोनों सिरों पर समन्वित परिवर्तन ही इसका एकमात्र संस्करण है जो अभिसरित होता है; एक पक्ष बदलकर बार-बार पुनः प्रयास करने से वही अस्वीकृति भरा लॉग बनता है।
विनिमय और कुंजी-नवीनीकरण की जाँच अलग-अलग करें
सफल कनेक्शन एक अवलोकन है, और कुंजी-नवीनीकरण दूसरा। प्रारंभिक IKE वार्ता एक पैरामीटर सेट उपयोग करती है, और ट्रैफ़िक ढोने वाला चाइल्ड एसोसिएशन बाद में अपनी नीति के साथ फिर से वार्ता कर सकता है। जो सेटअप जुड़ता है और फिर कुछ समय बाद गिर जाता है, वह आमतौर पर दूसरा मामला होता है।
ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *पहला कमांड स्थापित एसोसिएशनों पर सर्वर का दृष्टिकोण दिखाता है, जिसमें चाइल्ड SA और उसका शेष जीवनकाल शामिल है। दूसरा दिखाता है कि क्लाइंट प्रोफ़ाइल में अब क्या है, और यही पुष्टि करने का एकमात्र तरीका है कि आपने जो नीति सेट की वही प्रभावी नीति है।
सफलता घोषित करने से पहले पूर्ण कुंजी-नवीनीकरण देखें। इसका अर्थ है कनेक्शन को इतनी देर ऊपर रखना कि चाइल्ड एसोसिएशन बदल जाए, और फिर पुष्टि करना कि ट्रैफ़िक जारी है। अधिकांश नीति-असंगतियाँ उसी चरण में छिपी होती हैं, क्योंकि प्रारंभिक वार्ता ऐसे सेट के साथ सफल हो सकती है जिसे नवीनीकरण स्वीकार नहीं करता।
रोलबैक पिछला पैरामीटर सेट है, कोई ढीला विकल्प नहीं। यदि क्लाइंट ने केवल कोई कमज़ोर पुराना समूह दिया था, तो उत्तर क्लाइंट और सर्वर की साझा नीति सुधारना है, उस समूह को गेटवे में जोड़ना नहीं जहाँ हर भावी पक्ष उसकी ओर नीचे वार्ता कर सके।
चार पैरामीटर, समूह, कनेक्शन का दायरा और कुंजी-नवीनीकरण का परिणाम दर्ज करें। यह छोटा नोट है, और यही मार्गदर्शिका तथा टनल के ऊपर आने की कहानी के बीच का अंतर है।