Windows आणि strongSwan सिफर: योग्य स्तर जुळवा

दोन्ही टोके AES-128 म्हणतात आणि बोगदा तरीही तयार होण्यास नकार देतो. CBC आणि GCM वेगवेगळी रूपांतरे आहेत जी योगायोगाने समान की-लांबी सामायिक करतात, आणि एक देऊ करणारा क्लायंट फक्त दुसरे स्वीकारणाऱ्या गेटवेला समाधान देत नाही. AES हा शब्द एक कुटुंब वर्णन करतो, करार नाही.

दुसराही अक्ष आहे, आणि गोंधळात टाकणाऱ्या त्रुटी तोच निर्माण करतो.

दोन स्तर, दोन स्वतंत्र याद्या

IKE स्वतः वाटाघाटीचे संरक्षण करते, तर चाइल्ड असोसिएशन तुम्हाला खरोखर महत्त्वाच्या असलेल्या रहदारीचे संरक्षण करते. Windows पहिल्याला एन्क्रिप्शन पद्धत आणि अखंडता पद्धत म्हणून, आणि दुसऱ्याला सिफर व प्रमाणीकरण रूपांतर स्थिरांक म्हणून उघड करते. ती क्षेत्रे एकमेकांची उपनावे नाहीत, आणि एकात वैध मूल्य दुसऱ्यात अर्थहीन किंवा चुकीचे असू शकते. हे विभाजन लक्षात ठेवून प्रोफाइल वाचल्यास बहुतेक गोंधळ दूर होतो.

व्यावहारिक परिणाम असा की तुमच्याकडे पूर्णपणे स्वीकारार्ह की-देवघेव धोरण आणि साथीदार स्वीकारणार नाही असे डेटा-चॅनेल धोरण असू शकते. एक यादी वाटाघाटी करते; दुसरी पॅकेटचे संरक्षण करते. कॉन्फिगरेशन संवादात दोन्ही कितीही सारखी दिसली तरी पहिल्यातील मूल्य बदलल्याचा दुसऱ्यावर परिणाम होत नाही.

गेटवेशी तुलना करण्यापूर्वी दोन्ही याद्या लिहून ठेवा. स्मरणातून केलेली तुलना म्हणजे एक क्षेत्र दोन वेळा संपादित करणे आणि दुसरे कधीही न करणे. प्रोफाइलच्या शेजारी गेटवे कन्सोल उघडे ठेवा.

त्रुटी प्रस्तावांच्या शेजारी वाचा

अयशस्वी झालेला टप्पा कोणती यादी तपासायची ते सांगतो. सुरुवातीच्या की-देवघेवीत नकार ही IKE प्रस्तावाची समस्या आहे, आणि ती कोणतेही चाइल्ड असोसिएशन अस्तित्वात येण्यापूर्वीच घडते. संरक्षित-रहदारी असोसिएशनवर वाटाघाटी होत असताना अपयश हे ESP प्रस्तावाची समस्या आहे, आणि की-देवघेव आधीच यशस्वी झाली आहे. क्लायंटचा सामान्य धोरण-जुळणी संदेश दोन्हीपैकी कोणत्याही टप्प्याचे नाव घेत नाही, म्हणून गेटवेचाच दृष्टिकोन उपयुक्त आहे.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

प्राप्त प्रस्ताव, कॉन्फिगर केलेला प्रस्ताव आणि निवडलेला प्रस्ताव यांची तुलना करा त्या एकाच प्रयत्नासाठी. येथे तीन वेगळ्या याद्या महत्त्वाच्या आहेत, आणि प्रत्यक्षात काय वापरले गेले हे फक्त शेवटचीच सांगते. सारांश देण्याऐवजी तिकिटात तो शब्दशः उद्धृत करा.

CBC आणि GCM वेगळे पर्याय म्हणून ठेवा

कोणतेही कुटुंब स्वीकारण्यास जाणीवपूर्वक परवानगी असलेल्या गेटवेला एक नव्हे, दोन प्रस्ताव लागतात. strongSwan मध्ये स्वल्पविराम पर्याय वेगळे करतो, आणि हायफन एका संचाचे घटक जोडतो. दोन्ही कुटुंबे हायफनने एकत्र केल्यास दोन स्वीकारार्ह प्रस्तावांऐवजी एक अशक्य प्रस्ताव तयार होतो.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

पहिला पर्याय प्रमाणित एन्क्रिप्शन घेऊन येतो आणि तरीही स्यूडो-यादृच्छिक फलनाचे नाव घेतो, कारण अखंडता सिफरमधून आली तरी की-व्युत्पत्तीला एकाची गरज असते. दुसरा पर्याय वेगळ्या अखंडता अल्गोरिदमसह पारंपरिक एन्क्रिप्शन आहे. दोन्ही लोड केलेली क्रिप्टो अंमलबजावणी काय समर्थन देते यावर अवलंबून आहेत.

ESP प्रस्ताव पुनर्नामित IKE प्रस्ताव नाही

सिफर टोकन दोन्ही याद्यांमध्ये सारखेच दिसते, आणि जवळपास दुसरे काहीही पुढे जात नाही. ESP प्रस्तावात की-देवघेवीचे स्यूडो-यादृच्छिक फलन नसते, आणि त्याच्या अखंडता व पुढे-गोपनीयतेच्या आवश्यकता IKE ओळीतून नकल करण्याऐवजी दुसऱ्या बाजूच्या Windows धोरणाविरुद्ध मांडल्या जातात. एक यादी दुसऱ्यात यांत्रिकपणे भाषांतरित केल्यास सत्यापित होणारे पण कधीही वाटाघाटी न करणारे काहीतरी तयार होते.

एक दिशा निवडा आणि तिच्यात राहा. एकतर गेटवे फक्त GCM धोरण ठेवतो आणि क्लायंट पूर्ण सुसंगत धोरण तैनात करतो, किंवा गेटवे दोन्ही कुटुंबे स्वीकारतो आणि क्लायंट आपला विद्यमान संच ठेवतो. सुरक्षा धोरणाने प्रतिबंधित केलेला फॉलबॅक सक्षम करणे त्रुटी कितीही लवकर दूर केली तरी उपाय नाही.

दोन्ही संच सत्यापित करा, नंतर की-नूतनीकरण

निवडलेला की-देवघेव संच आणि निवडलेला रहदारी संच स्वतंत्रपणे पुष्टी करा, कारण ते वेगळ्या याद्यांमधून येतात आणि स्वतंत्रपणे यशस्वी होऊ शकतात. नंतर की-नूतनीकरण होऊ द्या आणि तेही पुष्टी करा. कार्यरत पहिला हस्तांदोलन आणि अयशस्वी की-नूतनीकरण अंशतःच स्वीकारार्ह अशा प्रस्ताव-संचाचे वर्णन करतात.

तो पुरावा बदलासोबत ठेवा. वारंवार होणारे कनेक्शन तुटणे याला कोणी टाइमर किंवा प्लॅटफॉर्म दोषाला दोष देण्यापूर्वी स्वतःची अयशस्वी-देवघेव नोंद आवश्यक आहे.