كيفية استخدام الأمر 'traceroute' في لينكس

يتم استخدام أمر traceroute في Linux لتعيين الرحلة التي تتعهد بها حزمة من المعلومات من مصدرها إلى وجهتها. أحد الاستخدامات الخاصة بتتبع المسار هو تحديد مكان حدوث فقدان البيانات عبر الشبكة ، مما قد يشير إلى وجود عقدة معطلة.

نظرًا لأن كل قفزة في السجل تعكس خادمًا أو جهاز توجيه جديدًا بين الكمبيوتر الشخصي والهدف المقصود ، فإن مراجعة نتائج فحص traceroute يتيح لك أيضًا تحديد نقاط بطيئة قد تؤثر بشكل سلبي على حركة مرور الشبكة.

كيف تعمل

إن تقييم المسار المحدد الذي تتبعه حركة مرور الشبكة (أو العثور على بوابة الإغراق التي تتجاهل حزمك) يقدم العديد من تحديات استكشاف الأخطاء وإصلاحها. يستخدم Traceroute بروتوكول IP الوقت للعيش حقل لطلب رد مؤقت ICMP TIME_EXCEEDED من كل عبّارة على طول المسار إلى مضيف وجهة.

المعلمة الوحيدة التي يجب عليك تضمينها عند تنفيذ أمر traceroute هي اسم المضيف أو عنوان IP الخاص بالوجهة.

Traceroute بناء الجملة والمفاتيح

متتبع -dFInrvx -F first_ttl -g بوابة -أنا أواجه -m max_ttl -p ميناء -q nqueries -s src_addr -t ابتكر -w وقت الانتظار -z pausemsecs مضيف packetlen

بينما ما سبق هو كيفية كتابة أمر traceroute من أجل العمل في سطر الأوامر ، يمكن تغيير أداء أو إخراج الأمر عن طريق تحديد واحد أو أكثر من المفاتيح الاختيارية.

• -F: قم بتعيين مدة التشغيل الأولية المستخدمة في حزمة الفحص الصادرة الأولى.
• -F: اضبط الجزء "عدم التجزئة".
• -د: تمكين تصحيح مستوى المقبس.
• -g: حدد بوابة مسار مصدر فضفاضة (8 كحد أقصى).
• -أنا: حدد واجهة شبكة للحصول على عنوان IP المصدر لحزم الفحص الصادرة. هذا هو عادة مفيدة فقط على مضيف homed متعددة. (انظر-s العلم لطريقة أخرى للقيام بذلك.)
• -أنا: استخدم ICMP ECHO بدلاً من مخططات بيانات UDP.
• -m: اضبط أقصى مدة تشغيل (أقصى عدد من القفزات) المستخدمة في رزم المسبار الصادرة. الافتراضي هو 30 قفزة (نفس الافتراضي المستخدم لاتصالات TCP).
• -n: عناوين القفزات المطبوعة عدديًا بدلاً من الرمز والرقمية (يحفظ بحثًا عن اسم خادم الأسماء لكل بوابة موجودة في المسار).
• -p: تعيين رقم منفذ UDP الأساسي المستخدم في probes (الافتراضي هو 33434). يأمل Traceroute أن لا شيء يستمع على منافذ UDP قاعدة إلى قاعدة + nhops - 1 في المضيف الوجهة (لذلك سيتم إرجاع رسالة ICON PORT_UNREACHABLE إنهاء مسار التوجيه). إذا كان هناك شيء يستمع على منفذ في النطاق الافتراضي ، فيمكن استخدام هذا الخيار لاختيار نطاق منفذ غير مستخدم.
• -r: تجاوز جداول التوجيه العادية وإرسالها مباشرةً إلى مضيف على شبكة متصلة. إذا لم يكن المضيف على شبكة متصلة مباشرة ، يتم إرجاع خطأ. يمكن استخدام هذا الخيار لإجراء اختبار ping لمضيف محلي من خلال واجهة لا تتضمن مسارًا (على سبيل المثال ، بعد أن تم إسقاط الواجهة بواسطة توجيه (8C)).
• -s: استخدم عنوان IP التالي (والذي يتم إعطاؤه عادة كرقم IP ، وليس اسم مضيف) كعنوان المصدر في حزم الفحص الصادرة. على المضيفات متعددة homed (تلك التي تحتوي على أكثر من عنوان IP واحد) ، يمكن استخدام هذا الخيار لفرض عنوان المصدر أن يكون شيء آخر غير عنوان IP للواجهة يتم إرسال حزمة الفحص. إذا لم يكن عنوان IP واحدًا من عناوين واجهة هذا الجهاز ، فسيتم إرجاع الخطأ ولن يتم إرسال أي شيء. (انظر-أنا العلم لطريقة أخرى للقيام بذلك.)
• -t: تعيين نوع الخدمة في الحزم اختبار إلى القيمة التالية (الافتراضي صفر). يجب أن تكون القيمة عددًا صحيحًا عشريًا في النطاق من 0 إلى 255. يمكن استخدام هذا الخيار لمعرفة ما إذا كان هناك أنواع مختلفة من الخدمات تؤدي إلى مسارات مختلفة. (إذا لم تكن قيد التشغيل 4.4bsd ، فقد يكون ذلك أكاديميًا ، نظرًا لأن خدمات الشبكة العادية مثل telnet و ftp لا تسمح لك بالتحكم في TOS.) ليست كل قيم TOS قانونية أو ذات معنى - راجع مواصفات IP للتعريفات. القيم المفيدة هي على الارجح-t 16 (تأخير منخفض) و-t 8 (إنتاجية عالية).
• -الخامس: إخراج مطول. يتم سرد الحزم المستلمة ICMP غير TIME_EXCEEDED و UNREACHABLEs.
• -w: اضبط الوقت (بالثواني) لانتظار استجابة للمسبار (الافتراضي 5 ثوان).
• -x: تبديل اختباري IP. عادة ، هذا يمنع traceroute من حساب checksums IP. في بعض الحالات ، يمكن لنظام التشغيل الكتابة فوق أجزاء من الحزمة الصادرة ولكن لا يعيد حساب المجموع الاختباري ؛ وبالتالي ، في بعض الحالات الافتراضي هو عدم حساب الاختباري واستخدام-x يسبب لهم أن يحسب. لاحظ أنه عادةً ما تكون مطلوبة checksums للحدث الأخير عند استخدام تحقيقات ICMP ECHO (-أنا) ، لذلك يتم حسابها دائمًا عند استخدام ICMP.
• -z: تعيين الوقت (بالمللي ثانية) للتوقف بين probes (افتراضي 0). بعض الأنظمة مثل Solaris وأجهزة التوجيه من Cisco ، رسائل ICMP حد المعدل. قيمة جيدة للاستخدام مع هذا 500 (على سبيل المثال ، 1/2 ثانية).

تفسير النتائج

يحدد مسار traceroute المسار الذي تتبعه حزمة IP إلى مضيف الإنترنت عن طريق تشغيل حزم فحص UDP مع TTL صغير (وقت للعيش) ثم الاستماع إلى وقت "تجاوز" ICMP للرد من العبّارة. نبدأ تحقيقاتنا مع TTL من واحد وزيادة واحد حتى نحصل على "منفذ الوصول ICMP" (مما يعني أن الحزمة وصلت إلى وجهتها) أو تصل إلى قيمة الحد الأقصى من المحاولات ، والتي تعترض إلى 30 قفزة ويمكن تغييرها مع ال-m العلم.

عند تنفيذ traceroute ، يرسل ثلاثة تحقيقات في كل إعداد TTL ، ثم يطبع سطرًا إلى وحدة التحكم يعرض TTL ، وعنوان البوابة ، والوقت المستدير لكل مسبار. إذا كانت إجابات المسبار تأتي من بوابات مختلفة ، فإن عنوان كل نظام استجابة يطبع. إذا لم يكن هناك استجابة في غضون فترة زمنية مدتها خمس ثوان (تغيرت مع-w العلم) ، تتم طباعة علامة النجمة لهذا التحقيق.

لتحول دون استيفاء مضيف الوجهة بواسطة معالجة حزمة فحص بروتوكول UDP ، يتم تعيين منفذ الوجهة على قيمة من غير المحتمل أن يستخدمها هذا الجهاز. إذا كانت الشبكة أو الخدمة في الوجهة تستخدم المنفذ ، فقم بتغيير القيمة باستخدام-p العلم.

سيؤدي استخدام العينة والإخراج إلى نتائج مشابهة لهذا المثال:

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

لاحظ أن الخطوط الثانية والثالثة هي نفسها. ترتبط هذه النتيجة بنواة عربات التي تجرها الدواب على نظام القفزة الثاني lbl-csam.arpa ، الذي يعيد توجيه الحزم ذات TTL صفر (خطأ في النسخة الموزعة من 4.3 BSD). يجب عليك أن تخمن المسار الذي تسلكه الحزم عبر البلاد نظرًا لأن NSFNet (129.140) لا تقدم ترجمات العنوان إلى اسم من أجل NSSes.

مثال أكثر إثارة للاهتمام هو:

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 مللي 279 مللي 279 مللي ثانية

لاحظ أن العبّارات عند 12 و 14 و 15 و 16 و 17 قفزة إما لا ترسل رسائل "تجاوز الوقت" لـ ICMP أو ترسلها مع TTL صغير جدًا للوصول إلينا. تقوم السطور من 14 إلى 17 بتشغيل كود MIT C Gateway الذي لا يرسل رسائل "تجاوز الوقت".

قد تكون البوابة الصامتة 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 الآنسة ! 39 مللي! 39 مللي!

لاحظ أن هناك 12 "بوابات" (13 هي الوجهة النهائية) ، والنصف الأخير منها مفقود. ما يحدث حقا هو أن الخادم المسمى RIP (Sun-3 running Sun OS 3.5) يستخدم TTL من مخطط البيانات الذي توصلنا إليه باعتباره TTL في الرد على ICMP. لذا ، فإن الرد سوف ينتهي على مسار العودة (مع عدم إرسال أي إشعار إلى أي شخص لأن ICMP لا يتم إرساله إلى ICMP) حتى نتحقق من TTL وهو ضعف طول المسار على الأقل - بعبارة أخرى ، التمزق هو في الحقيقة سبعة فقط يقفز بعيدا.

يعد الرد الذي يتم إرجاعه باستخدام TTL من 1 دليلاً على وجود هذه المشكلة. Traceroute يطبع "!" بعد الوقت إذا كان TTL أقل من أو يساوي 1. بما أن البائعين يشحنون الكثير من الأجهزة القديمة (DEC's Ultrix أو Sun 3.x) أو برنامج غير قياسي (HPUX) ، فنتوقع أن ترى هذه المشكلة بشكل متكرر وتنتبه إلى اختيار المضيف الهدف من المسابر الخاصة بك.

التعليقات التوضيحية الأخرى المحتملة بعد مرور الوقت! H, ! Nأو! P (المضيف أو الشبكة أو البروتوكول غير قابلة للوصول) ،! S (فشل مسار المصدر) ،!F- (التجزئة المطلوبة - يتم عرض قيمة RFC1191 Path MTU Discovery) ،! X (يحظر الاتصال من الإدارة) ،!الخامس (انتهاك الأسبقية للمضيف) ،! C (قطع الأسبقية في الواقع) ، أو! (رمز ICMP لا يمكن الوصول إليه). يتم تعريف هذه الرموز بواسطة RFC1812 ، والذي يحل محل RFC1716. إذا أسفرت جميع التحقيقات تقريبًا عن نوع ما من المضيف الذي لا يمكن الوصول إليه ، فسيتوقف traceroute ويخرج.

هذا البرنامج معد للاستخدام في اختبار الشبكة وقياسها وإدارتها. يجب استخدامه في المقام الأول لعزل الخطأ اليدوي. بسبب الحمل الذي يمكن أن تفرضه على الشبكة ، من غير الحكمة استخدام traceroute أثناء العمليات العادية أو من البرامج النصية الآلية.