डुप्लिकेट IKE पॅकेट: हरवलेले संक्रमण शोधा

लॉग त्याच IKE विनंती दोनदा दाखवतो, कोणीतरी मोबाइल अपलिंककडे बोट दाखवतो, आणि तिकीट एका अंदाजाने बंद होते. तोच अंदाज हा गैरसमज आहे: पुनरावृत्ती झालेले पॅकेट एका देवाणघेवाणीबद्दलचे निरीक्षण आहे, दुव्याचे निदान नाही. पुनर्प्रसारण हे स्वतःच्या नियमांसह सामान्य वर्तन आहे, आणि प्रतिसाद मंद असताना निरोगी मार्गांवरही ते दिसते. इंटरफेसला दोष देण्यापूर्वी प्रतिसादाचा मागोवा घ्या.

गैरसमज: पुनरावृत्ती झालेली विनंती एका दुव्यावरील हानी सिद्ध करते

दोन वेगळ्या गोष्टी डुप्लिकेट तयार करतात आणि दोन्हीपैकी कोणीही दोषीचे नाव घेत नाही. विनंतीकर्ता प्रतिसाद न मिळाल्यामुळे विनंतीची पुनरावृत्ती करू शकतो, किंवा स्टॅकला कुठे जोडले आहे यामुळे कॅप्चर बिंदू तेच पॅकेट दोनदा दाखवू शकतो. एकाच होस्टवर प्रवेश आणि निर्गम पाहणारा टॅप एक पॅकेट आनंदाने दोन म्हणून नोंदवेल, आणि तो लॉग वाचणाऱ्या ऑपरेटरला देवाणघेवाण ओळखकर्त्यांशिवाय फरक ओळखण्याचा मार्ग नाही. दोन्हींपैकी कोणते हातात आहे हे सांगता येईपर्यंत डुप्लिकेटला टाइमर घटना माना.

दोन अपलिंक गोंधळ सुधारण्याऐवजी वाढवतात. एक लॉग ओळ एका इंटरफेसचे नाव घेते, तर प्रतिसाद दुसऱ्यातून गेलेला असू शकतो, म्हणून संदेशातील इंटरफेस पॅकेट कुठे दिसले हे सांगतो, संभाषणाचा आकार नाही. म्हणूनच पहिला प्रश्न कोणता दुवा सदोष आहे हा नाही, तर कोणती देवाणघेवाण पाहत आहात हा आहे.

पुनर्प्रसारण प्रत्यक्षात काय सांगते

IKEv2 मध्ये, पुनर्प्रसारण असे कार्य करते: प्रतिसाद न आल्यास विनंतीकर्ता विनंतीची पुनरावृत्ती करतो, आणि प्रतिसादकर्ता नवीन गणना करण्याऐवजी आपला साठवलेला प्रतिसाद पुन्हा पाठवू शकतो. संदेश ओळखकर्ते त्या देवाणघेवाणीचे असतात, आणि त्यामुळेच समान ओळखकर्त्यासह पुनरावृत्ती झालेली विनंती नवीन प्रयत्न नव्हे तर प्रोटोकॉलचे कार्य म्हणून ओळखता येते. प्रारंभिक प्रयत्नाला सहसंबंधासाठी स्रोत पत्ता किंवा आरंभकर्ता SPI पेक्षा अधिक लागते, म्हणून प्लॅटफॉर्मचा स्वतःचा देवाणघेवाण नोंद पॅकेट यादीपेक्षा चांगला आहे. IKEv1 वेगळ्या ओळखकर्त्यांसह वेगळे नियम पाळतो, आणि पहिल्या पॅकेटच्या डुप्लिकेटबद्दल विक्रेत्याचा इशारा सर्व आवृत्त्यांमध्ये एकच अर्थ देत नाही.

त्यामुळे पुनर्प्रसारणाचा टाइमस्टॅम्प सांगतो की टाइमर संपला. कोणता हॉप मंद होता हे सांगत नाही, आणि ऑपरेटर दोषी आहे असे निश्चितच सांगत नाही. हे वेगळे दावे आहेत, आणि तिकिटात फक्त दुसरा उपयुक्त आहे.

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

एक साखळी म्हणून चार निरीक्षण बिंदू

देवाणघेवाण पाहण्याच्या चार वेगळ्या जागा म्हणून नव्हे, तर साखळीतील चार दुवे म्हणून विचार करा. दुवा पुरावा ठेवतो किंवा अज्ञात राहतो, आणि साखळी तिच्या सर्वात कमकुवत नोंदवलेल्या दुव्याइतकीच माहितीपूर्ण असते. खालील तक्ता यादी आहे: प्रत्येक स्थान काय सिद्ध करू शकते आणि काय अस्पर्श ठेवते.

साखळी फक्त जिथे प्रवेश आहे तिथे भरा, आणि उर्वरित अनुमान करण्याऐवजी अज्ञात म्हणून चिन्हांकित करा. एका मशीनवर पॅकेट नोंदवणारा हुक दूरच्या मशीनला काय मिळाले याबद्दल काहीही सांगत नाही, आणि विनंती दिसली अशी लॉग ओळ हा कधीही प्रतिसाद गेला याचा पुरावा नाही. प्रामाणिक अंतर अनुमानांनी बांधलेल्या पूर्ण दिसणाऱ्या नोंदीपेक्षा अधिक उपयुक्त आहेत.

पहिले हरवलेले संक्रमण शोधा

आरंभकर्त्यापासून बाहेरच्या दिशेने साखळी चाला आणि पुरावा नसलेल्या पहिल्या दुव्यावर थांबा. गेटवेने विनंती कधीही नोंदवली नाही तर दोष त्याच्या आधीच्या मार्गावर आहे. गेटवे तीच विनंती वारंवार नोंदवतो पण क्लायंट कधीही प्रतिसाद नोंदवत नाही, तेव्हा परतीची दिशा संशयास्पद आहे: स्रोत पत्ता, भाषांतर आणि तुम्ही नियंत्रित करता त्या प्रत्येक सीमेवरील गाळणी. प्रतिसाद आला तरी क्लायंट पुढे सरकत नसेल, तर प्रश्नाने वाहतूक सोडली आहे आणि तो धोरण किंवा स्थिती झाला आहे.

तुलना करताना पीअर आणि प्रोटोकॉल स्थिर ठेवा, आणि विलंब, हानी, धोरण व स्थिती यापैकी प्रत्येक वेगळी कालरेषा तयार करते हे लक्षात ठेवा. मोबाइल नेटवर्क आपोआप कारण नसते, आणि स्थिर लाईन प्रत्येक गरजेसाठी आपोआप पुरेसा विश्वासार्ह नसते. देवाणघेवाण जिवंत असताना दोन्ही दिशा कॅप्चर करा:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

दूरच्या टोकापूर्वी प्रवेश थांबल्यास, नोंद कुठे थांबते हे सांगत असेल तर ती अजूनही मदत करते. फक्त आरंभकर्त्यावर कॅप्चर केल्यास विनंती बाहेर जाते आणि प्रतिसाद येत नाही हे दाखवता येते, ज्यामुळे दोष त्या हुकनंतरच्या सर्व गोष्टींपर्यंत मर्यादित होतो, कोणत्या हॉपने ते टाकले हे माहीत असल्याचे नाटक न करता. दूरचे दुवे अज्ञात म्हणून चिन्हांकित करा आणि प्रवेश असलेल्या पुढील व्यक्तीला ते भरू द्या. असे लिहिल्यास नोंद प्रामाणिक राहते आणि तरीही संक्षिप्त राहते.

काहीही बदलण्यापूर्वी तुलना करा. त्याच पीअरकडे त्याच प्रोटोकॉलसह त्याच विनंतीची पुनरावृत्ती केल्यास चल गणनीय राहतात, तर कॅप्चरमधील रीसेट, की नूतनीकरण किंवा धोरण संपादन तुलना नष्ट करते. बदल टाळता येत नसेल, तर लगेच नंतर पुन्हा कॅप्चर करा जेणेकरून आधी आणि नंतर अजूनही त्याच देवाणघेवाणीचे वर्णन करतील.

उपयुक्त अहवाल काय सांगतो

कृतीयोग्य अहवाल एका विनंतीला तिच्या प्रतिसादाशी जोडतो आणि मागे पुरावा नसलेल्या पहिल्या पायरीचे नाव घेतो. ते वाक्य आठवड्यानंतर तिथे नसलेल्या अभियंत्याने वाचल्यावरही टिकते, आणि पुढील व्यक्तीला संशयिताऐवजी सुरुवातीची जागा देते.

फक्त पुनर्प्रसारण सिद्धांत तपासण्यासाठी ओळख तपासण्या कधीही कमकुवत करू नका किंवा अनुमत प्रोटोकॉल संच रुंदावू नका. कोणत्याही रीसेटपूर्वी मूळ पॅकेट आणि घटना नोंदी जतन करा, कारण रीसेट नेमकी जी सामग्री तुम्ही गोळा करणार होते ती नष्ट करते आणि देवाणघेवाण कुठे अडकली हे दाखवणारी वेळ पुसून टाकते.

गैरसमज असा आहे की एक डुप्लिकेट ऑपरेटरचा दोष सिद्ध करतो. वास्तव असे आहे की एक डुप्लिकेट टाइमर संपला हे सिद्ध करतो, आणि उत्तर उत्तरेच्या मार्गावरच राहते.