TCP पुनःप्रसारण र IPsec रिप्ले खारेजी: हरेक तह पढ्नुहोस्
पुनःप्रसारण झन्डा, डुप्लिकेट ACK र ESP रिप्ले खारेजी गणकले फरक-फरक तहमा फरक-फरक घटना मापन गर्छन्। हरेक गणक त्यो उत्पन्न हुने तहमै पढ्नुहोस्।
तीन फरक औजारले तीन फरक डुप्लिकेट रिपोर्ट गर्छन्, र तीमध्ये एउटा मात्र यस्तो नेटवर्क घटना हो जसमा तपाईं कारबाही गर्न सक्नुहुन्छ। 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 टिप्पणीमा टेकेको सुरुङबारे भनाइ अनुमान हो।
हरेक भेट्टिएको कुराका लागि तह, गणक र अवलोकन बिन्दु लेख्नुहोस्, र अर्को पाठकले तीन घटनालाई एउटै काल्पनिक खराबीमा मिसाउने छैन। यी तीन क्षेत्रसहित बढाउनुहोस्, र सुधार सामान्यतया पहिलोबाटै आउँछ।