IKE SA प्रस्थापित, CHILD SA नाही: डेटा कुठे थांबतो

क्लायंट म्हणतो की प्रमाणीकरण झाले, IKE स्थिती निरोगी दिसते आणि पॅकेट काउंटर शून्यावरच राहतात। हे संयोजन विरोधाभास नाही: IKEv2 नियंत्रण संबंध आणि डेटा संबंध वेगळे ठेवते, आणि पहिला यशस्वी होऊ शकतो तर दुसरा कधीच वर येत नाही। पालक वाटाघाटी करतो; चाइल्ड रहदारी हाताळतो। बोगदा बंद आहे असे म्हणण्यापूर्वी दोन्ही स्तर वेगळे वाचा।

दोन SA काय करतात

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

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

कनेक्शन लेबल नाही, चाइल्ड नोंदी वाचा

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

पालक तुम्ही तपासत असलेल्या रहदारी संचापेक्षा वेगळा संच दाखवत असेल तर तुम्ही चुकीचे चाइल्ड वाचत आहात। ही सिलेक्टरची अडचण आहे, तुटलेला बोगदा नाही।

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

चाइल्ड अजिबात नसताना

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

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

चाइल्ड आहे पण काउंटर शून्यावरच असताना

चाइल्डच्या सिलेक्टरशी जुळणारी नवीन विनंती पाठवा। त्या धोरणाबाहेरील गंतव्यस्थानाकडे जाणारी विनंती कितीही यशस्वी दिसली तरी त्याचे काउंटर हलणार नाही।

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

अहवालात स्तर नावाने सांगा

अपयश निकाल नाही तर तीन क्षेत्रे म्हणून नोंदवा: अपयशी झालेला स्तर, तुम्ही तपासलेली देवघेव किंवा चाइल्ड, आणि तुमच्याकडील पुरावा। स्तर तीनपैकी एक आहे: पालक कधीच प्रस्थापित झाला नाही, चाइल्डची वाटाघाटी नाकारली गेली, किंवा चाइल्ड आहे आणि रहदारी त्याच्यापर्यंत पोहोचत नाही। पुरावा म्हणजे सिलेक्टर आणि काउंटरसह चाइल्डची ओळख, किंवा दोन्ही लॉगमधून उद्धृत केलेला नाकारलेला प्रस्ताव। ते वाचणारा कोणीही कोणता VPN म्हणताय याची विचारणा न करता महत्त्वाच्या देवघेवीकडे थेट जाऊ शकतो।

strongSwan IKEv2 दस्तऐवज ते स्तर स्थिती आउटपुटमध्ये कसे दिसतात हे दाखवते। फक्त पालकाचा सारांश नाही, तुम्ही तपासलेले चाइल्ड आउटपुट जोडा।