दोहोरिएका IKE प्याकेट: हराएको संक्रमण खोज्नुहोस्

लगले उही IKE अनुरोध दुई पटक देखाउँछ, कसैले मोबाइल अपलिङ्कतर्फ देखाउँछ, र टिकट एउटा अनुमानसँग बन्द हुन्छ। त्यही अनुमान भ्रम हो: दोहोरिएको प्याकेट एउटा आदानप्रदानको अवलोकन हो, लिङ्कको निदान होइन। पुनःप्रेषण आफ्नै नियम भएको सामान्य व्यवहार हो, र प्रतिक्रिया ढिलो हुँदा स्वस्थ मार्गमा पनि देखिन्छ। इन्टरफेसलाई दोष दिनुअघि प्रतिक्रियाको पछि लाग्नुहोस्।

भ्रम: दोहोरिएको अनुरोधले एउटा लिङ्कमा हानि प्रमाणित गर्छ

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

दुई अपलिङ्कले अन्योल सुधार्नुको सट्टा बढाउँछन्। एउटा लग लाइनले एउटा इन्टरफेसको नाम लिन्छ, तर प्रतिक्रिया अर्कोबाट गएको हुन सक्छ, त्यसैले सन्देशमा भएको इन्टरफेसले प्याकेट कहाँ देखियो भन्ने बताउँछ, कुराकानीको आकार होइन। त्यसैले पहिलो प्रश्न कुन लिङ्क बिग्रिएको हो भन्ने होइन, कुन आदानप्रदान हेर्दै हुनुहुन्छ भन्ने हो।

पुनःप्रेषणले वास्तवमा के भन्छ

IKEv2 मा, पुनःप्रेषण यसरी काम गर्छ: प्रतिक्रिया नआएपछि अनुरोधकर्ताले अनुरोध दोहोर्याउँछ, र प्रतिक्रियाकर्ताले नयाँ गणना गर्नुको सट्टा आफ्नो सञ्चित प्रतिक्रिया फेरि पठाउन सक्छ। सन्देश पहिचानकर्ता त्यही आदानप्रदानका हुन्, र एउटै पहिचानकर्ता भएको दोहोरिएको अनुरोधलाई नयाँ प्रयास नभई प्रोटोकलको कामका रूपमा चिन्न सकिनु त्यसैको कारण हो। सुरुवाती प्रयासलाई सहसम्बन्ध गर्न प्रायः स्रोत ठेगाना वा सुरुवातकर्ता SPI भन्दा बढी चाहिन्छ, त्यसैले प्लेटफर्मको आफ्नै आदानप्रदान अभिलेख प्याकेट सूचीभन्दा राम्रो हुन्छ। IKEv1 फरक पहिचानकर्तासहित फरक नियम पछ्याउँछ, र पहिलो प्याकेट दोहोरिएकोबारे विक्रेताको चेतावनी सबै संस्करणमा एउटै अर्थ लिँदैन।

त्यसैले पुनःप्रेषणको टाइमस्ट्याम्पले टाइमर सकियो भन्छ। कुन हप ढिलो थियो भन्ने बताउँदैन, र अपरेटर दोषी छ भनी पक्कै भन्दैन। यी छुट्टाछुट्टै दाबी हुन्, र टिकटमा दोस्रो मात्र उपयोगी हुन्छ।

व्यावहारिक परिणाम भनेको निष्कर्षमा पुग्नुअघि आदानप्रदान अभिलेख गर्नु हो। स्थानीय प्राप्ति ठेगाना, नीतिले छानेको प्रतिक्रिया मार्ग, पियर टुपल र आदानप्रदान पहिचानकर्ता एउटै ठाउँमा लेख्नुहोस्, किनकि अभिलेख पछि पढ्दा ती प्रत्येकले फरक प्रश्नको उत्तर दिन्छ।

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

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

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

पहिलो हराएको संक्रमण खोज्नुहोस्

सुरुवातकर्ताबाट बाहिरतिर शृंखला हिँड्नुहोस् र प्रमाण नभएको पहिलो कडीमा रोकिनुहोस्। गेटवेले अनुरोध कहिल्यै लग गर्दैन भने गडबडी त्यसअघिको मार्गमा छ। गेटवेले उही अनुरोध बारम्बार लग गर्छ तर क्लाइन्टले कहिल्यै प्रतिक्रिया लग गर्दैन भने शङ्कास्पद फर्किने दिशा हो: स्रोत ठेगाना, अनुवाद र तपाईंले नियन्त्रण गर्ने हरेक सीमामा फिल्टरिङ। प्रतिक्रिया आए पनि क्लाइन्ट अघि नबढ्ने हो भने प्रश्नले यातायात छोडेर नीति वा अवस्था बनेको छ।

तुलना गर्दा पियर र प्रोटोकल स्थिर राख्नुहोस्, र ढिलाइ, हानि, नीति र अवस्थाले प्रत्येकले फरक समयरेखा बनाउँछन् भन्ने सम्झनुहोस्। मोबाइल सञ्जाल स्वतः कारण होइन, र स्थिर लाइन हरेक आवश्यकताका लागि स्वतः पर्याप्त भरपर्दो पनि होइन। आदानप्रदान जीवित रहँदा दुवै दिशा क्याप्चर गर्नुहोस्:

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

टाढाको छेउअघि पहुँच रोकिँदा, अभिलेखले कहाँ रोकिन्छ भन्यो भने पनि मद्दत गर्छ। सुरुवातकर्तामा मात्र क्याप्चर गर्दा अनुरोध बाहिर जाँदै छ र प्रतिक्रिया आउँदैन भन्ने देखाउन सकिन्छ, जसले गडबडीलाई त्यो हुकपछिको सबैमा सीमित गर्छ, कुन हपले खसाल्यो भन्ने थाहा भएको नाटक नगरी। टाढाका कडी अज्ञात भनी चिन्ह लगाउनुहोस् र पहुँच भएको अर्को व्यक्तिलाई ती भर्न दिनुहोस्। यसरी लेख्दा अभिलेख इमानदार रहन्छ र अझै छोटो पनि।

केही बदल्नुअघि तुलना गर्नुहोस्। उही पियरतर्फ उही प्रोटोकलमा उही अनुरोध दोहोर्याउँदा चर गणनीय रहन्छन्, तर क्याप्चरबीच रिसेट, कुञ्जी नवीकरण वा नीति सम्पादनले तुलना नष्ट गर्छ। परिवर्तन अपरिहार्य भए ठीक पछि फेरि क्याप्चर गर्नुहोस्, ताकि अघि र पछि अझै उही आदानप्रदान वर्णन गरून्।

उपयोगी प्रतिवेदन के भन्छ

कार्ययोग्य प्रतिवेदनले एउटा अनुरोधलाई त्यसको प्रतिक्रियासँग जोड्छ र पछाडि प्रमाण नभएको पहिलो चरणको नाम लिन्छ। त्यो वाक्य एक हप्तापछि त्यहाँ नभएको इन्जिनियरले पढ्दा पनि टिक्छ, र अर्को व्यक्तिलाई संदिग्ध नभई सुरु गर्ने ठाउँ दिन्छ।

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

भ्रम भनेको एउटा दोहोरोले अपरेटर दोषी छ भनी प्रमाणित गर्छ। वास्तविकता भनेको एउटा दोहोरोले टाइमर सकियो भनी प्रमाणित गर्छ, र उत्तर प्रतिक्रियाकै मार्गमा बाँच्छ।