คำสั่ง traceroute ใช้ใน Linux เพื่อกำหนดเส้นทางการเดินทางที่แพ็คเก็ตข้อมูลรับจากแหล่งข้อมูลไปยังจุดหมายปลายทาง การใช้งานหนึ่งสำหรับ traceroute คือการระบุตำแหน่งเมื่อข้อมูลสูญหายเกิดขึ้นทั่วทั้งเครือข่ายซึ่งอาจหมายถึงโหนดที่ไม่ทำงาน
เนื่องจากแต่ละการบันทึกในเร็กคอร์ดจะแสดงเซิร์ฟเวอร์หรือเราเตอร์ใหม่ระหว่างพีซีต้นทางกับเป้าหมายที่ตั้งใจไว้การตรวจสอบผลลัพธ์ของการสแกน traceroute จะช่วยให้คุณระบุจุดที่ช้าซึ่งอาจส่งผลต่อการรับส่งข้อมูลเครือข่ายของคุณ
มันทำงานอย่างไร
การประเมินเส้นทางเฉพาะที่การรับส่งข้อมูลเครือข่าย (หรือค้นหาเกตเวย์ที่ไม่เหมาะสมซึ่งทิ้งแพ็คเก็ตของคุณ) แสดงถึงความท้าทายในการแก้ไขปัญหาต่างๆ Traceroute ใช้โปรโตคอล IP เวลาที่จะมีชีวิตอยู่ เพื่อขอรับการตอบสนอง ICMP TIME_EXCEEDED จากเกตเวย์แต่ละแห่งตามเส้นทางไปยังโฮสต์ปลายทาง
พารามิเตอร์เดียวที่คุณต้องมีเมื่อคุณรันคำสั่ง traceroute คือชื่อโฮสต์หรือที่อยู่ IP ของปลายทาง
ไวยากรณ์และสวิตช์ Traceroute
traceroute -dFInrvx -f first_ttl -G ประตู -ผม iface -m max_ttl -p ท่าเรือ -q nqueries -s src_addr t- การชำระเงิน -w รอเวลา -z pausemsecs เจ้าภาพ packetlen
ในขณะที่ข้างต้นเป็นวิธีที่คำสั่ง traceroute ต้องถูกเขียนขึ้นเพื่อที่จะทำงานในบรรทัดคำสั่งประสิทธิภาพหรือผลลัพธ์ของคำสั่งสามารถเปลี่ยนแปลงได้โดยระบุสวิตช์ตัวเลือกอย่างน้อยหนึ่งรายการ
- -f: ตั้งเวลาเริ่มต้นในการใช้งานครั้งแรกในแพ็กเก็ต probe ขาออก
- -F: ตั้งค่าบิต "ไม่แบ่งส่วน"
- -d: เปิดใช้งานดีบักระดับซ็อกเก็ต
- -g: ระบุเกตเวย์เส้นทางหลวม (8 สูงสุด)
- -ผม: ระบุอินเทอร์เฟซเครือข่ายเพื่อขอรับที่อยู่ IP ต้นทางสำหรับแพ็กเก็ต probe ขาออก นี่เป็นเรื่องปกติที่มีประโยชน์เฉพาะกับโฮสต์แบบ multi-homed เท่านั้น (ดู-s ธงวิธีอื่นในการทำเช่นนี้)
- -ผม: ใช้ ICMP ECHO แทน datagrams UDP
- -m: ตั้งเวลาสูงสุดที่จะมีชีวิต (จำนวนสูงสุดของ hops) ที่ใช้ในการส่งแพ็กเก็ตออก ค่าดีฟอลต์คือ 30 hops (ค่าดีฟอลต์เดียวกันสำหรับการเชื่อมต่อ TCP)
- -n: พิมพ์ที่อยู่ hop แทนตัวเลขและตัวเลข (บันทึกการค้นหาที่อยู่ชื่อของ nameserver สำหรับแต่ละเกตเวย์ที่พบในเส้นทาง)
- -p: ตั้งค่าหมายเลขพอร์ต UDP พื้นฐานที่ใช้ในการตรวจสอบ (ค่าเริ่มต้นคือ 33434) Traceroute หวังว่าไม่มีอะไรจะฟังในพอร์ต UDP ฐาน ไปยัง base + nhops - 1 ที่โฮสต์ปลายทาง (ดังนั้นข้อความ ICMP PORT_UNREACHABLE จะถูกส่งกลับเพื่อยุติเส้นทางการสืบค้นกลับเส้นทาง) หากมีฟังอะไรอยู่ในพอร์ตในช่วงเริ่มต้นตัวเลือกนี้สามารถใช้เพื่อเลือกช่วงพอร์ตที่ไม่ได้ใช้
- -r: หลีกเลี่ยงตารางเส้นทางปกติและส่งตรงไปยังโฮสต์ในเครือข่ายที่แนบมา ถ้าโฮสต์ไม่อยู่ในเครือข่ายที่แนบมาโดยตรงข้อผิดพลาดจะถูกส่งกลับ คุณสามารถใช้ตัวเลือกนี้เพื่อ ping โฮสต์ภายในผ่านอินเทอร์เฟซที่ไม่มีเส้นทางผ่าน (เช่นหลังจากอินเตอร์เฟสถูกทิ้งโดย เส้นทาง (8C))
- -s: ใช้ที่อยู่ IP ต่อไปนี้ (โดยปกติจะเป็นหมายเลข IP ไม่ใช่ชื่อโฮสต์) เป็นที่อยู่ต้นทางในแพ็กเก็ต probe ขาออก ในโฮสต์ multi-homed (ผู้ที่มีที่อยู่ IP มากกว่าหนึ่งแห่ง) ตัวเลือกนี้สามารถใช้เพื่อบังคับให้ที่อยู่ต้นทางเป็นสิ่งอื่นที่ไม่ใช่ที่อยู่ IP ของอินเทอร์เฟซที่มีการส่งแพ็กเก็ต probe ถ้าที่อยู่ IP ไม่ใช่ที่อยู่ติดต่อของเครื่องนี้ข้อผิดพลาดจะถูกส่งกลับและไม่มีการส่งอะไร (ดู-ผม ธงวิธีอื่นในการทำเช่นนี้)
- t-: ตั้งค่า พิมพ์การให้บริการ ในแพ็คเก็ต probe ไปยังค่าต่อไปนี้ (ค่าเริ่มต้นเป็นศูนย์) ค่าต้องเป็นจำนวนเต็มทศนิยมในช่วง 0 ถึง 255 ตัวเลือกนี้สามารถใช้เพื่อดูว่าผลการบริการประเภทต่างๆในเส้นทางต่างๆหรือไม่ (ถ้าคุณไม่ได้ใช้งาน 4.4bsd อาจเป็นเรื่องเกี่ยวกับการศึกษาเนื่องจากบริการเครือข่ายตามปกติเช่น telnet และ ftp ไม่อนุญาตให้คุณควบคุม TOS) ค่าทั้งหมดของ TOS ไม่ถูกต้องตามกฎหมายหรือมีความหมายให้ดูที่ข้อกำหนด IP สำหรับคำจำกัดความ ค่าที่เป็นประโยชน์อาจเป็น `t- 16 '(ล่าช้าต่ำ) และ `t- 8 '(throughput สูง)
- -v: เอาท์พุท Verbose ได้รับแพคเก็ต ICMP ที่ไม่ใช่ TIME_EXCEEDED และ UNREACHABLEs แล้ว
- -w: ตั้งเวลา (เป็นวินาที) เพื่อรอการตอบสนองต่อโพรบ (ค่าเริ่มต้น 5 วินาที)
- -x: สลับการตรวจสอบ IP checksum โดยปกติการทำเช่นนี้จะป้องกัน traceroute จากการคำนวณ checksums ของ IP ในบางกรณีระบบปฏิบัติการสามารถเขียนทับส่วนของแพ็คเก็ตขาออกได้ แต่จะไม่สามารถคำนวณใหม่ได้ ดังนั้นในบางกรณีค่าเริ่มต้นคือการไม่คำนวณ checksums และใช้-x ทำให้พวกเขาถูกคำนวณ โปรดทราบว่า checksums มักจำเป็นสำหรับการกระโดดครั้งสุดท้ายเมื่อใช้ ICMP ECHO probes (-ผม) ดังนั้นจึงมีการคำนวณเมื่อใช้ ICMP เสมอ
- -z: กำหนดเวลา (เป็นมิลลิวินาที) เพื่อหยุดชั่วคราวระหว่างการตรวจจับ (ค่าเริ่มต้น 0) บางระบบเช่น Solaris และเราเตอร์จากซิสโก้ข้อความ ICMP limit rate ค่าที่ดีที่จะใช้กับค่านี้คือ 500 (เช่น 1/2 วินาที)
การตีความผลลัพธ์
Traceroute แสดงเส้นทางของแพ็คเก็ต IP ดังต่อไปนี้ไปยังโฮสต์อินเทอร์เน็ตโดยการเปิดใช้แพ็กเก็ต UDP probe กับ TTL ขนาดเล็ก (เวลาที่จะอยู่) จากนั้นฟังข้อความตอบกลับ "time exceeded" ของ ICMP จากเกตเวย์ เราเริ่มต้นการตรวจสอบของเราด้วย TTL หนึ่งครั้งและเพิ่มขึ้นหนึ่งครั้งจนกว่าเราจะได้รับพอร์ต ICMP "ไม่สามารถเข้าถึงได้" (หมายถึงแพ็คเก็ตมาถึงจุดหมายปลายทาง) หรือกดค่าความพยายามสูงสุดซึ่งมีค่าเริ่มต้น 30 ก้าวและสามารถเปลี่ยนแปลงได้ด้วย-m ธง.
เมื่อ traceroute ดำเนินการจะส่งสาม probes ที่ตั้ง TTL แต่ละครั้งแล้วพิมพ์บรรทัดไปยังคอนโซลแสดง TTL ที่อยู่ของเกตเวย์และเวลา round-trip ของแต่ละ probe ถ้าคำตอบของหัววัดมาจากเกตเวย์อื่น ๆ ระบบจะพิมพ์ที่อยู่ของแต่ละระบบตอบกลับ หากไม่มีการตอบสนองภายในช่วงหมดเวลาห้าวินาที (เปลี่ยนด้วย-w ธง) เครื่องหมายดอกจันถูกพิมพ์สำหรับการสอบสวนนั้น
เพื่อป้องกันไม่ให้โฮสต์ปลายทางถูกครอบงำด้วยโพรเซสแพ็คเก็ต UDP โปรโตคอล UDP ปลายทางพอร์ตถูกตั้งค่าเป็นค่าที่ไม่น่าจะใช้โดยอุปกรณ์ดังกล่าว หากเครือข่ายหรือบริการที่ปลายทางใช้พอร์ตดังกล่าวให้เปลี่ยนค่าโดยใช้ปุ่ม-p ธง.
ตัวอย่างการใช้และผลลัพธ์จะแสดงผลลัพธ์ที่คล้ายคลึงกับตัวอย่างนี้:
yak 71% traceroute nis.nsf.net traceroute ไปที่ 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-c.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
โปรดทราบว่าบรรทัดที่สองและสามเหมือนกัน ผลลัพธ์นี้เกี่ยวข้องกับเคอร์เนลที่มีปัญหาในระบบ hop ที่สอง lbl-csam.arpa ซึ่งจะส่งต่อแพ็คเก็ตด้วย TTL เป็นศูนย์ (bug ในเวอร์ชันแจกแจง 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 มิลลิวินาที 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 มิลลิวินาที 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 hops จะไม่ส่งข้อความ "เกินเวลา" ของ ICMP หรือส่งข้อมูลด้วย TTL เล็กเกินไปที่จะเข้าถึงเรา บรรทัดที่ 14 ถึง 17 กำลังเรียกใช้รหัส CMS ของ MIT C Gateway ที่ไม่ได้ส่งข้อความ "time exceeded"
เกตเวย์เงียบ 12 ในตัวอย่างข้างต้นอาจเป็นผลมาจากข้อผิดพลาดในรหัสเครือข่าย 4. 23 BSD และอนุพันธ์: เครื่องที่ใช้รหัส 4.3 และก่อนหน้านี้จะส่งข้อความที่ไม่สามารถเข้าถึงได้โดยใช้สิ่งที่ TTL ยังคงอยู่ในดาต้าต้นฉบับ เนื่องจากสำหรับเกตเวย์ TTL ที่เหลือจะเป็นศูนย์ ICMP "time exceeded" จึงรับประกันได้ว่าจะไม่ทำให้เรากลับมาหาเรา พฤติกรรมของข้อผิดพลาดนี้ดูน่าสนใจเล็กน้อยเมื่อปรากฏในระบบปลายทาง:
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 มิลลิวินาที 19 ms 39 ms 3 lilac-dmc.Berkeley.EDU (128.32.216.1 ) 19 ms 39 ms 19 ms 4 ccngw-ner-c.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 ms! 39 ms!
สังเกตว่ามี 12 เกตเวย์ (13 เป็นจุดหมายปลายทางสุดท้าย) และครึ่งหลังของพวกเขาหายไป สิ่งที่เกิดขึ้นจริงๆคือเซิร์ฟเวอร์ชื่อ ฉีก (Sun-3 ที่รัน Sun OS 3.5) กำลังใช้ TTL จากเดตาแกรมของเราในฐานะ TTL ในการตอบกลับของ ICMP ดังนั้นการตอบกลับจะหมดเวลาในเส้นทางกลับ (โดยไม่ต้องแจ้งให้ผู้อื่นทราบเนื่องจาก ICMPs จะไม่ถูกส่งไปยัง ICMPs) จนกว่าเราจะสอบสวนด้วย TTL ที่มีความยาวอย่างน้อยสองเท่าของความยาวของเส้นทาง - กล่าวคือการฉีกเป็นเพียงเจ็ด กระโดดออกไป
การตอบกลับที่ส่งกลับด้วย TTL เป็น 1 ข้อบ่งชี้ว่าปัญหานี้มีอยู่ Traceroute พิมพ์ "!" หลังจากที่ TTL มีค่าน้อยกว่าหรือเท่ากับ 1. เนื่องจากผู้จัดจำหน่ายจัดส่งซอฟต์แวร์ล้าสมัย (DEC's Ultrix, Sun 3.x) หรือซอฟต์แวร์ที่ไม่ได้มาตรฐาน (HPUX) จำนวนมากคาดว่าปัญหานี้จะเกิดขึ้นบ่อยครั้งและระมัดระวังในการเลือก โฮสต์เป้าหมายของ probes ของคุณ
คำอธิบายประกอบที่เป็นไปได้อื่น ๆ หลังจากผ่านไปแล้ว! H, ! N, หรือ! P (โฮสต์เครือข่ายหรือโปรโตคอลไม่สามารถเข้าถึงได้)! S (เส้นทางต้นทางล้มเหลว),! F- (จำเป็นต้องแยกส่วน - ค่าการค้นพบเส้นทาง MTU ของ RFC1191 จะปรากฏขึ้น),! X (ห้ามกระทำการสื่อสาร),! V (การละเมิดความสำคัญของโฮสต์),! C (ตัดความสำคัญในผล) หรือ! (รหัสที่ไม่สามารถเข้าถึง ICMP) รหัสเหล่านี้กำหนดโดย RFC1812 ซึ่งใช้แทนที่ RFC1716 ถ้าเกือบทุก probes ส่งผลให้โฮสต์บางแห่งไม่สามารถเข้าถึงได้ traceroute จะยอมแพ้และออก
โปรแกรมนี้มีวัตถุประสงค์เพื่อใช้ในการทดสอบ, การวัดและการจัดการเครือข่าย ควรใช้เป็นหลักในการแยกความผิดพลาดด้วยตนเอง เนื่องจากโหลดที่สามารถใช้งานบนเครือข่ายได้จึงไม่ฉลาดที่จะใช้ traceroute ระหว่างการทำงานปกติหรือจากสคริปต์อัตโนมัติ
