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

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

काउन्टरले मात्रा देखाउँछन्, खराबीको दिशा होइन

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 मा छ। यदि ठूला स्थानान्तरण मात्र अड्किन्छन् भने प्याकेटको आकार अलगै जाँच्नुहोस्।

सम्बन्धित लेखहरू