जानने योग्य बातें
- traceroute कमांड के साथ आपको जो एकमात्र पैरामीटर शामिल करना होगा वह है गंतव्य का होस्ट नाम या IP पता।
- TTL एक के साथ जांच शुरू करें और तब तक एक से बढ़ाएं जब तक आपको ICMP "पोर्ट अप्राप्य" न मिल जाए या अधिकतम प्रयासों के मान तक न पहुंच जाएं।
यह लेख लिनक्स मशीनों पर लागू traceroute जानकारी को कवर करता है और इसमें कमांड स्विच स्पष्टीकरण और परिणामों की व्याख्या कैसे करें, इस पर जानकारी शामिल है। Traceroute का उपयोग विंडोज में अलग तरीके से किया जाता है।
Traceroute कैसे काम करता है
traceroute कमांड उस यात्रा को मैप करता है जो सूचना का एक पैकेट अपने स्रोत से अपने गंतव्य तक लेता है। traceroute का एक उपयोग नेटवर्क में डेटा हानि कब होती है, इसका पता लगाना है, जो एक नोड के डाउन होने का संकेत दे सकता है।
क्योंकि रिकॉर्ड में प्रत्येक हॉप मूल पीसी और इच्छित लक्ष्य के बीच एक नए सर्वर या राउटर को दर्शाता है, traceroute स्कैन के परिणामों की समीक्षा करने से धीमे बिंदुओं की पहचान होती है जो आपके नेटवर्क ट्रैफ़िक पर प्रतिकूल प्रभाव डाल सकते हैं।
Traceroute के साथ समस्या निवारण
नेटवर्क ट्रैफ़िक द्वारा अनुसरण किए जाने वाले विशिष्ट मार्ग का मूल्यांकन करना (या उस दुष्ट गेटवे को ढूंढना जो आपके पैकेट को छोड़ रहा है) कई समस्या निवारण चुनौतियाँ प्रस्तुत करता है। Traceroute प्रत्येक गेटवे से ICMP TIME_EXCEEDED प्रतिक्रिया प्राप्त करने के लिए IP प्रोटोकॉल time to live फ़ील्ड का उपयोग करता है जो गंतव्य होस्ट तक के पथ पर होता है।
traceroute कमांड को निष्पादित करते समय आपको केवल एक पैरामीटर शामिल करना होगा जो गंतव्य का होस्ट नाम या IP पता है।
Traceroute सिंटैक्स और स्विच
Traceroute निम्नलिखित सामान्य सिंटैक्स का पालन करता है:
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g gateway ] [ -i iface ] [ -m max_ttl ] [ -p port ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w waittime ] [ -z pausemsecs ] host [ packetlen ]
एक या अधिक वैकल्पिक स्विच निर्दिष्ट करके आप कमांड के प्रदर्शन या आउटपुट को बदल सकते हैं।
| Traceroute कमांड स्विच | |
|---|---|
| -f | पहले आउटगोइंग प्रोब पैकेट में उपयोग किए गए प्रारंभिक time-to-live को सेट करें। |
| -F | "डोंट फ्रैगमेंट" बिट सेट करें। |
| -d | सॉकेट लेवल डिबगिंग सक्षम करें। |
| -g | एक ढीला स्रोत मार्ग गेटवे निर्दिष्ट करें (अधिकतम 8)। |
| -i | आउटगोइंग प्रोब पैकेट के लिए स्रोत IP पता प्राप्त करने के लिए एक नेटवर्क इंटरफ़ेस निर्दिष्ट करें। यह आमतौर पर केवल मल्टी-होम्ड होस्ट पर उपयोगी होता है। (इसे करने का दूसरा तरीका -s फ्लैग देखें।) |
| -I | UDP डेटाग्राम के बजाय ICMP ECHO का उपयोग करें। |
| -m | आउटगोइंग प्रोब पैकेट में उपयोग किए गए अधिकतम time-to-live (अधिकतम हॉप्स की संख्या) सेट करें। डिफ़ॉल्ट 30 हॉप्स है (TCP कनेक्शन के लिए उपयोग किया जाने वाला वही डिफ़ॉल्ट)। |
| -n | प्रतीकात्मक और संख्यात्मक के बजाय हॉप पते को संख्यात्मक रूप से प्रिंट करें (पथ पर पाए गए प्रत्येक गेटवे के लिए नेमसर्वर एड्रेस-टू-नाम लुकअप बचाता है)। |
| -p | प्रोब में उपयोग की जाने वाली बेस UDP पोर्ट संख्या सेट करें (डिफ़ॉल्ट 33434)। Traceroute को उम्मीद है कि गंतव्य होस्ट पर UDP पोर्ट्स बेस से बेस + nhops - 1 पर कुछ भी सुन नहीं रहा है (ताकि रूट ट्रेसिंग को समाप्त करने के लिए एक ICMP PORT_UNREACHABLE संदेश वापस कर दिया जाए)। यदि डिफ़ॉल्ट रेंज में किसी पोर्ट पर कुछ सुन रहा है, तो इस विकल्प का उपयोग अप्रयुक्त पोर्ट रेंज चुनने के लिए किया जा सकता है। |
| -r | सामान्य रूटिंग टेबल को बायपास करें और सीधे जुड़े नेटवर्क पर एक होस्ट पर भेजें। यदि होस्ट सीधे जुड़े नेटवर्क पर नहीं है, तो एक त्रुटि वापस कर दी जाती है। इस विकल्प का उपयोग एक स्थानीय होस्ट को एक इंटरफ़ेस के माध्यम से पिंग करने के लिए किया जा सकता है जिसके माध्यम से इसका कोई मार्ग नहीं है (उदाहरण के लिए, routed(8C) द्वारा इंटरफ़ेस ड्रॉप किए जाने के बाद)। |
| -s | निम्नलिखित IP पते का उपयोग करें (जो आमतौर पर होस्टनाम के बजाय IP नंबर के रूप में दिया जाता है) आउटगोइंग प्रोब पैकेट में स्रोत पते के रूप में। मल्टी-होम्ड होस्ट (एक से अधिक IP पते वाले) पर, इस विकल्प का उपयोग स्रोत पते को उस इंटरफ़ेस के IP पते के अलावा कुछ और होने के लिए बाध्य करने के लिए किया जा सकता है जिस पर प्रोब पैकेट भेजा जाता है। यदि IP पता इस मशीन के इंटरफ़ेस पतों में से एक नहीं है, तो एक त्रुटि वापस कर दी जाती है और कुछ भी नहीं भेजा जाता है। (इसे करने का दूसरा तरीका -i फ्लैग देखें।) |
| -t | प्रोब पैकेट में type-of-service को निम्नलिखित मान पर सेट करें (डिफ़ॉल्ट शून्य)। मान 0 से 255 की सीमा में एक दशमलव पूर्णांक होना चाहिए। इस विकल्प का उपयोग यह देखने के लिए किया जा सकता है कि विभिन्न प्रकार की सेवा के परिणामस्वरूप अलग-अलग पथ मिलते हैं या नहीं। (यदि आप 4.4bsd नहीं चला रहे हैं, तो यह अकादमिक हो सकता है, क्योंकि सामान्य नेटवर्क सेवाएं जैसे टेलनेट और FTP आपको TOS को नियंत्रित नहीं करने देतीं।) TOS के सभी मूल्य कानूनी या सार्थक नहीं हैं—परिभाषाओं के लिए IP स्पेक देखें। उपयोगी मान शायद -t 16 (कम विलंब) और -t 8 (उच्च थ्रूपुट) हैं। |
| -v | वर्बोज़ आउटपुट। TIME_EXCEEDED और UNREACHABLEs के अलावा प्राप्त ICMP पैकेट सूचीबद्ध हैं। |
| -w | प्रोब के लिए प्रतिक्रिया की प्रतीक्षा करने का समय (सेकंड में) सेट करें (डिफ़ॉल्ट 5 सेकंड)। |
| -x | IP चेकसम टॉगल करें। आमतौर पर, यह traceroute को IP चेकसम की गणना करने से रोकता है। कुछ मामलों में, ऑपरेटिंग सिस्टम आउटगोइंग पैकेट के कुछ हिस्सों को ओवरराइट कर सकता है लेकिन चेकसम की पुनर्गणना नहीं करता; इस प्रकार, कुछ मामलों में डिफ़ॉल्ट चेकसम की गणना नहीं करना है और -x का उपयोग करने से उनकी गणना होती है। ध्यान दें कि चेकसम आमतौर पर ICMP ECHO प्रोब (-I) का उपयोग करते समय अंतिम हॉप के लिए आवश्यक होते हैं, इसलिए ICMP का उपयोग करते समय उनकी गणना हमेशा की जाती है। |
| -z | प्रोब के बीच ठहराव का समय (मिलीसेकंड में) सेट करें (डिफ़ॉल्ट 0)। सोलारिस और सिस्को के राउटर्स जैसे कुछ सिस्टम, icmp संदेशों को रेट लिमिट करते हैं। इसके साथ उपयोग करने के लिए एक अच्छा मान 500 है (उदाहरण के लिए, 1/2 सेकंड)। |
परिणामों की व्याख्या
Traceroute UDP प्रोब पैकेट लॉन्च करके एक इंटरनेट होस्ट पर एक IP पैकेट के पथ को रूपरेखा करता है जिसमें एक छोटा TTL होता है फिर एक गेटवे से ICMP "टाइम एक्सीडेड" उत्तर के लिए सुनता है। TTL एक के साथ जांच शुरू करें और तब तक एक से बढ़ाएं जब तक आपको ICMP "पोर्ट अप्राप्य" न मिल जाए (जिसका अर्थ है कि पैकेट अपने गंतव्य पर पहुंच गया) या प्रयासों के अधिकतम मान तक न पहुंच जाए, जो डिफ़ॉल्ट रूप से 30 हॉप्स है और इसे -m फ्लैग के साथ बदला जा सकता है।
जब traceroute निष्पादित होता है, तो यह प्रत्येक TTL सेटिंग पर तीन प्रोब भेजता है और फिर कंसोल पर एक लाइन प्रिंट करता है जो TTL, गेटवे का पता, और प्रत्येक प्रोब का राउंड-ट्रिप समय दिखाता है। यदि प्रोब उत्तर विभिन्न गेटवे से आते हैं, तो प्रत्येक प्रतिक्रिया देने वाले सिस्टम का पता प्रिंट होता है। यदि traceroute पांच सेकंड के भीतर प्रतिक्रिया प्राप्त नहीं करता है (-w फ्लैग के साथ बदला गया), तो यह उस प्रोब के लिए एक एस्टेरिस्क प्रिंट करता है।
गंतव्य होस्ट पर UDP प्रोब-पैकेट प्रोसेसिंग को भारी होने से रोकने के लिए, traceroute गंतव्य पोर्ट को एक ऐसे मान पर सेट करता है जिसका उपयोग डिवाइस द्वारा किए जाने की संभावना नहीं है। यदि गंतव्य पर कोई नेटवर्क या सेवा उस पोर्ट का उपयोग करती है, तो -p फ्लैग का उपयोग करके मान बदलें।
Traceroute परिणाम उदाहरण
एक नमूना उपयोग और आउटपुट इस उदाहरण के समान परिणाम लौटाएगा:
[yak 71]% traceroute nis.nsf.net. traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 38 byte packet 1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms 9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms 10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms
साइलेंट गेटवे उदाहरण
एक अधिक दिलचस्प उदाहरण है:
[yak 72]% traceroute allspice.lcs.mit.edu. traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max 1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms 5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms 8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms 9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms 10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms 11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms 12 * * * 13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms
ध्यान दें कि 12, 14, 15, 16, और 17 हॉप दूर के गेटवे या तो ICMP "टाइम एक्सीडेड" संदेश नहीं भेजते हैं या उन्हें TTL के साथ भेजते हैं जो हम तक पहुंचने के लिए बहुत छोटा है। लाइन 14 से 17 MIT C गेटवे कोड चला रहे हैं जो "टाइम एक्सीडेड" संदेश नहीं भेजते हैं।
उपरोक्त उदाहरण में साइलेंट गेटवे 12 4.[23]BSD नेटवर्क कोड और इसके डेरिवेटिव में एक बग का परिणाम हो सकता है: 4.3 कोड और पहले चलने वाली मशीनें मूल डेटाग्राम में शेष TTL का उपयोग करके एक अप्राप्य संदेश भेजती हैं। गेटवे के लिए, शेष TTL शून्य है, ICMP "टाइम एक्सीडेड" के हम तक वापस आने की गारंटी नहीं है।
गंतव्य सिस्टम साइलेंट गेटवे उदाहरण
जब यह गंतव्य सिस्टम पर दिखाई देता है तो इस बग का व्यवहार थोड़ा अधिक दिलचस्प होता है:
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms 6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms !
ध्यान दें कि 12 "गेटवे" मौजूद हैं (13 अंतिम गंतव्य है), और उनमें से अंतिम आधे गायब हैं। वास्तव में क्या हो रहा है कि rip नामक सर्वर (Sun OS 3.5 चलाने वाला Sun-3) हमारे आने वाले डेटाग्राम से TTL का उपयोग अपने ICMP उत्तर में TTL के रूप में कर रहा है। इसलिए, उत्तर वापसी पथ पर टाइम आउट हो जाएगा (किसी को कोई सूचना नहीं भेजी गई क्योंकि ICMPs के लिए ICMPs नहीं भेजे जाते) जब तक हम एक TTL के साथ प्रोब नहीं करते जो पथ लंबाई से कम से कम दोगुना हो - दूसरे शब्दों में, rip वास्तव में केवल सात हॉप दूर है।
TTL 1 के साथ वापस आने वाला उत्तर एक संकेत है कि यह समस्या मौजूद है। Traceroute समय के बाद एक ! प्रिंट करता है यदि TTL 1 से कम या बराबर है। चूंकि विक्रेता बहुत सारे अप्रचलित (DEC के Ultrix, Sun 3.x) या गैर-मानक (HPUX) सॉफ़्टवेयर शिप करते हैं, इस समस्या को अक्सर देखने की उम्मीद करें और अपने प्रोब के लक्ष्य होस्ट को चुनने में सावधानी बरतें।
समय के बाद अन्य संभावित एनोटेशन हैं !H, !N, या !P (होस्ट, नेटवर्क, या प्रोटोकॉल अप्राप्य), !S (स्रोत मार्ग विफल), !F- (खंडन आवश्यक - RFC1191 पथ MTU खोज मान प्रदर्शित होता है), !X (संचार प्रशासनिक रूप से निषिद्ध), !V (होस्ट प्रेसिडेंस उल्लंघन), !C (प्रेसिडेंस कटऑफ प्रभाव में), या ! (ICMP अप्राप्य कोड)। ये कोड RFC1812 द्वारा परिभाषित हैं, जो RFC1716 को प्रतिस्थापित करता है। यदि लगभग सभी प्रोब किसी प्रकार के अप्राप्य होस्ट में परिणाम देते हैं, तो traceroute हार मान लेगा और बाहर निकल जाएगा।
