डुप्लिकेट IKE पैकेट: गुम हुआ संक्रमण खोजें

लॉग वही IKE अनुरोध दो बार दिखाता है, कोई मोबाइल अपलिंक की ओर इशारा करता है, और टिकट एक अनुमान के साथ बंद हो जाता है। वही अनुमान भ्रम है: दोहराया गया पैकेट एक आदान-प्रदान के बारे में अवलोकन है, लिंक का निदान नहीं। पुनःप्रेषण अपने नियमों वाला सामान्य व्यवहार है, और उत्तर धीमा होने पर यह स्वस्थ मार्गों पर भी दिखता है। किसी इंटरफ़ेस को दोष देने से पहले उत्तर का पीछा करें।

भ्रम: दोहराया गया अनुरोध एक लिंक पर हानि सिद्ध करता है

दो अलग चीज़ें डुप्लिकेट बनाती हैं और उनमें से कोई दोषी का नाम नहीं लेती। अनुरोधकर्ता अनुरोध दोहरा सकता है क्योंकि उसे कोई उत्तर नहीं मिला, या कैप्चर बिंदु स्टैक से जुड़े होने की जगह के कारण वही पैकेट दो बार दिखा सकता है। जो टैप एक ही होस्ट पर प्रवेश और निकास देखता है, वह एक पैकेट को खुशी से दो लिख देगा, और वह लॉग पढ़ने वाले ऑपरेटर के पास आदान-प्रदान पहचानकर्ताओं के बिना अंतर बताने का कोई तरीका नहीं है। जब तक आप न कह सकें कि दोनों में से कौन सा आपके हाथ में है, डुप्लिकेट को टाइमर घटना मानें।

दो अपलिंक भ्रम को सुधारने की बजाय बढ़ा देते हैं। एक लॉग पंक्ति एक इंटरफ़ेस का नाम लेती है, जबकि उत्तर दूसरे से निकला हो सकता है, इसलिए संदेश में इंटरफ़ेस बताता है कि पैकेट कहाँ देखा गया, बातचीत का आकार नहीं। इसीलिए पहला प्रश्न यह है कि आप कौन सा आदान-प्रदान देख रहे हैं, यह नहीं कि कौन सा लिंक खराब है।

पुनःप्रेषण वास्तव में आपको क्या बताता है

IKEv2 में, पुनःप्रेषण इस तरह काम करता है: उत्तर न आने पर अनुरोधकर्ता अनुरोध दोहराता है, और उत्तरदाता नया गणना करने के बजाय अपना कैश किया हुआ उत्तर फिर भेज सकता है। संदेश पहचानकर्ता उसी आदान-प्रदान के होते हैं, और यही समान पहचानकर्ता वाले दोहराए गए अनुरोध को नया प्रयास नहीं बल्कि प्रोटोकॉल का काम पहचानने योग्य बनाता है। प्रारंभिक प्रयास को सहसंबंध के लिए अक्सर स्रोत पते या आरंभकर्ता SPI से अधिक चाहिए, इसलिए प्लेटफ़ॉर्म का अपना आदान-प्रदान रिकॉर्ड पैकेट सूची से बेहतर है। IKEv1 भिन्न पहचानकर्ताओं के साथ भिन्न नियमों का पालन करता है, और पहले पैकेट के डुप्लिकेट के बारे में विक्रेता की चेतावनी सभी संस्करणों में एक जैसी नहीं होती।

इसलिए पुनःप्रेषण का टाइमस्टैम्प कहता है कि टाइमर समाप्त हो गया। यह नहीं कहता कि कौन सा हॉप धीमा था, और निश्चित रूप से यह नहीं कहता कि ऑपरेटर दोषी है। ये अलग-अलग दावे हैं, और टिकट में केवल दूसरा ही उपयोगी है।

व्यावहारिक परिणाम यह है कि निष्कर्ष निकालने से पहले आदान-प्रदान दर्ज करें। स्थानीय प्राप्ति पता, नीति द्वारा चुना गया उत्तर मार्ग, पीयर टपल और आदान-प्रदान पहचानकर्ता एक ही जगह लिखें, क्योंकि रिकॉर्ड बाद में पढ़े जाने पर इनमें से हर एक अलग प्रश्न का उत्तर देता है।

एक श्रृंखला के रूप में चार अवलोकन बिंदु

आदान-प्रदान को देखने के चार अलग स्थानों के बजाय श्रृंखला की चार कड़ियों के रूप में सोचें। कड़ी साक्ष्य रखती है या अज्ञात रहती है, और श्रृंखला उतनी ही सूचनाप्रद है जितनी उसकी सबसे कमजोर दर्ज कड़ी। नीचे दी गई तालिका सूची है: हर स्थिति क्या सिद्ध कर सकती है और क्या अछूता छोड़ देती है।

श्रृंखला केवल वहाँ भरें जहाँ आपकी पहुँच है, और बाकी को अनुमान लगाने के बजाय अज्ञात चिह्नित करें। एक मशीन पर पैकेट दर्ज करने वाला हुक दूर की मशीन को क्या मिला, इस बारे में कुछ नहीं कहता, और यह कहने वाली लॉग पंक्ति कि अनुरोध देखा गया, इस बात का साक्ष्य नहीं कि कभी उत्तर निकला। ईमानदार अंतराल अनुमानों से बने पूर्ण दिखने वाले रिकॉर्ड से अधिक उपयोगी हैं।

पहला गुम संक्रमण खोजें

आरंभकर्ता से बाहर की ओर श्रृंखला पर चलें और साक्ष्य रहित पहली कड़ी पर रुकें। यदि गेटवे कभी अनुरोध दर्ज नहीं करता, तो दोष उससे पहले के मार्ग पर है। जब गेटवे वही अनुरोध बार-बार दर्ज करता है जबकि क्लाइंट कभी उत्तर दर्ज नहीं करता, तो वापसी दिशा संदिग्ध है: स्रोत पता, अनुवाद और आपके नियंत्रण वाली हर सीमा पर फ़िल्टरिंग। यदि उत्तर आता है और क्लाइंट फिर भी आगे नहीं बढ़ता, तो प्रश्न परिवहन छोड़कर नीति या स्थिति बन गया है।

तुलना करते समय पीयर और प्रोटोकॉल स्थिर रखें, और याद रखें कि विलंब, हानि, नीति और स्थिति में से हर एक अलग समयरेखा बनाता है। मोबाइल नेटवर्क अपने आप कारण नहीं होता, और स्थिर लाइन हर आवश्यकता के लिए अपने आप पर्याप्त विश्वसनीय नहीं होती। आदान-प्रदान जीवित रहते समय दोनों दिशाएँ कैप्चर करें:

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

जब दूर के सिरे से पहले पहुँच समाप्त हो जाती है, तो रिकॉर्ड अभी भी मदद करता है यदि वह बताता है कि कहाँ रुकता है। केवल आरंभकर्ता पर कैप्चर दिखा सकता है कि अनुरोध निकल रहा है और कोई उत्तर नहीं आ रहा, जो दोष को उस हुक के बाद की हर चीज़ तक सीमित करता है, यह जताए बिना कि किस हॉप ने उसे गिराया। दूर की कड़ियों को अज्ञात चिह्नित करें और पहुँच वाले अगले व्यक्ति को उन्हें भरने दें। इस तरह लिखा गया रिकॉर्ड ईमानदार और फिर भी संक्षिप्त रहता है।

कुछ भी बदलने से पहले तुलना करें। उसी पीयर के प्रति उसी प्रोटोकॉल के साथ वही अनुरोध दोहराना चरों को गणनीय रखता है, जबकि कैप्चर के बीच रीसेट, कुंजी नवीनीकरण या नीति संपादन तुलना को नष्ट कर देता है। यदि बदलाव अपरिहार्य है, तो ठीक उसके बाद फिर कैप्चर करें ताकि पहले और बाद अभी भी उसी आदान-प्रदान का वर्णन करें।

एक उपयोगी रिपोर्ट क्या कहती है

कार्रवाई योग्य रिपोर्ट एक अनुरोध को उसके उत्तर के साथ जोड़ती है और उस पहले कदम का नाम लेती है जिसके पीछे कोई साक्ष्य नहीं है। वह वाक्य एक सप्ताह बाद ऐसे इंजीनियर द्वारा पढ़े जाने पर भी टिकता है जो वहाँ नहीं था, और अगले व्यक्ति को संदिग्ध के बजाय शुरुआत की जगह देता है।

केवल पुनःप्रेषण सिद्धांत जाँचने के लिए पहचान जाँच कभी कमजोर न करें और न ही अनुमत प्रोटोकॉल समूह को चौड़ा करें। किसी भी रीसेट से पहले मूल पैकेट और घटना रिकॉर्ड सहेजें, क्योंकि रीसेट ठीक उसी सामग्री को नष्ट करता है जिसे आप एकत्र करने वाले थे और उस समय को मिटा देता है जो दिखाता था कि आदान-प्रदान कहाँ अटका।

भ्रम यह है कि एक डुप्लिकेट सिद्ध करता है कि ऑपरेटर दोषी है। वास्तविकता यह है कि एक डुप्लिकेट सिद्ध करता है कि टाइमर समाप्त हो गया, और उत्तर उत्तर के मार्ग पर रहता है।