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 मध्ये आहे। हस्तांदोलन अपयशी झाल्यास, सुरंगाबद्दल सामान्यीकरण करण्याऐवजी स्थानिक त्रुटी श्रेणी नोंदवा। व्याप्तीची टीप निकालाजवळ ठेवा, कारण पुढच्या व्यक्तीला कोणत्या पद्धतीने तो तयार केला हे कळायला हवे।