VPN मा Ping हानि: प्रतिशत अघि Echo अनुरोधहरू समूहीकरण गर्नुहोस्

एउटा क्याप्चरमा छ Echo अनुरोध र तीन उत्तरहरू हुन्छन्, र कसैले टिकटमा 50 प्रतिशत प्याकेट हानि लेख्छ। त्यो संख्या क्याप्चरका लागि सत्य र सुरुङका लागि असत्य हुन सक्छ। ती छ अनुरोध दुई फरक डेलिभरी सम्झौतासहितका दुई फरक कुराकानीका हुन सक्छन्। बाँड्नु अघि तिनीहरूलाई समूहीकरण गर्नुहोस्, र अनुपात प्रतिवेदनको रोचक भाग रहन छोड्नेछ।

चरण 1: स्रोत र गन्तव्य अनुसार प्रवाहहरू छुट्याउनुहोस्

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

केही गन्नु अघि क्याप्चरलाई ती फिल्डहरूमा विभाजन गर्नुहोस्, र गन्तव्यलाई कुञ्जीको भागका रूपमा राख्नुहोस्। फरक पियरतर्फ जाने दुई प्रवाहले स्रोत साझा गरे पनि तुलनीय हुँदैनन्।

समूहहरूलाई तिनका संख्यासहित लेख्नुहोस्, किनकि अर्को चरणले कुन उत्तर कुन समूहको हो निर्धारण गर्छ। तीन अनुरोध र कुनै मिल्ने उत्तर नभएको समूह एउटा खोज हो। तीन अनुरोध र तीन उत्तर भएको समूह आधाररेखा हो।

चरण 2: पहिचानकर्ता र क्रममा मिलाउनुहोस्

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

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

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

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

चरण 3: एउटै सीमामा ट्युपलहरू तुलना गर्नुहोस्

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

गन्न सुरु गर्नु अघि सीमा निर्धारण गर्नुहोस्, र अर्को व्यक्तिले समूहीकरण पुनरुत्पादन गर्न सकोस् भनी प्रतिवेदनमा उल्लेख गर्नुहोस्। ग्राहकतर्फ एउटा क्याप्चर र सर्भरतर्फ अर्को दुई फरक सीमा हुन्। प्रत्येकले उत्तर कहाँ हरायो भन्ने फरक प्रश्नको उत्तर दिन्छ।

अनुवादित प्रोबको समूहले अनुवाद उपकरणको आफ्नै अवस्था पनि वंशानुगत रूपमा पाउँछ, जुन उत्तर कहिल्यै नआउनुको वास्तविक कारण हुन सक्छ। त्यसभन्दा परको मार्गलाई दोष दिनु अघि त्यो अवस्था जाँच्नुहोस्।

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

चरण 4: क्याप्चरले के प्रमाणित गर्न सक्छ र के सक्दैन भन्नुहोस्

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

गणनासँगै क्याप्चरको स्थान, फिल्टर अभिव्यक्ति र ड्रप काउन्टरहरू लेख्नुहोस्, किनकि ती बिना अनुपातको अडिट हुन सक्दैन। ती तीन लाइनले नै संख्यालाई पछि रक्षायोग्य बनाउँछन्।

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

जब प्रश्न कुनै विशेष मार्गले प्याकेट खसाल्छ कि भन्ने हुन्छ, स्पष्ट स्रोत ठेगानासहितको नियन्त्रित प्रोब मिश्रित ट्राफिकको निष्क्रिय गणनाभन्दा बलियो प्रमाण हो। त्यसलाई एउटै मेसिनबाट, एउटै समयमा, एउटै पियरमा पठाउनुहोस्। एउटा चल परिवर्तन गर्नुहोस् र तुलना टिकिरहन्छ।

समूहहरू र अर्को सीमा रिपोर्ट गर्नुहोस्

प्रतिवेदनमा तीन लाइन हुन्छन्: समूहको परिभाषा, प्रत्येक समूहभित्र मिलेका गणनाहरू, र तुलना गरिएको सीमा। तब पाठकले एउटा समूहले पूरै उत्तर दियो र अर्कोले दिएन भनी देख्न सक्छ, जसले अनियमित हानिको सट्टा मार्ग वा अनुमतितर्फ सङ्केत गर्छ।

समूहीकरण पुनरुत्पादनयोग्य बनाउन क्याप्चर फाइल र फिल्टर अभिव्यक्तिहरू संलग्न गर्नुहोस्। फाइल बिनाको सारांश दाबी हो, नतिजा होइन।

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

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