तीच पोर्ट तपासणी कार्यालयीन लाईनवरून आणि VPN निर्गमावरून चालवा, आणि कोणीही न बदललेल्या पत्त्याबद्दल दोन उत्तरे जुळणार नाहीत असे होऊ शकते. हा फरक मार्गातून आणि कोणत्या यजमानाने उत्तर दिले यातून येतो, सेवा सुरू आहे की बंद यातून नाही. तीन प्रश्न ती स्पष्टीकरणे वेगळी करतात: तपासणीने प्रत्यक्षात काय विचारले, कोणत्या यजमानाने उत्तर दिले, आणि तुमच्या स्वतःच्या सर्व्हरने काय नोंदवले. ते याच क्रमाने पूर्ण करा आणि पुढच्याकडे जाण्यापूर्वी प्रत्येक उत्तर लिहा.

दोन फेऱ्यांची तुलना करण्यापूर्वी तपासणी दुरुस्त करा

स्थिती-शब्दाची तुलना दुसऱ्या स्थिती-शब्दाशी तेव्हाच करता येते, जेव्हा दोन्ही एकाच प्रयोगातून आलेले असतात. पाच क्षेत्रे ते निश्चित करतात: दूरच्या बाजूने पाहिलेला स्रोत पत्ता, सोडवलेले गंतव्य, पोर्ट, स्कॅनचा प्रकार आणि वेळ. यापैकी कोणतेही बदलल्यास तुम्ही पहिले दोनदा मोजण्याऐवजी दुसरा प्रयोग केला आहे.

सर्वांपूर्वी स्रोत तपासा, कारण VPN क्लायंट सुरू असतानाही रहदारी भौतिक इंटरफेसने बाहेर जाऊ शकते. दूरच्या बाजूला काय दिसते ते विचारा, नंतर कर्नेलला कोणता इंटरफेस निवडला ते विचारा:

curl -s https://ifconfig.me
ip route get 203.0.113.20

वेगवेगळ्या नेटवर्कवरील दोन पत्ते म्हणजे स्पष्टीकरण आधीच हातात आहे, आणि उर्वरित तपासण्या ते केवळ पुष्टी करतील. ते जुळल्यास तपासणी कारण-ध्वज सुरू ठेवून नोंदवा, म्हणजे स्थिती केवळ नग्न शब्द म्हणून एकटी उभी न राहता स्पष्टीकरणाशी जोडलेली परत येईल. स्कॅनचा प्रकारही त्या नोंदीत येतो, कारण तो काय मागितले हे वर्णन करतो, काय परत आले ते नाही. स्रोत, पद्धत आणि टाइमस्टॅम्प नसलेल्या स्थितीची कोणाशीही तुलना करता येत नाही:

nmap -sT -p 443,8443 --reason 203.0.113.20

ती आउटपुट नोंदीच्या शेजारी ठेवा, पुढच्या व्यक्तीला दिसू न शकणाऱ्या स्क्रोलबॅक बफरमध्ये नाही. जुळत नसलेल्या दोन प्रामाणिक स्कॅन केवळ तेव्हाच वाद असतात, जेव्हा कोणी अटी लिहिलेल्या नसतात. अटी निश्चित झाल्यावर एकतर निकाल जुळतात आणि प्रश्न बंद होतो, किंवा ते वेगळे असतात आणि फरक मार्गाबद्दलची वस्तुस्थिती असतो.

कोणत्या यजमानाने हस्तांदोलन पूर्ण केले ते शोधा

पूर्ण झालेले हस्तांदोलन हे सिद्ध करते की कोणत्यातरी यजमानाने ते पूर्ण केले, आणि तो यजमान तुमच्या मनातील प्रक्रिया असावा असे नाही. लोड बॅलन्सर, उलट प्रॉक्सी किंवा SYN प्रॉक्सी खऱ्या सर्व्हरच्या सहभागापूर्वी उत्तर देऊ शकतात, जे सामान्य रचना आहे, लक्षण नाही. अपेक्षित नावासाठी वैध प्रमाणपत्रही हे संकुचित करत नाही, कारण प्रमाणपत्र सेवा-संबंध वर्णन करते आणि कोणत्या यंत्राने जोडणी संपवली याबद्दल काहीही सांगत नाही.

Nmap पोर्ट-स्थिती संदर्भ हे मूलभूत मानतो: स्थिती तपासणीने जिथून पाठवले तिथून काय निरीक्षण करता आले ते नोंदवते, पोर्टचा गुणधर्म नाही. स्थिती-शब्द असा वाचा आणि जुळत नसलेल्या दोन फेऱ्या विरोधाभासी नव्हे तर सुसंगत दिसू लागतात, आणि प्रश्न पोर्ट उघडा आहे का यावरून त्याच्यासमोर कोण उभे होते याकडे सरकतो.

दुसऱ्या प्रश्नाचे उत्तर बाहेरून नाही, बॅकएंडमध्ये द्या. जो फ्रंटएंड जोडण्या स्वीकारतो आणि नंतर आपल्या अपस्ट्रीमपर्यंत पोहोचत नाही, तो संथ अनुप्रयोग असलेल्या निरोगी सेवेचे नेमके बाह्य चित्र तयार करतो. केवळ अपस्ट्रीमची स्वतःची नोंद दोन्ही प्रकरणे वेगळी करते:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

लॉग ओळ अनुप्रयोगाने प्रत्यक्षात पाहिलेला क्लायंट पत्ता दाखवते, आणि दुसरा आदेश दाखवतो की पोर्ट 443 धरून ठेवणारी प्रक्रिया तुमचा अनुप्रयोग आहे की त्याच्यापुढे काहीतरी. जर दोन्ही कोणता पत्ता जोडला गेला यावर जुळत नसतील, तर तुम्ही एका विनंतीचे दोन पाय पाहत आहात आणि तिकिटाने तसे म्हटले पाहिजे.

बोगद्याला दोष देण्यापूर्वी स्वतःचे नियम तपासा

हेतुपूर्वक ठेवलेले धोरण हे पोर्ट एका नेटवर्कवर उत्तर देण्याचे आणि दुसऱ्यावर न देण्याचे सर्वात सामान्य कारण आहे, आणि ते उपलब्ध स्पष्टीकरणांपैकी सर्वात कमी मनोरंजक आहे. प्रवेश नियम एका स्रोताला परवानगी देण्यासाठी आणि बाकीचे टाकून देण्यासाठी असतात, म्हणून निर्गमाचा बदल हीच ती घटना आहे ज्यासाठी ते लिहिले गेले. त्यामुळे VPN द्वारे वेगळी स्थिती हे दाखवत नाही की प्रदाता रहदारीची तपासणी करतो. ते दाखवते की तुमचा स्रोत पत्ता आता वेगळा आहे, जे खूपच लहान विधान आहे.

हे नियम सर्व्हरवर वाचता येतात, म्हणून नेटवर्कच्या मध्याबद्दल अंदाज लावण्याऐवजी ते वाचा. दोन्हीपैकी कोणत्याही पत्ता-श्रेणीचा उल्लेख करणारे गाळणी नियम यादी करा, नंतर जोडणी डेमनपर्यंत पोहोचली का ते तपासा:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

रिकामा दुसरा निकाल माहितीपूर्ण आहे, कारण डेमनपर्यंत काहीच पोहोचले नाही आणि प्रश्न गाळणी, सुरक्षा गट किंवा मार्गाचाच आहे. हिट म्हणजे सेवेने तुमचा स्रोत पाहिला आणि तिचे उत्तर निवडले, आणि तो निर्णय सहसा वाचता येणाऱ्या नियमात लिहिलेला असतो. दोन्हीपैकी कोणताही निकाल प्रदात्याबद्दलच्या कथेला आधार देत नाही, आणि दोन्ही पॅकेट पकडण्यापेक्षा स्वस्तात तपासता येतात.

वाहतूक, प्रमाणपत्र आणि प्रतिसाद वेगवेगळे वाचा

तीन स्तर तीन निरीक्षणे निर्माण करतात, आणि त्यातील एकाची चाचणी करणारी तपासणी उर्वरित दोनांबद्दल अहवाल देऊ शकत नाही. त्यांना एकाच निवाड्यात दुमडण्याऐवजी नोंदीत स्वतंत्र ओळी म्हणून ठेवा, कारण प्रत्येक ओळ स्वतःच्या पद्धतीने अयशस्वी होते आणि अयशस्वीतेची पद्धत पुढे कुठे पाहावे ते सांगते.

ObservationWhat it settlesWhat it leaves open
Connection completedA host on the path accepted the handshakeWhich host, and whether its upstream is reachable
Certificate valid for the nameThe endpoint holds a credential for that nameWhether the process behind it is the one you meant
Expected response bodyThe application handled the requestAnything about other ports or other paths
Connection refusedA host replied and nothing was listeningWhether a filter sits ahead of the refused port
TimeoutNo reply arrived before the deadlineDrop, blackhole route or an overloaded host

एकच आदेश तुम्ही नियंत्रित करता त्या सेवेविरुद्ध पहिल्या तीन ओळी तयार करतो. त्याचे आउटपुट चॅट संदेशात नाही, स्कॅनच्या शेजारी नोंदीत ठेवा:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

आउटपुट क्रमाने वाचा: हस्तांदोलन वाहतुकीच्या प्रश्नाचे उत्तर देते, प्रमाणपत्राचा विषय नावाच्या प्रश्नाचे, आणि प्रतिसादाचा मुख्य भाग अनुप्रयोगाच्या प्रश्नाचे. जेव्हा हस्तांदोलनाची ओळ यशस्वी होते आणि प्रतिसादाची ओळ नाही, तेव्हा तुमच्याकडे तुटलेल्या अपस्ट्रीमसह फ्रंटएंड आहे, अडवलेला पोर्ट नाही. ते तुम्ही उघडलेल्या तिकिटापेक्षा वेगळे तिकीट आहे, आणि ते स्पष्टपणे सांगण्यासारखे आहे.

तिकिटात चार तथ्ये लिहून पूर्ण करा: स्रोत पत्ता, स्कॅनचा प्रकार, उत्तर देणारा यजमान आणि वेळ. नंतरच्या तुलनेला जे काही लागते ते याच चारांत राहते, आणि पुढे प्रकरण घेणाऱ्याकडे तुमचा टर्मिनल इतिहास नसेल. चारही भरता येत नसतील, तर फेरी पूर्ण झालेली नाही.

संबंधित लेख