คำสั่ง Traceroute สำหรับ Linux

ข้อควรรู้

พารามิเตอร์เดียวที่คุณต้องรวมไว้ในคำสั่ง traceroute คือชื่อโฮสต์หรือที่อยู่ IP ของปลายทาง
เริ่มโพรบด้วย TTL หนึ่งและเพิ่มขึ้นทีละหนึ่งจนกว่าคุณจะได้รับ "พอร์ตที่ไม่สามารถเข้าถึงได้" ของ ICMP หรือถึงค่าสูงสุดของความพยายาม

บทความนี้ครอบคลุมข้อมูลการติดตามที่ใช้กับเครื่อง Linux และรวมถึงคำอธิบายสวิตช์คำสั่งพร้อมข้อมูลเกี่ยวกับวิธีการตีความผลลัพธ์ Traceroute ใช้ต่างกันใน Windows

วิธีการทำงานของ Traceroute

คำสั่ง traceroute แม็พการเดินทางที่แพ็กเก็ตข้อมูลดำเนินการจากต้นทางไปยังปลายทาง การใช้งานแบบหนึ่งสำหรับ traceroute คือการระบุตำแหน่งเมื่อข้อมูลสูญหายทั่วทั้งเครือข่าย ซึ่งอาจหมายถึงโหนดที่หยุดทำงาน

เนื่องจากการกระโดดแต่ละครั้งในบันทึกสะท้อนถึงเซิร์ฟเวอร์หรือเราเตอร์ใหม่ระหว่างพีซีต้นทางและเป้าหมายที่ต้องการ การตรวจสอบผลลัพธ์ของการสแกนตามเส้นทางจะระบุจุดที่ช้าซึ่งอาจส่งผลเสียต่อการรับส่งข้อมูลเครือข่ายของคุณ

การแก้ไขปัญหาด้วย Traceroute

การประเมินเส้นทางเฉพาะที่ทราฟฟิกเครือข่ายติดตาม (หรือการค้นหาเกตเวย์ miscreant ที่ทิ้งแพ็กเก็ตของคุณ) นำเสนอความท้าทายในการแก้ไขปัญหาหลายประการ Traceroute ใช้โปรโตคอล IP เวลาใช้ชีวิต เพื่อร้องขอการตอบกลับ ICMP TIME_EXCEEDED จากแต่ละเกตเวย์ตามเส้นทางไปยังโฮสต์ปลายทาง

พารามิเตอร์เดียวที่คุณต้องระบุเมื่อคุณรันคำสั่ง 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 ]

คุณเปลี่ยนประสิทธิภาพหรือเอาต์พุตของคำสั่งได้โดยระบุสวิตช์เสริมอย่างน้อย 1 ตัว

สวิตช์คำสั่ง Traceroute สวิตช์ คำอธิบาย -f ตั้งค่า time-to-live เริ่มต้นที่ใช้ในแพ็กเก็ตโพรบขาออกแรก-F ตั้งค่าบิต "ไม่แตก"-d เปิดใช้งานการดีบักระดับซ็อกเก็ต-g ระบุเกตเวย์เส้นทางต้นทางที่หลวม (สูงสุด 8)-i ระบุอินเทอร์เฟซเครือข่ายเพื่อรับที่อยู่ IP ต้นทางสำหรับแพ็คเก็ตโพรบขาออก โดยปกติแล้วจะมีประโยชน์เฉพาะกับโฮสต์แบบหลายบ้านเท่านั้น (ดู -s ตั้งค่าสถานะสำหรับวิธีอื่นในการทำเช่นนี้)-I ใช้ ICMP ECHO แทนดาตาแกรม UDP-m ตั้งค่า time-to-live สูงสุด (จำนวนฮ็อพสูงสุด) ที่ใช้ในแพ็กเก็ตโพรบขาออก ค่าดีฟอลต์คือ 30 ฮ็อพ (ค่าดีฟอลต์เดียวกับที่ใช้สำหรับการเชื่อมต่อ TCP)-n พิมพ์ที่อยู่ฮ็อพเป็นตัวเลขแทนที่จะเป็นสัญลักษณ์และตัวเลข (บันทึกการค้นหาที่อยู่ต่อชื่อเซิร์ฟเวอร์เนมเซิร์ฟเวอร์สำหรับแต่ละเกตเวย์ที่พบในเส้นทาง)-p ตั้งค่าหมายเลขพอร์ต UDP พื้นฐานที่ใช้ในโพรบ (ค่าเริ่มต้นคือ 33434) Traceroute หวังว่าจะไม่มีอะไรฟังบนพอร์ต UDP base ถึง เบส + nhops - 1 ที่โฮสต์ปลายทาง (ดังนั้น ข้อความ ICMP PORT_UNREACHABLE จะถูกส่งคืนเพื่อยุติการติดตามเส้นทาง) หากมีบางอย่างกำลังฟังพอร์ตในช่วงเริ่มต้น สามารถใช้ตัวเลือกนี้เพื่อเลือกช่วงพอร์ตที่ไม่ได้ใช้-r ข้ามตารางเส้นทางปกติและส่งตรงไปยังโฮสต์บนเครือข่ายที่เชื่อมต่อ หากโฮสต์ไม่ได้อยู่บนเครือข่ายที่เชื่อมต่อโดยตรง ข้อผิดพลาดจะถูกส่งคืน สามารถใช้ตัวเลือกนี้เพื่อ ping โฮสต์ในเครื่องผ่านอินเทอร์เฟซที่ไม่มีเส้นทางผ่าน (เช่น หลังจากที่อินเทอร์เฟซถูกลบโดยกำหนดเส้นทาง (8C)).-s ใช้ที่อยู่ IP ต่อไปนี้ (ซึ่งโดยปกติแล้วจะเป็นหมายเลข IP ไม่ใช่ชื่อโฮสต์) เป็นที่อยู่ต้นทางในแพ็กเก็ตโพรบขาออก บนโฮสต์แบบ multi-homed (ที่มีมากกว่าหนึ่งที่อยู่ IP) ตัวเลือกนี้สามารถใช้เพื่อบังคับให้ที่อยู่ต้นทางเป็นอย่างอื่นนอกเหนือจากที่อยู่ IP ของอินเทอร์เฟซที่ส่งแพ็คเก็ตโพรบ หากที่อยู่ IP ไม่ใช่ที่อยู่อินเทอร์เฟซเครื่องใดที่อยู่หนึ่ง ข้อผิดพลาดจะถูกส่งคืนและไม่มีการส่งข้อมูลใดๆ (ดู -i ตั้งค่าสถานะสำหรับวิธีอื่นในการทำเช่นนี้)-t ตั้งค่า ประเภทของบริการ ในแพ็กเก็ตโพรบเป็นค่าต่อไปนี้ (ศูนย์เริ่มต้น) ค่าต้องเป็นจำนวนเต็มทศนิยมในช่วง 0 ถึง 255 สามารถใช้ตัวเลือกนี้เพื่อดูว่าบริการประเภทต่างๆ ส่งผลให้เกิดพาธต่างกันหรือไม่ (หากคุณไม่ได้ใช้ 4.4bsd นี่อาจเป็นเรื่องวิชาการ เนื่องจากบริการเครือข่ายปกติ เช่น telnet และ ftp ไม่อนุญาตให้คุณควบคุม TOS) ค่า TOS บางอย่างอาจไม่ถูกกฎหมายหรือมีความหมาย—ดูข้อกำหนด IP สำหรับคำจำกัดความ ค่าที่มีประโยชน์น่าจะเป็น `-t 16 ' (ดีเลย์ต่ำ) และ `-t 8 ' (ปริมาณงานสูง)-v เอาต์พุตแบบละเอียด แพ็กเก็ต ICMP ที่ได้รับนอกเหนือจาก TIME_EXCEEDED และ UNREACHABLE อยู่ในรายการ-w ตั้งเวลา (เป็นวินาที) เพื่อรอการตอบสนองต่อโพรบ (ค่าเริ่มต้น 5 วินาที)-x สลับการตรวจสอบ IP โดยปกติ สิ่งนี้จะป้องกันไม่ให้ traceroute คำนวณเช็คซัม IP ในบางกรณี ระบบปฏิบัติการสามารถเขียนทับส่วนของแพ็กเก็ตขาออกได้ แต่ไม่สามารถคำนวณเช็คซัมใหม่ได้ ดังนั้น ในบางกรณี ค่าเริ่มต้นคือไม่คำนวณเช็คซัมและใช้ -x ทำให้เกิดการคำนวณ โปรดทราบว่ามักจะต้องใช้เช็คซัมสำหรับการฮอปสุดท้ายเมื่อใช้โพรบ ICMP ECHO (-I ) ดังนั้นจึงคำนวณเสมอเมื่อใช้ ICMP-z ตั้งเวลา (เป็นมิลลิวินาที) เพื่อหยุดชั่วคราวระหว่างโพรบ (ค่าเริ่มต้น 0) ระบบบางระบบ เช่น Solaris และเราเตอร์จาก Cisco อัตราข้อความ icmp ที่จำกัด ความคุ้มค่าที่จะใช้กับสิ่งนี้คือ 500 (เช่น 1/2 วินาที)

การตีความผลลัพธ์

Traceroute กำหนดเส้นทางของแพ็กเก็ต IP ที่ติดตามไปยังอินเทอร์เน็ตโฮสต์โดยเรียกใช้แพ็กเก็ตโพรบ UDP ด้วย TTL ขนาดเล็ก จากนั้นรับฟังการตอบกลับ "เกินเวลา" ของ ICMP จากเกตเวย์ เริ่มโพรบด้วย TTL หนึ่งและเพิ่มขึ้นทีละหนึ่งจนกว่าคุณจะได้รับ "พอร์ตที่ไม่สามารถเข้าถึงได้" ของ ICMP (ซึ่งหมายความว่าแพ็กเก็ตมาถึงที่ปลายทาง) หรือถึงค่าสูงสุดของความพยายามซึ่งมีค่าเริ่มต้นเป็น 30 ฮ็อป และสามารถเปลี่ยนแปลงได้โดยใช้ <แข็งแกร่ง>-ม ธง.

เมื่อ 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

บรรทัดที่สองและสามเหมือนกัน ผลลัพธ์นี้เกี่ยวข้องกับเคอร์เนลแบบบั๊กกี้บนระบบฮ็อพที่สอง—lbl-csam.arpa—ที่ส่งต่อแพ็กเก็ตที่มี TTL เป็นศูนย์ (ข้อบกพร่องในเวอร์ชันแจกจ่าย 4.3 BSD) คุณต้องเดาว่าแพ็กเก็ตใช้เส้นทางใดข้ามประเทศ เนื่องจาก NSFNet (129.140) ไม่ได้จัดเตรียมการแปลที่อยู่เป็นชื่อสำหรับ NSS

ตัวอย่าง Silent Gateway

ตัวอย่างที่น่าสนใจกว่าคือ:

[แยก 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (18.26.0.115), สูงสุด 30 ฮ็อป
 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 มิลลิวินาที

โปรดทราบว่าเกตเวย์ที่ 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.2216.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 ms !

สังเกตว่ามี "เกตเวย์" 12 แห่ง (13 เป็นปลายทางสุดท้าย) และครึ่งหลังหายไป สิ่งที่เกิดขึ้นจริงคือเซิร์ฟเวอร์ชื่อ rip (Sun-3 ที่ใช้ Sun OS 3.5) กำลังใช้ TTL จากดาตาแกรมที่เรามาถึงเป็น TTL ในการตอบกลับ ICMP ดังนั้นการตอบกลับจะหมดเวลาบนเส้นทางขากลับ (โดยไม่มีการส่งการแจ้งเตือนถึงใครเลย เนื่องจากไม่มีการส่ง ICMP สำหรับ ICMP) จนกว่าเราจะตรวจสอบด้วย TTL ที่มีความยาวเส้นทางอย่างน้อยสองเท่า—กล่าวอีกนัยหนึ่งคือ rip มีเพียงเจ็ดเท่านั้น กระโดดออกไป

คำตอบที่ส่งคืนด้วย TTL เท่ากับ 1 เป็นการบ่งชี้ว่าปัญหานี้มีอยู่ Traceroute พิมพ์ ! หลังจากนั้น หาก TTL น้อยกว่าหรือเท่ากับ 1 เนื่องจากผู้ขายจัดส่งซอฟต์แวร์ที่ล้าสมัย (DEC's Ultrix, Sun 3.x) หรือที่ไม่ได้มาตรฐาน (HPUX) จำนวนมาก คาดว่าจะพบปัญหานี้บ่อยครั้งและระมัดระวังในการเลือก กำหนดเป้าหมายโฮสต์ของโพรบของคุณ

คำอธิบายประกอบที่เป็นไปได้อื่นๆ หลังจากเวลาผ่านไปคือ !H , !N , หรือ !P (โฮสต์ เครือข่าย หรือโปรโตคอลไม่สามารถเข้าถึงได้), !S (เส้นทางต้นทางล้มเหลว), !F- (จำเป็นต้องแยกส่วน—ค่า RFC1191 Path MTU Discovery จะแสดง), !X (ห้ามใช้ในการสื่อสาร) !V (การละเมิดลำดับความสำคัญของโฮสต์), !C (มีผลใช้ตัดลำดับความสำคัญ) หรือ ! (รหัสที่ไม่สามารถเข้าถึงได้ ICMP) รหัสเหล่านี้กำหนดโดย RFC1812 ซึ่งแทนที่ RFC1716 หากการตรวจสอบเกือบทั้งหมดส่งผลให้โฮสต์บางประเภทไม่สามารถเข้าถึงได้ traceroute จะยกเลิกและออก

โปรแกรมนี้จัดทำขึ้นเพื่อใช้ในการทดสอบ การวัด และการจัดการเครือข่าย ควรใช้เป็นหลักสำหรับการแยกข้อผิดพลาดด้วยตนเอง เนื่องจากภาระงานที่เกิดขึ้นในเครือข่าย จึงไม่ฉลาดที่จะใช้ Traceroute ระหว่างการทำงานปกติหรือจากสคริปต์อัตโนมัติ