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 आणि त्याचे उर्वरित आयुष्य समाविष्ट आहे। दुसरा क्लायंट प्रोफाइलमध्ये आता काय आहे ते दाखवतो, आणि तुम्ही सेट केलेले धोरणच प्रभावी धोरण आहे याची खात्री करण्याचा तोच एकमेव मार्ग आहे।
यश जाहीर करण्यापूर्वी संपूर्ण की-नूतनीकरण पाहा। म्हणजे चाइल्ड असोसिएशन बदलण्याइतका काळ कनेक्शन वर ठेवणे आणि नंतर रहदारी सुरू आहे याची खात्री करणे। बहुतेक धोरण-विसंगती त्या टप्प्यात लपलेल्या असतात, कारण सुरुवातीची वाटाघाटी नूतनीकरण स्वीकारत नसलेल्या संचासहही यशस्वी होऊ शकते।
रोलबॅक म्हणजे आधीचा घटक संच, सोयीस्कर पर्याय नाही। क्लायंटने फक्त कमकुवत जुना गट दिला असेल, तर उत्तर क्लायंट आणि सर्व्हरचे सामायिक धोरण सुधारणे हे आहे, तो गट गेटवेवर जोडणे नाही जिथे भविष्यातील प्रत्येक बाजू त्याच्याकडे खाली वाटाघाटी करू शकेल।
चार घटक, गट, कनेक्शनची व्याप्ती आणि की-नूतनीकरणाचा निकाल नोंदवा। ही छोटी नोंद आहे, आणि मार्गदर्शक व बोगदा एकदा वर आला त्याची गोष्ट यातील फरक तोच आहे।