UDP VPN पोर्ट स्कैन पर शांत? ऐसा क्यों होता है
WireGuard और कठोर OpenVPN प्रमाणीकरण में विफल डेटाग्राम को बिना उत्तर दिए छोड़ देते हैं। स्कैनर की ओर से चुप्पी अपेक्षित व्यवहार है, बंद पोर्ट नहीं।
आप VPN पोर्ट स्कैन करते हैं, कोई उत्तर नहीं मिलता और निष्कर्ष निकालते हैं कि सेवा बंद है या फ़ायरवॉल बंद है। WireGuard में और अपना प्रमाणीकरण ले जाने वाले OpenVPN नियंत्रण चैनलों में यह निष्कर्ष लागू नहीं होता। वैध प्रमाणीकरण सामग्री के बिना डेटाग्राम बिना किसी उत्तर के छोड़ दिया जाता है, इसलिए बाहर से स्वस्थ सेवा इसी तरह चुप दिखती है। सुरंग गलत होने से पहले जाँच ही गलत है।
चुप्पी ही प्रोटोकॉल है, खराबी नहीं
UDP में कनेक्शन स्थापना नहीं होती, इसलिए कोई SYN नहीं है और ऐसी कोई स्वीकृति नहीं है जो स्कैनर को खुला पोर्ट और फ़िल्टर किया गया पोर्ट अलग करने दे। जाँच एक अलग डेटाग्राम के रूप में आती है और सेवा जाँचती है कि यह अपेक्षित प्रोटोकॉल से मेल खाती है या नहीं। मेल न खाने पर पैकेट छोड़ दिया जाता है, और छोड़ना दस्तावेज़ी व्यवहार है, खराबी नहीं।
WireGuard अपने हैंडशेक संदेशों को क्रिप्टोग्राफ़िक रूप से सत्यापित करता है और विफल होने वाली हर चीज़ को अनदेखा करता है। OpenVPN tls-auth या tls-crypt के साथ अपने नियंत्रण चैनल के लिए वही करता है। दोनों स्थितियों में मनमाना पेलोड कभी उपयोगकर्ता-मुखी चरण तक नहीं पहुँचता, इसलिए उत्तर देने के लिए कुछ नहीं है और लौटाने के लिए कोई त्रुटि नहीं है।
TCP होता तो बंद पोर्ट से आपको रीसेट मिलता। UDP आपको अस्पष्टता में छोड़ देता है, जिसे स्कैनर अनुमान लगाने के बजाय खुला या फ़िल्टर किया गया छापकर सुलझाते हैं।
स्कैनर क्या निष्कर्ष निकाल सकता है और क्या नहीं
स्कैन परिणाम उतना ही जानकारीपूर्ण है जितना उसने भेजा गया पेलोड। संभावित अवलोकनों को इस क्रम में लगाएँ कि हर एक वास्तव में किसका समर्थन करता है:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
सूची में एकमात्र सकारात्मक परीक्षण के रूप में तीसरी पंक्ति पढ़ें। इसमें असली प्रोफ़ाइल, असली कुंजी और सही एंडपॉइंट चाहिए, और सामान्य स्कैनर के पास ठीक यही नहीं होता।
पथ के दोनों सिरों को देखें
आप जिस सर्वर का प्रबंधन करते हैं, उसके लिए कोई निष्कर्ष निकालने से पहले इंटरफ़ेस पर कैप्चर करें, फिर सेवा से पूछें कि उसने क्या देखा। दोनों कमांड के लिए गेटवे पर root चाहिए:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showअगर इंटरफ़ेस पर कोई पैकेट नहीं दिखता, तो सेवा के कुछ देखने से पहले ही पथ ने उसे छोड़ दिया, और अगला पड़ाव राउटिंग और फ़िल्टरिंग है। अगर पैकेट आते हैं पर कोई हैंडशेक पूरा नहीं होता, तो सेवा पहुँच योग्य है और असंगति कुंजियों, एंडपॉइंट कॉन्फ़िगरेशन या प्रोटोकॉल संस्करण में है। वही तुलना उस प्रश्न का उत्तर देती है जो स्कैनर नहीं दे सका। इसे तब चलाएँ जब कोई असली क्लाइंट जुड़ने की कोशिश कर रहा हो, तब नहीं जब स्कैनर खुद को दोहरा रहा हो।
परीक्षण बदलें, सुरक्षा नहीं
लुभावना शॉर्टकट यह है कि नियंत्रण चैनल की सुरक्षा बंद कर दें ताकि निदान को उत्तर मिले। यह वास्तविक सुरक्षा गुण के बदले में सुंदर स्कैन परिणाम देता है, और यह गलत दिशा है। इसके बजाय अनुमोदित नेटवर्क से वैध प्रोफ़ाइल इस्तेमाल करें और एंडपॉइंट व समय नोट करें ताकि तुलना दोहराई जा सके।
सबसे उपयोगी परीक्षण विभेदक है: वही प्रोफ़ाइल एक ऐसे पथ पर जो काम करता है और उस पथ पर जो नहीं करता। अगर काम करने वाला पथ हैंडशेक पैदा करता है और विफल पथ इंटरफ़ेस पर कुछ भी नहीं पैदा करता, तो आपने कुछ भी कमज़ोर किए बिना टूटन का स्थान ढूँढ लिया है।
इसलिए बिना उत्तर वाला UDP पैकेट न यह साबित करता है कि सर्वर ऑफ़लाइन है, न यह कि वह सुरक्षित है। यह साबित करता है कि यह जाँच, इस पथ पर, इस क्षण, स्वीकार नहीं की गई।