VPN निर्गमन पछाडि पोर्ट स्क्यानका नतिजा किन बदलिन्छन्?
निर्गमन बदल्नुहोस् र सेवा नसर्दै पोर्ट फरक जवाफ दिन सक्छ। मार्गको अवलोकनलाई तपाईंलाई साँच्चै चाहिने सूचीबाट अलग गर्नुहोस्।
एउटै पोर्ट जाँच कार्यालयको लाइनबाट र 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खाली दोस्रो नतिजा सूचनाप्रद हुन्छ, किनकि डेमनसम्म केही पुगेन र प्रश्न फिल्टर, सुरक्षा समूह वा मार्गकै हो। हिट भन्नाले सेवाले तपाईंको स्रोत देख्यो र आफ्नो जवाफ छान्यो भन्ने हुन्छ, र त्यो निर्णय सामान्यतया पढ्न सकिने नियममा लेखिएको हुन्छ। कुनै पनि नतिजाले प्रदायकबारेको कथालाई समर्थन गर्दैन, र दुवैलाई प्याकेट क्याप्चरभन्दा सस्तोमा जाँच्न सकिन्छ।
यातायात, प्रमाणपत्र र प्रतिक्रिया अलग-अलग पढ्नुहोस्
तीन तहले तीन अवलोकन उत्पन्न गर्छन्, र तीमध्ये एउटा परीक्षण गर्ने जाँचले अरू दुईबारे रिपोर्ट गर्न सक्दैन। तिनलाई एउटै फैसलामा पट्याउनुको सट्टा रेकर्डमा अलग लाइनका रूपमा राख्नुहोस्, किनकि हरेक लाइन आफ्नै तरिकाले असफल हुन्छ र असफलताको तरिकाले अर्को पटक कहाँ हेर्ने भन्ने बताउँछ।
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
एउटा आदेशले तपाईंले नियन्त्रण गर्ने सेवाविरुद्ध पहिलो तीन लाइन उत्पन्न गर्छ। त्यसको आउटपुट च्याट सन्देशमा होइन, स्क्यानको छेउमा रेकर्डमा राख्नुहोस्:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/आउटपुट क्रममा पढ्नुहोस्: ह्यान्डशेकले यातायातको प्रश्नको जवाफ दिन्छ, प्रमाणपत्रको विषयले नामको प्रश्नको, र प्रतिक्रियाको मुख्य भागले एप्लिकेसनको प्रश्नको। जब ह्यान्डशेक लाइन सफल हुन्छ र प्रतिक्रिया लाइन हुँदैन, तपाईंसँग भाँचिएको अपस्ट्रिम भएको फ्रन्टएन्ड छ, रोकिएको पोर्ट होइन। त्यो तपाईंले खोलेको टिकटभन्दा फरक टिकट हो, र त्यो स्पष्टसँग भन्न लायक छ।
टिकटमा चार तथ्य लेखेर टुङ्ग्याउनुहोस्: स्रोत ठेगाना, स्क्यानको प्रकार, जवाफ दिने होस्ट र समय। पछिको तुलनालाई चाहिने सबै यिनै चारमा बस्छ, र अर्को पटक मुद्दा उठाउनेसँग तपाईंको टर्मिनल इतिहास हुनेछैन। चारै भर्न सक्नुहुन्न भने रन पूरा भएको छैन।