TCP पुनःप्रसारण बनाम IPsec रीप्ले ड्रॉप: हर परत पढ़ें

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

तीन काउंटर जो कभी एक ही घटना नहीं मापते

TCP पुनःप्रसारण का अंकन बताता है कि प्रेषक ने क्रम की एक श्रेणी फिर से तार पर रखी है। हानि इसका एक कारण है, और आपके पास जो कैप्चर है उसमें शायद मूल पैकेट या वह स्वीकृति ही नहीं है जो समय को समझाती। डुप्लिकेट ACK का अर्थ है प्राप्तकर्ता का TCP रिकवरी नियमों के अंतर्गत संचयी स्वीकृति दोहराना, जो न तो अनुप्रयोग की दोहरी लेखन है और न ही डेटा की दूसरी प्रति।

ESP अपने ही क्रम-स्थान में काम करता है। हर सुरक्षा संबद्धता अपने भेजे पैकेटों को क्रमांकित करती है, और प्राप्तकर्ता उन संख्याओं की एक खिड़की रखता है जिन्हें वह पहले स्वीकार कर चुका है, इसलिए दो बार आने वाला ESP पैकेट अकेले उन्हीं नियमों के आधार पर छोड़ दिया जाता है। इसलिए फिर से भेजा गया TCP खंड नई क्रम संख्या वाले नए ESP पैकेट में यात्रा करता है, जो दोनों परतों पर सही व्यवहार है। वही बाइट्स एक काउंटर में नई और दूसरे में पुरानी दिख सकती हैं, और दोनों में से कोई परत झूठ नहीं बोलती।

विश्लेषक क्या देख सकता है और क्या नहीं

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

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

उन संख्याओं के साथ विशेषज्ञ जानकारी पढ़ें, क्योंकि चेकसम और क्रम की चेतावनियाँ यह बदल देती हैं कि वे कितना महत्व रखती हैं। दो सेंसरों का मिला हुआ ट्रेस एक फ़्रेम को दो बार दिखा सकता है, और दोनों प्रतियों को गिनना ऐसी रिकवरी घटना गढ़ लेता है जो कभी नहीं हुई।

ESP काउंटर कर्नेल स्थिति में रहते हैं

ESP क्रम संख्याएँ TCP प्रवाह की नहीं, सुरक्षा संबद्धता की होती हैं, इसलिए गेटवे ही पूछने का स्थान है। स्थिति सूची प्रति संबद्धता पैकेट और त्रुटि काउंटर बताती है जिन्हें कोई कैप्चर पुनर्निर्मित नहीं कर सकता।

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 क्रम संख्या और उसे खपाने वाली रीप्ले-रोधी खिड़की को परिभाषित करता है, इसलिए कुछ भी गलत न होने पर भी काउंटर बढ़ता है। संबंधित TCP विसंगति के बिना एकरस बाहरी क्रम संख्याएँ पुनःप्रसारण के तूफ़ान की नहीं, किसी दूसरे प्रेषक या दोहराए गए मार्ग की ओर संकेत करती हैं। एन्क्रिप्टेड सुरंग का बाहरी कैप्चर सामान्यतः भीतरी TCP क्रम संख्याएँ छिपा देता है, इसलिए वह सिद्ध नहीं कर सकता कि भीतरी स्टैक ने क्या किया। सुरंग के भीतर केवल वहीं कैप्चर करें जहाँ नीति अनुमति देती है, और किसी असंबंधित चेतावनी को चुप कराने के लिए कभी रीप्ले-रोध बंद न करें।

जहाँ दृष्टि-बिंदु उत्तर बदलता है

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

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

संख्याओं को सही क्रम में पढ़ना

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

हर निष्कर्ष के लिए परत, काउंटर और दृष्टि-बिंदु दर्ज करें, और अगला पाठक तीन घटनाओं को एक काल्पनिक खराबी में नहीं मिलाएगा। इन्हीं तीन क्षेत्रों के साथ बढ़ाएँ और सुधार सामान्यतः पहले से ही आता है।