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 पोर्टला परवानगी देतो याची खात्री करा। होस्ट फायरवॉल नियम आणि क्लाउड सुरक्षा गट ही दोन स्वतंत्र दारे आहेत, आणि यापैकी कोणतेही असे पॅकेट टाकून देऊ शकते ज्याला दुसऱ्याने परवानगी दिली होती। दोन्ही कॉन्फिगरेशनमधील खऱ्या पोर्टशी तपासा, तुम्हाला आठवणाऱ्या पोर्टशी नाही।

पत्ता पोर्टइतकाच महत्त्वाचा आहे। विशिष्ट पत्त्यावर ऐकणारा सर्व्हर दुसऱ्या पत्त्यावर आलेल्या पॅकेटला उत्तर देणार नाही, आणि अनेक इंटरफेस असलेला होस्ट चाचणी तुमच्या हेतूच्या नसलेल्या इंटरफेसवर घेऊ शकतो।

प्रत्येक चाचणी ज्या प्रणालींची चाचणी करण्याचा तुम्हाला अधिकार आहे त्यांच्यातच ठेवा। उपयुक्त तुलना एका खऱ्या क्लायंट प्रयत्नाची आणि अपेक्षित सर्व्हर मार्गाची असते, तीच प्रदात्याच्या असलेल्या पत्त्यांची व्यापक झाडाझडती नाही।

स्कॅनचा निकाल प्रामाणिकपणे वाचणे

स्कॅन हा होस्ट अस्तित्वात आहे आणि पोर्टला मधल्या उपकरणाने स्पष्टपणे अडवले नाही हे तपासण्याचा स्वस्त मार्ग आहे। हा पडताळलेल्या प्रोटोकॉलसाठी पोहोचीचा पुरावा नाही, आणि नक्कीच कॉन्फिगरेशनची चाचणी नाही।

अधिक भक्कम पुरावा म्हणजे तुम्हाला खरोखर महत्त्वाच्या असलेल्या क्लायंटकडून पूर्ण झालेली हातमिळवणी, आणि त्यानंतर सुरुंग वापरून उत्तर मिळवणारी विनंती। हा क्रम एकाच वेळी किल्ल्या, अनुमत पत्ते, दोन्ही फायरवॉल आणि परतीचा मार्ग तपासतो।

जिथे खरा प्रयत्न अयशस्वी होतो, तिथेही बिघाड क्लायंटच्या काउंटरने आणि सर्व्हरच्या कॅप्चरनेच निदान करावा लागतो, दुसऱ्या चाचणीने नाही। प्रोटोकॉलचे वर्णन सांगते की पडताळणी न झालेल्या पॅकेटला उत्तर का मिळत नाही, आणि स्कॅनचा निकाल संदिग्ध असण्याचे हेच संपूर्ण कारण आहे।