UDP स्कैन कहता है फ़िल्टर्ड: क्या आपका WireGuard पीयर वाकई डाउन है?

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

इसके बजाय क्लाइंट से बाहर की ओर काम करें, और स्कैन को कई कमज़ोर डेटा बिंदुओं में से एक मानें।

स्कैनर क्या देख सकता है और क्या नहीं

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

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

उसी पोर्ट नंबर पर TCP परीक्षण किसी संबंधित चीज़ की जाँच नहीं करता। यह किसी और श्रोता को चलाता है जो शायद मौजूद ही न हो, और उसका इनकार UDP के बारे में कुछ नहीं कहता।

इसलिए खुली फ़िल्टर्ड अवस्थाएँ आपके सर्वर की तुलना में स्कैनर की अनिश्चितता को अधिक सटीकता से बताती हैं।

असली क्लाइंट को प्रोफ़ाइल से अंदर तक चलिए

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

फिर तीसरी जगह से अलग स्कैन चलाने के बजाय, एक अधिकृत कोशिश के दौरान सर्वर की तरफ़ देखें:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

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

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

जब आप सर्वर का प्रबंधन करें तो वहीं सहसंबंध जोड़ें

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

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

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

स्कैन नतीजे को ईमानदारी से पढ़ना

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

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

जहाँ असली कोशिश नाकाम होती है, वहाँ भी खराबी का पता क्लाइंट के काउंटरों और सर्वर के कैप्चर से ही लगाना होगा, किसी और जाँच से नहीं। प्रोटोकॉल का विवरण बताता है कि अप्रमाणित पैकेट को जवाब क्यों नहीं मिलता, और स्कैन नतीजे के अस्पष्ट होने की पूरी वजह यही है।