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 इंस्टेंस के बजाय वापसी मार्ग की ओर ले जाता है।