WireGuard कोई नया हैंडशेक नहीं दिखा रहा: पहले क्या जाँचें

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

परीक्षण वह अनुमत पैकेट है जो peer को उस गंतव्य की ओर ले जाना चाहिए। उस स्थिति स्क्रीन की बाकी हर चीज़ गतिविधि नहीं, इरादा बताती है।

निष्क्रिय इंटरफ़ेस के पास बताने को कुछ नहीं है

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

यदि दोनों तरफ़ काउंटर शून्य पर हैं, तो समस्या टनल के ऊपर है। इंटरफ़ेस तक कुछ नहीं पहुँचा जो कुछ शुरू करे।

वह ट्रैफ़िक ट्रिगर करें जिसे peer ले जाने की अनुमति रखता है

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

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

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

कुंजी जोड़ी और एंडपॉइंट की तुलना करें

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

एंडपॉइंट को भी वही जाँच चाहिए: होस्टनाम, पता, UDP पोर्ट और वहाँ पहुँचने के लिए इस्तेमाल किया गया परिवार। पुराना पता या गलत पोर्ट संदेश की जगह खामोशी देता है।

बाहरी UDP पथ पर नज़र रखें

हैंडशेक UDP के रूप में एंडपॉइंट की ओर जाता है, इसलिए बाहरी पथ को उसे ले जाना होगा। नीचे दिए कमांड जाँचते हैं कि श्रोता मौजूद है या नहीं, स्थानीय स्टैक ने डेटाग्राम भेजा या नहीं, और कौन सा एंडपॉइंट कॉन्फ़िगर है। ट्रैफ़िक ट्रिगर करते समय कैप्चर चलाएँ, उससे पहले नहीं।

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

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