मैं एक आईपी पते पर पता लगा सकता हूं, लेकिन इसे पिंग नहीं कर सकता

Question

विंडोज पर, अगर मैं Google को ट्रेस करता हूं तो मुझे निम्नलिखित मिलता है;

C:\Users\Dave>tracert -d -w 100 www.google.com

Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms  150.101.33.18
  5    35 ms    43 ms    33 ms  72.14.221.174
  6    33 ms    33 ms    33 ms  66.249.95.234
  7    31 ms    31 ms    31 ms  209.85.142.11
  8    33 ms    33 ms    38 ms  216.58.220.100

Trace complete.

अब, अगर मैं 66.249.95.234 के तीसरे अंतिम आईपी पते को पिंग करता हूं, तो मुझे यह मिलता है ...

C:\Users\Dave>ping 66.249.95.234

Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.95.234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

यह कैसे होता है कि 'पिंग' आंतरिक रूप से किसी तरह से वास्तविक पिंग के लिए अलग तरह से काम करता है? वे कैसे अलग हैं? ट्रैसर की तरह काम करने के लिए मुझे पिंग करने के लिए क्या करने की आवश्यकता है?

Comments

यह केवल यह हो सकता है कि ICMP ECHO अवरुद्ध हो।

— बुरहान खालिद

Answer 1

यह सब कैसे tracert काम करता है के साथ क्या करना है। पिंग सीधे ICMP से बिंदु A से बिंदु B तक है, जो रूटिंग नियमों के माध्यम से नेटवर्क का पता लगाता है। Tracert बहुत अलग काम करता है, भले ही वह ICMP का उपयोग करता हो।

Tracert अंतिम हॉप को लक्षित करके काम करता है, लेकिन TTL को सीमित करके एक समय से अधिक संदेश की प्रतीक्षा करता है, और फिर अगले पुनरावृत्ति के लिए इसे एक से बढ़ाता है। इसलिए, जो प्रतिक्रिया मिलती है, वह ICMP इको रिक्वेस्ट का मेजबान के लिए ICMP इको रिक्वेस्ट का जवाब नहीं है, लेकिन एक समय उस होस्ट के संदेश को पार कर जाता है - इसलिए भले ही वह ICMP का उपयोग कर रहा हो, लेकिन वह इसे बहुत अलग तरीके से उपयोग कर रहा है ।

आप इसके बारे में अधिक विवरण यहां पढ़ सकते हैं ।

Comments

अंतिम बिंदु को जोड़ने के लिए क्यों समय समाप्त हो जाता है: जाहिर तौर पर तीसरी अंतिम 3 होस्ट को इसके माध्यम से ट्रैफ़िक के लिए राउटर के रूप में काम करने के लिए कॉन्फ़िगर किया गया है (जिसमें विफलताओं के लिए ICMP TTL EXCEEDED संदेश भेजना शामिल है), लेकिन इसके लिए ट्रैफ़िक को अवरुद्ध करना, विशेष रूप से उत्तर देने के लिए नहीं ICMP ECHO REQ। वैसे, ट्रेसरूट ग्राहक गंतव्य के रूप में अंतिम हॉप के साथ कुछ भी भेज सकता है - यह कर सकता है ICMP ECHO अनुरोध किया लेकिन यह बस के रूप में अच्छी तरह से कुछ टीसीपी SYN हो सकता है (अन्य ICMP संदेशों, esp ट्रिगर हो सकता है जो जब लक्ष्य jhost पहुँच जाता है।। वास्तव में, कार्यान्वयन OSes के बीच भिन्न होता है। और फिर वहाँ tracepath...

— Hagen von Eitzen

@HagenvonEitzen कि अपने दम पर एक अच्छा जवाब देना होगा (सबसे अच्छा, IMO!)

— को मोनिका

यह भी ध्यान देने योग्य है कि कई "ट्रैसर्ट" कार्यान्वयन आईसीएमपी पैकेट भी नहीं भेजते हैं। कम से कम यह tracerouteसबसे लिनक्स पर मामला है , जो यूडीपी डेटाग्राम भेजता है, हालांकि मुझे यकीन नहीं है कि विंडोज़ संस्करण क्या करता है। इंटरमीडिएट हॉप्स को केवल ICMP ही नहीं, बल्कि किसी भी तरह के पैकेट के लिए ICMP TTL EXCEEDED भेजना चाहिए।

— डिजिटल ट्रामा

tracertविंडोज 7 पर @DigitalTrauma Wireshark ICMP इको अनुरोध भेजता है।

— बॉब

Answer 2

सबसे पहले आपके दोनों कमांड अलग-अलग डेस्टिनेशन आईपी एड्रेस के साथ पैकेट भेज रहे हैं। इसका मतलब है कि वे अलग-अलग मार्ग ले सकते हैं।

जब आप 66.249.95.234मार्ग की ओर देखते हैं 216.58.220.100, तो आप मान सकते हैं कि गंतव्य के पते वाले पैकेट 66.249.95.234उसी बिंदु तक पहुंचने तक उसी मार्ग का उपयोग करेंगे। हालांकि यह एक मान्य धारणा नहीं है।

यह मार्ग के लिए 66.249.95.234एक से अधिक होने के लिए पूरी तरह से मान्य है 216.58.220.100। कभी-कभी ऐसा भी होता है कि ऐसा कोई मार्ग नहीं है जो आपके पैकेटों को उस मध्यवर्ती राउटर तक ले जा सकता है, लेकिन यह एक अच्छी तरह से डिज़ाइन किया गया नेटवर्क नहीं होगा, अगर ऐसा होता।

मुझे नहीं पता कि आप tracertऔर pingकमांड दोनों एक ही प्रोटोकॉल का उपयोग कर रहे हैं या नहीं। अधिकांश पिंग कार्यान्वयन ICMP इको अनुरोध पैकेट का उपयोग करते हैं। हालांकि ट्रेसरआउट कार्यान्वयन आईसीएमपी इको अनुरोध, टीसीपी SYN और UDP पैकेट सहित प्रोटोकॉल की एक विस्तृत श्रृंखला का समर्थन करते हैं। यदि दोनों अलग-अलग प्रोटोकॉल का उपयोग करते हैं, तो यह विभिन्न परिणामों को देखने के लिए एक महत्वपूर्ण कारक हो सकता है।

अंत में यह भले ही सभी पैकेटों तक पहुंचने के लिए था 66.249.95.234, यह संभव है कि 66.249.95.234क्या इसके आधार पर बेतहाशा अलग व्यवहार होगा:

• पैकेट को अग्रेषित करें
• खुद को संबोधित एक पैकेट पर एक ICMP त्रुटि का उत्पादन
• किसी अन्य को संबोधित पैकेट पर ICMP त्रुटि उत्पन्न करें

केवल तीन मामलों में से एक में चुपचाप पैकेट छोड़ने का विकल्प स्पष्ट रूप से बहुत से नेटवर्क डायग्नोस्टिक्स टूल को तोड़ने वाला है, लेकिन कुछ सिस्टम प्रशासकों को वैसे भी ऐसा करने से नहीं रोकता है।

Answer 3

जैसा कि नेटवर्क पर सुरक्षा लगातार बढ़ रही है, एक आसान बात जो बहुत से लोग करते हैं, वह मूल रूप से आईसीएमपी प्रोटोकॉल के पहलुओं को अक्षम करना है। यह अनुरेखक को जवाब देने और FQDN को हॉप से ​​वापस करने से रोकता है। कभी-कभी प्रशासक चीजों को लॉक कर देते हैं ताकि तंग भी काम न करें। यह सिस्टम के व्यवस्थापक का एक निर्णय है।

यह भी संभावना है कि सिस्टम एक व्यापक नेटवर्किंग लोड को संभाल रहा है, ICMP आम तौर पर वास्तविक डेटा की तुलना में संसाधित होने में प्राथमिकता में बहुत कम है।

Comments

यह वास्तव में सवाल का जवाब नहीं देता है। सवाल यह है कि, यदि दोनों ट्रेसरआउट और पिंग ICMP का उपयोग करते हैं, तो क्या पिंग विफल और ट्रेसरआउट सफल होता है।

— MaQleod