एका IKEv2 लॉगिनमध्ये दोन ओळखी: आधी मशीन, नंतर वापरकर्ता

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

लक्षण: यशस्वी पहिल्या पुराव्यानंतरचे अपयश

पहिली देवाणघेवाण पूर्ण होते आणि लॉग निरोगी दिसतो, गेटवे EAP द्वारे वापरकर्ता ओळख मागत नाही तोपर्यंत। मग हँडशेक थांबतो किंवा अतिरिक्त फेरीचे नाव देणारी प्रोटोकॉल त्रुटी परत येते। पूर्णपणे वैध मशीन प्रमाणपत्र त्याच्या वैधतेशी काहीही संबंध नसलेल्या कारणाने नाकारले जाते। धोरणाने दुसरा पुरावा मागितला होता, आणि क्लायंटचे उत्तर कधीही आले नाही।

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

विस्तार काय जोडतो आणि काय जोडत नाही

IKEv2 एका सत्रात एकापेक्षा जास्त प्रमाणीकरण देवाणघेवाण चालवण्यासाठी विस्तार घेऊन येते। RFC 4739 इतर क्रमांसोबत, प्रमाणपत्र ओळख सिद्ध करून नंतर EAP द्वारे व्यक्तीचे प्रमाणीकरण करणारा क्लायंट रेखाटतो। दस्तऐवज Experimental स्थितीत आहे, म्हणजे कोणतेही अंमलबजावणी तुम्हाला हे वैशिष्ट्य देण्यास बांधील नाही। सहकारी त्यावर वाटाघाटी करेपर्यंत समर्थनाबद्दल काहीही गृहीत धरू नका।

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

प्रत्येक एंडपॉइंटला एक पुरावा हा नेहमीचा आकार आहे, आणि ही ती रचना नाही। गेटवे त्याचे प्रमाणपत्र सादर करते, वापरकर्ता EAP द्वारे उत्तर देतो, आणि प्रत्येक बाजूने दुसऱ्याचे नेमके एकदा प्रमाणीकरण केले आहे। ते दोन पुरावे विरुद्ध टोकांकडून येतात, म्हणून कोणतेही मशीन आणि ते वापरणाऱ्या व्यक्तीबद्दल स्वतंत्रपणे काहीही सांगत नाही।

EAP-TLS हा तिसरा आकार आहे, आणि तोही हा नाही। तिथे क्लायंट प्रमाणपत्र EAP पद्धतीच्या आत सादर केले जाते, म्हणून क्लायंट अजूनही एकच IKE प्रमाणीकरण पूर्ण करतो। क्रेडेन्शियल्स बहु-फेरीच्या प्रकरणासारखे सारखे दिसू शकतात, पण प्रोटोकॉल दोनऐवजी एक फेरी वाहून नेते। म्हणूनच EAP-TLS तैनातीतून नकल केलेली रचना दुसरा पुरावा अपेक्षित असलेल्या ठिकाणीच अपयशी ठरते।

तेच फाइल गेटवेवर वेगळ्या पद्धतीने वाचली जाते

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

विभागाची जागा त्याचा क्रम ठरवते, जोपर्यंत फेरी क्रमांक त्यावर मात करत नाही। म्हणून अतिरिक्त local किंवा remote विभाग पर्याय नव्हे तर अतिरिक्त फेऱ्या वर्णन करतात, आणि swanctl.conf संदर्भ मधील स्पष्ट फेरी क्रमांक तो क्रम जाणीवपूर्वक करण्यासाठीच आहे। त्याशिवाय ब्लॉक हलवल्याने वर्तन बदलते। म्हणूनच कागदावर समान दिसणारी दोन संरचना विरुद्ध क्रमाने वागू शकतात।

तो क्रम-नियम लक्षात ठेवण्यासारखा अपयशाचा प्रकार निर्माण करतो। दुसरा remote ब्लॉक हा दुसरा स्वीकारार्ह पर्याय नाही, तो दुसरी मागणी आहे, म्हणून एक तर/किंवा असे वाचले जाणारे धोरण आणि-नंतर असे वागते। गेटवे धोरण नोंदणीकृत मशीनचे प्रमाणपत्र स्वीकारू शकते आणि नंतर त्या वापरकर्त्याची EAP देवाणघेवाण त्याच क्रमाने मागू शकते।

फेऱ्या स्वतंत्र घटकांपासून वेगळ्या ओळखा

दोन फेऱ्या आपोआप दोन स्वतंत्र घटक नसतात। पुरावा पुन्हा करणे, किंवा एकाच भांडारात दोन क्रेडेन्शियल्स ठेवणे, रचनेने जोडायचे होते ते सामर्थ्य देत नाही। स्वातंत्र्य हे रहस्ये कशी ठेवली जातात आणि काय त्यांना तडजोडीत आणते याचे गुणधर्म आहे, प्रोटोकॉल किती देवाणघेवाण करतो याचे नाही। फेऱ्यांची घटक म्हणून गणना करणारी रचना आपल्याकडे असलेल्याचा अतिरेक करते। अनुपालनाचा प्रश्न लॉगिन प्रत्यक्षात किती घटक वापरते असे विचारतो तेव्हा हा फरक सर्वात महत्त्वाचा ठरतो।

मशीन प्रमाणपत्र त्याच्या स्वीकृत कीची मालकी सिद्ध करते, आणि त्यापुढे काहीही नाही। ते हार्डवेअर अटेस्टेशन नाही किंवा उपकरण-आरोग्य अहवाल नाही, म्हणून स्थिती माहिती आवश्यक असलेल्या धोरणाला वेगळी यंत्रणा आवश्यक आहे। subject फील्डही विश्वासार्ह मालमत्ता टॅग नाही, कारण subject प्रमाणपत्र जारी किंवा नोंदणी करणाऱ्याने निवडले जाते। रचनेला मशीन निरोगी असल्याचा पुरावा हवा असेल, तर तो पुरावा मशीन मोजणाऱ्या घटकाकडून आला पाहिजे।

प्रत्येक फेरी प्रत्यक्षात काय सिद्ध करते ते जोडण्यापूर्वी लिहून ठेवा। दोन फेऱ्या एकच गोष्ट दोनदा सिद्ध करतात तेव्हा दुसरी खात्रीऐवजी विलंब आणि समर्थन तिकिटे जोडते। ती नोंद अतिरिक्त फेरी आपल्या खर्चास पात्र आहे का या वादाला थांबवते।

जोडणी नियम लिहा आणि नकार तपासा

कोणत्या मशीन ओळखी कोणत्या लोकांशी जोडल्या जाऊ शकतात हे ठरवा, आणि नियम जिथे अंमलबजावणी राहते तिथे लिहा। शेजारी ठेवलेली दोन वैध क्रेडेन्शियल्स जोडणीबद्दल काहीही सिद्ध करत नाहीत, कारण जोडणी ही प्रमाणीकरणाचा निकाल नव्हे तर अधिकृततेचा निर्णय आहे। नोंदणी नोंदी किंवा प्रमाणीकरण बॅकएंडने संस्थेला हवे असलेले नाते लागू केले पाहिजे।

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

swanctl --list-conns
swanctl --list-sas

फक्त यशस्वी लॉगिन नव्हे, तर वाटाघाटी झालेल्या फेऱ्या आणि त्यातून मिळणारी अधिकृतता तपासा। आणि शॉर्टकट म्हणून जुन्या IKEv1 XAuth सेटिंग्जकडे वळू नका: कनेक्शन यशस्वी होईपर्यंत आवश्यक फेरी हटवण्याऐवजी प्रोटोकॉल, भूमिका, क्रम आणि क्लायंटचे खरे वर्तन जुळवा। जी फेरी अपयशी होते ती हटवणे म्हणजे दोन-पुराव्यांची रचना कोणीही पुनरावलोकन न केलेल्या एक-पुराव्याच्या रचनेत शांतपणे बदलण्याचा मार्ग। हटवणी बदल-नोंदीत ठेवा।