VPN मा Nmap को कच्चा स्क्यान असफल, तर -sT जडान काम गर्छ?

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

क्षमतालाई सुरुङबाट अलग गर्नुहोस्

सामान्य अनुप्रयोगले कर्नेललाई TCP जडान खोल्न भन्छ, र कर्नेलले विशेष अनुमति बिना ह्यान्डसेक गर्छ। कच्चा स्क्यानले प्याकेट आफै बनाउँछ, जसका लागि प्लेटफर्म अनुसार कच्चा सकेट वा क्याप्चर ड्राइभर चाहिन्छ। यी अनुमति र ड्राइभरका प्रश्न हुन्, र VPN जोडिएको होस् वा नहोस् ती रहन्छन्।

यही भिन्नताले सामान्य असममिति बुझाउँछ। curl सफल हुन्छ किनभने सकेट मार्ग काम गर्छ, जबकि SYN स्क्यान असफल हुन्छ किनभने प्रक्रियाले सुरुङ इन्टरफेसमा कच्चा सकेट खोल्न सक्दैन। यसले उल्टो अवस्था पनि बुझाउँछ: मार्गले प्रोब फ्याँकिदिने हुँदा कच्चा स्क्यान फिल्टर भएको जनाउँछ, तर अनुप्रयोगको मार्ग राम्रो रहन्छ।

दुवैमध्ये कुनै नतिजाले दूरस्थ सेवाको वर्णन गर्दैन। दुवैले एउटै विधि अन्तर्गत एउटै मार्गको वर्णन गर्छन्, त्यसैले विधिलाई निष्कर्षसँग जोडेर राख्नुहोस्।

जडान जाँच एउटा स्वीकृत होस्टमा चलाउनुहोस्

तपाईंको कामले समेट्ने एउटै होस्ट छान्नुहोस्, त्यसपछि कच्चा पहुँच नचाहिने मोड प्रयोग गर्नुहोस्। यहाँको उदाहरण लक्ष्य 198.51.100.24 हो, यस्तै उदाहरणका लागि आरक्षित दस्तावेज ठाउँ।

एउटा पङ्क्ति, एउटा होस्ट, एउटा पोर्ट, कुनै खोज चरण छैन:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT पूर्ण TCP जडान छान्छ, त्यसैले अनुप्रयोगले प्रयोग गर्ने त्यही कर्नेल मार्ग अभ्यास गर्छ र क्याप्चर ड्राइभर चाहिँदैन। -Pn होस्ट खोज छोड्छ; nmap स्थानीय खण्डका लक्ष्यहरूका लागि लिङ्क-तह समाधान भने पनि गर्छ, त्यसैले यो फ्ल्याग शून्य प्रारम्भिक ट्राफिकको वाचा होइन। --unprivileged nmap लाई कच्चा वा सुन्ने अधिकार छैन भनी मान्न भन्छ, जसले विधि बदल्छ र केही दिँदैन।

हरेक फ्ल्यागलाई एउटा परिवर्तनका रूपमा पढ्नुहोस्, मर्मतका रूपमा होइन

हरेक विकल्पलाई विधिका बारेमा एउटा भनाई मान्नुहोस्। -sT, -Pn वा --unprivileged मध्ये कुनैले पनि मार्ग थप्दैन, दूरस्थ फायरवाल खोल्दैन वा प्रमाणपत्र प्रमाणित गर्दैन। जडान स्क्यानले सेवाले अभिलेख गर्ने वास्तविक ह्यान्डसेक पनि पूरा गर्छ, त्यसैले स्वीकृत जाँच र अस्वीकृत सफाई सर्भरबाट हेर्दा दायरा र गतिबाहेक उस्तै देखिन्छन्। आउटपुट नबदलेसम्म विकल्प थुपार्नु भनेको विधिको समस्या सञ्जाल निष्कर्षका रूपमा अभिलेख गर्ने तरिका हो।

आउटपुटले बन्द भन्छ भने कसैले रिसेटले जवाफ दियो, र त्यो मौनभन्दा फरक निष्कर्ष हो। आउटपुटले फिल्टर भन्छ भने कुनै उपकरणले प्रोब वा त्यसको जवाफ फ्याँकिदियो, र VPN संयोगवश हुन सक्छ। ठ्याक्कै शब्दावली लेख्नुहोस्, किनभने खोज चरणको फैसला र प्रोब-तहको असफलताले फरक तहतर्फ सङ्केत गर्छन्।

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

यातायात नतिजामा रोकिनुहोस्, त्यसपछि सेवा जाँच्नुहोस्

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

सेवाकै आफ्नै क्लाइन्टसङ्ग अगाडि बढ्नुहोस् ताकि TLS पहिचान र अनुप्रयोग व्यवहार छुट्टाछुट्टै तथ्यका रूपमा देखियोस्:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

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

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