IKEv2 हा एकच हँडशेक नाही: आधी IKE SA, नंतर प्रमाणीकरण आणि नंतर CHILD SA

गेटवेचे उत्तर पोहोच दर्शवते, ओळख नाही। IKE_SA_INIT, IKE_AUTH आणि पहिला CHILD SA अनुसरा, नंतर रहदारी सुरू होण्यापूर्वी काय खरे असले पाहिजे ते तपासा।

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

गैरसमज: गेटवेने उत्तर दिले तर तुम्ही जोडलेले आहात

पहिल्या संदेशाला मिळालेले उत्तर असे सिद्ध करते की टोक पोहोचण्यायोग्य आहे आणि बोलण्यास तयार आहे। खाते स्वीकारले गेले, प्रमाणपत्रांची साखळी वैध ठरली किंवा कोणतेही डेटा धोरण बसवले गेले हे ते सिद्ध करत नाही।

त्या अयशस्वी घटना नंतर होतात आणि वेगळी लक्षणे देतात। प्रमाणपत्र नाकारणे किंवा EAP अपयश पहिली देवघेव यशस्वी झाल्यानंतर येते, म्हणूनच UDP 500 वरचा ping आणि क्लायंटवरील हिरवे चिन्ह फार थोडे सांगतात।

IKE_SA_INIT: मापदंडांवर एकमत व्हा, ओळखीवर नाही

पहिली देवघेव IKE सुरक्षा संघटनेसाठीचे प्रस्ताव वाहून नेते: एन्क्रिप्शन आणि अखंडता अल्गोरिदम, छद्म-यादृच्छिक फंक्शन आणि Diffie-Hellman गट। दोन्ही बाजू nonce ची देवाणघेवाणही करतात, आणि प्रत्येक बाजू त्या मूल्यांतून तयार होणाऱ्या सामायिक रहस्यातून IKE SA साठीची किल्ली तयार करते। या देवघेवीत काहीही दुसरी बाजू कोण आहे हे ठरवत नाही। दोन्ही बाजू एकाच किल्ल्या गणू शकतात आणि एका प्रस्तावावर एकमत आहेत एवढेच ते ठरवते। कोणताही प्रस्ताव न आवडणारा प्रतिसादक येथे देवघेव नाकारतो, म्हणूनच आवृत्ती किंवा अल्गोरिदमची विसंगती सर्व्हर बंद असल्यासारखी दिसते।

या टप्प्यावर तयार झालेला IKE SA पुढील सर्व व्यवस्थापन देवघेवींचे संरक्षण करतो। ते त्याचे काम आहे, आणि तुमची पॅकेट संरक्षित करण्यापेक्षा वेगळे काम आहे।

IKE_AUTH: ओळख सिद्ध करा आणि मग पहिला CHILD SA तयार करा

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

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

दोन SA, दोन कामे

संघटनासंरक्षण करतेआयुष्याचे वर्तन
IKE SAव्यवस्थापन देवघेवी: किल्ली पुनर्निर्मिती, हटवणे, संरचना पेलोडस्वतःच्या वेळापत्रकानुसार पुनर्निर्मित होते; डेटा मार्ग बदल सहन करू शकतो
CHILD SAरहदारी निवडकांशी जुळणारी अनुप्रयोग रहदारीस्वतंत्रपणे पुनर्निर्मित होते, बऱ्याचदा अधिक वेळा

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

strongSwan वर, IKEv2 संरचना संदर्भ आणि swanctl --list-sas दोन्ही स्तर दर्शवतात, आणि ip xfrm state सह ip xfrm policy कर्नेलने प्रत्यक्षात काय बसवले ते दर्शवतात। या दोन दृश्यांची तुलना करणे हा वाटाघाटी पूर्ण झाली की फक्त पूर्ण झाल्यासारखी दिसली हे पाहण्याचा सर्वात वेगवान मार्ग आहे। डिमनने कर्नेलमध्ये स्थिती नसलेला CHILD SA सूचीबद्ध केला तर बसवणी शांतपणे अयशस्वी झाली। कर्नेलकडे डिमनला माहीत नसलेली स्थिती असेल तर तुम्ही पूर्वीच्या प्रयत्नाचा उरलेला भाग पाहत आहात।

बोगदा वर आल्यानंतरही काय खरे राहिले पाहिजे

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

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

संबंधित लेख