तुमचे IKEv2 SA सुरू आहे पण कोणतेही चाइल्ड SA नाही: देवघेव वाचा

IKE म्हणते बोगदा सुरू आहे, चाइल्ड SA अनुपस्थित आहे, आणि दोन्ही विधाने एकाच वेळी खरी असू शकतात। प्रस्थापित नियंत्रण संबंध डेटा असोसिएशन नाही, आणि दोन्ही वस्तूंचे आयुष्य, बोलणी आणि अयशस्वी होण्याच्या पद्धती वेगळ्या आहेत। पहिल्याची कनेक्टिव्हिटी म्हणून नोंद करणे हा तो मार्ग आहे ज्यामुळे तिकीट शेवटी बोगदा सुरू असल्याचा दावा करते पण काहीही चालत नाही। जोडणीच्या सारांश लेबलऐवजी असोसिएशनची यादी वाचा, कारण ती यादी हीच गहाळ वस्तू दिसणारी एकमेव जागा आहे। पुढे यादी अर्थपूर्ण होण्याचा क्रम आहे।

दोन असोसिएशन, दोन कामे

IKE SA नियंत्रण चॅनेल वाहून नेते: ओळख, किल्ल्या आणि नियंत्रण देवघेवीसाठीचे प्रस्ताव। चाइल्ड SA ESP संरक्षण वाहते, स्वतःच्या अल्गोरिदम आणि स्वतःच्या रहदारी निवडकांसह। प्रमाणीकरण आणि चाइल्ड SA तयार करणे सहसा एकत्र जाते, कारण पहिले चाइल्ड SA IKE_AUTH च्या आत बोलले जाते, आणि हेच एकत्रीकरण लोकांना या विभाजनाने आश्चर्यचकित करते।

हे तुम्हाला भेटणाऱ्या दोन अयशस्वी स्वरूपांचेही स्पष्टीकरण देते। सुरुवातीच्या देवघेवीत नाकारलेले चाइल्ड SA सहसा IKE SA लाही खाली घेते, त्यामुळे तुम्हाला कोणतेही प्रस्थापित नियंत्रण चॅनेल दिसत नाही। एकटे उभे असलेले IKE SA बहुतेक वेळा असे सूचित करते की पहिले चाइल्ड SA यशस्वी झाले आणि नंतरचा चाइल्ड SA तयार करण्याचा प्रयत्न अयशस्वी झाला, उदाहरणार्थ किल्ली नूतनीकरणात। वेळेच्या ठशांमुळे ती प्रकरणे कोणत्याही संरचना आढाव्यापेक्षा वेगाने वेगळी होतात।

कोणत्या स्तराने नकार दिला

चाइल्ड SA नाकारले जाते तेव्हा सूचना स्तराचे नाव सांगते। प्रस्ताव नाकारणे म्हणजे पक्ष अल्गोरिदमवर सहमत होऊ शकले नाहीत, बहुतेक वेळा कारण एक पक्ष वेगळा पूर्ण पुढचा गुप्तता गट किंवा दुसऱ्याला मान्य नसलेला सिफर मागतो। निवडक नाकारणे म्हणजे रहदारीचा संच सरळ नाकारला गेला, आणि हा व्याप्तीचा युक्तिवाद आहे, गुप्तलेखनाचा नाही।

काहीवेळा चाइल्ड SA नसणे हेच रचना आहे। चाइल्ड नसलेले IKE SA हे परिभाषित विस्तार आहे जे तिथे वापरले जाते जिथे डेटा असोसिएशन मागणीनुसार तयार केले पाहिजे, त्यामुळे अनुपस्थिती बरोबर आहे आणि जुळणारी रहदारी आल्यावर चाइल्ड SA दिसते। IKEv2 वर strongSwan च्या नोंदी मागणीची शैली आणि पहिले प्रकरण ठरवणार्या प्रस्ताव सेटिंग्ज दोन्ही व्यापतात।

दोषाचे निदान करण्यापूर्वी मागणीनुसार किंवा सापळा संरचना आहे का ते तपासा। चाइल्ड SA आळशीपणे तयार होत असतील तर निष्क्रिय अवस्थेत चाइल्ड SA नसणे ही अपेक्षित स्थिती आहे, आणि खरी चाचणी म्हणजे रहदारी एक वर आणते का हे। ही चाचणी आळशी रचना शांत अयशस्वीपासूनही वेगळी करते, कारण अयशस्वी निर्मिती ट्रिगरला केवळ निष्क्रिय न ठेवता उत्तराशिवाय ठेवते।

मग डेटा मार्गाबद्दल विचारा

चाइल्ड SA असेल तर पुढच्या प्रश्नाचे उत्तर काउंटर देतात। ip -s xfrm state प्रत्येक असोसिएशनसाठी पॅकेट आणि बाइटची गणना सांगते, आणि तुम्ही रहदारी निर्माण करत असताना काहीही वाहून न नेणारे चाइल्ड SA जुळणी किंवा मार्गनिर्देशनाकडे निर्देश करते गहाळ असोसिएशनकडे नाही। swanctl --list-sas त्या काउंटरच्या शेजारी चाइल्ड SA चे निवडक छापते, आणि पॅकेट स्वीकारलेल्या संचाच्या आत आहे हे तेच सिद्ध करते।

यशस्वी प्रमाणीकरण आणि अयशस्वी चाइल्ड SA देवघेव अहवालात वेगळी ठेवा। प्रमाणीकरण अयशस्वी झाले असे म्हणणारा अहवाल पुढच्या अभियंत्याला प्रमाणपत्र भांडाराकडे पाठवतो, आणि अचूक वाक्य खूपच लहान आहे: IKE SA वर आले, आणि या प्रवाहासाठी चाइल्ड SA कधीही स्वीकारले गेले नाही।

दोन्ही टोके जुळवा

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

चाइल्ड SA ची बोलणी दुरुस्त करा, नंतर इच्छित निवडकाच्या आतल्या रहदारीसह पुन्हा चाचणी करा। गहाळ वस्तू आता आहे हे सिद्ध करणारी हीच एकमेव चाचणी आहे, कारण निष्क्रिय अवस्थेत ताजी केलेली असोसिएशन यादी दुरुस्तीपूर्वी आणि नंतर सारखीच दिसू शकते।