एक ही पोर्ट जाँच कार्यालय की लाइन से और 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/

आउटपुट को क्रम में पढ़िए: हैंडशेक ट्रांसपोर्ट सवाल का जवाब देता है, प्रमाणपत्र का विषय नाम के सवाल का और प्रतिक्रिया का मुख्य भाग एप्लिकेशन के सवाल का। जब हैंडशेक पंक्ति सफल हो और प्रतिक्रिया पंक्ति न हो, तो आपके पास टूटे अपस्ट्रीम वाला फ़्रंटएंड है, अवरुद्ध पोर्ट नहीं। वह उस टिकट से अलग टिकट है जो आपने खोला था, और यह साफ़ कहना बनता है।

टिकट में चार तथ्य लिखकर समाप्त कीजिए: स्रोत पता, स्कैन का प्रकार, जवाब देने वाला मेज़बान और समय। बाद की तुलना को जो कुछ चाहिए वह इन्हीं चार में रहता है, और आगे मामला उठाने वाले के पास आपके टर्मिनल का इतिहास नहीं होगा। अगर आप चारों नहीं भर सकते, तो रन पूरा नहीं हुआ।

संबंधित लेख