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 में है। यदि हैंडशेक विफल हो, तो सुरंग के बारे में सामान्यीकरण करने के बजाय स्थानीय त्रुटि स्ट्रिंग दर्ज करें। दायरे का नोट परिणाम के पास रखें, क्योंकि अगले व्यक्ति को जानना है कि किस विधि ने इसे बनाया।