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 पोर्टलाई अनुमति दिन्छ भनी पुष्टि गर्नुहोस्। होस्ट फायरवाल नियम र क्लाउड सुरक्षा समूह दुई स्वतन्त्र ढोका हुन्, र यीमध्ये जुनसुकैले अर्कोले अनुमति दिएको प्याकेट फाल्न सक्छ। दुवैलाई कन्फिगरेसनमा भएको वास्तविक पोर्टसँग जाँच्नुहोस्, तपाईंले सम्झेको पोर्टसँग होइन।

ठेगाना पोर्टजत्तिकै महत्त्वपूर्ण छ। कुनै विशेष ठेगानामा सुन्ने सर्भरले अर्को ठेगानामा आएको प्याकेटको जवाफ दिँदैन, र धेरै इन्टरफेस भएको होस्टले जाँच तपाईंको मनसाय नभएको इन्टरफेसमा लिन सक्छ।

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

स्क्यानको नतिजा इमानदारीसाथ पढ्ने

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

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

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