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

काम छोटा करने वाली तुलना उस अनुरोध से है जो कभी टनल से बाहर नहीं गया और उस जवाब से जो कभी वापस नहीं आया। सही इंटरफ़ेस पर एक कैप्चर दोनों के बीच फ़ैसला कर देता है।

काउंटर मात्रा बताते हैं, खराबी की दिशा नहीं

WireGuard के काउंटर दर्ज करते हैं कि इंटरफ़ेस ने पीयर को क्या दिया और उससे क्या पाया। वे यह नहीं बताते कि कौन-सा गंतव्य, कौन-सा पीयर या अदला-बदली का कौन-सा आधा हिस्सा विफल हुआ। बैकग्राउंड ट्रैफ़िक कुल संख्याओं को और कम जानकारीपूर्ण बना देता है, क्योंकि कुछ बाइट्स कीपअलाइव या असंबंधित फ़्लो हो सकते हैं। इन्हें इस संकेत के रूप में पढ़ें कि इंटरफ़ेस सक्रिय है, फिर इन्हें सबूत मानना बंद कर दें।

पहली उपयोगी बात यह है कि हैंडशेक मौजूदा है या नहीं। इसके बिना इस पीयर के लिए कुछ भी एन्क्रिप्ट नहीं हुआ और रिसीव काउंटर के हिलने की कोई वजह नहीं है।

पीयर का चयन या जवाब का रास्ता: दो व्याख्याएँ

पहली व्याख्या यह है कि पैकेट कभी इच्छित पीयर तक पहुँचा ही नहीं, क्योंकि रूट कहीं और इशारा कर रहा था या पीयर के अनुमत प्रीफ़िक्स गंतव्य को नहीं ढकते थे। दूसरी यह है कि पैकेट पहुँच गया और जवाब वापस नहीं आ सका, जो दूर के सिरे पर रूटिंग की समस्या है। तालिका दोनों को इस आधार पर अलग करती है कि आप हर बिंदु पर क्या देखेंगे।

ObservationPoints to
No handshake while transmit climbsPeer selection or endpoint
Handshake current, request visible on the serverReply path or far-side route
Request never visible on the serverAllowed prefixes or local route
Both packets visible, nothing reaches the clientReturn filter or translation

तालिका ऊपर से पढ़ें। हैंडशेक न हो तो यह आपको कुंजियों, एंडपॉइंट और बाहरी रास्ते की ओर भेजता है, क्योंकि अभी जाँचने के लिए और कुछ नहीं है। सर्वर पर अनुरोध दिखाई देने के साथ मौजूदा हैंडशेक समस्या को वापसी की दिशा में ले जाता है, जहाँ गंतव्य की अपनी रूट तालिका फ़ैसला करती है। जो अनुरोध सर्वर पर कभी दिखाई ही नहीं देता, वह चयन की समस्या है, और दोनों पीयर के अनुमत प्रीफ़िक्स सबसे पहले तुलना करने योग्य चीज़ हैं।

इन चार पंक्तियों में से दो क्लाइंट पर और दो सर्वर पर ठीक होती हैं। यह जानना कि आप किस जोड़ी में हैं, काम का बड़ा हिस्सा है।

जवाब कहाँ गायब होते हैं

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

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

एक गंतव्य को शुरू से अंत तक जाँचें

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

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

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

अगर नाम विफल हों जबकि कोई अनुमत पता काम करता हो, तो जवाब टनल में नहीं, DNS में है। अगर सिर्फ़ बड़े स्थानांतरण अटकें, तो पैकेट का आकार अलग से जाँचें।

संबंधित लेख