Traceroute คืออะไร? และทำไมต้อง Timeout?

            คำสั่ง ping หรือ traceroute เป็นเครื่องมือสำหรับการตรวจสอบการทำงานของระบบเครือข่ายชนิดหนึ่ง โดยสามารถจะทำการวัดค่า round-trip time (RTT) ซึ่งเป็นค่าช่วงเวลาที่ใช้ในการส่งแพ็คเก็ตไปยังปลายทางจนได้รับแพ็คเก็ตตอบกลับมา เพื่อนำมาใช้ในการตรวจสอบค่า delay ของแต่ละเส้นทางได้ ซึ่งบทความในวันนี้ก็จะขอกล่าวถึงการทำงานของ traceroute เป็นหลักนะครับ

Traceroute คืออะไร?

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

            กลไกการทำงานของ traceroute จะใช้ค่า Time-To-Live (TTL) ที่เป็น field หนึ่งใน IP header มาเป็นเครื่องมือในการทำงาน ซึ่งค่า TTL โดยปกติจะใช้ในการกำหนดขอบเขตจำนวน hop สูงสุดที่จะใช้ในการส่งผ่านข้อมูลไปยังปลายทาง (เป็นกลไกหนึ่งในการป้องกันการเกิด loop ในระบบเครือข่าย) โดยเมื่อแพ็คเก็ตถูกส่งผ่านเราเตอร์แต่ละตัวไป ค่า TTL จะถูกลดค่าลงไปทีละหนึ่งค่า และเมื่อ TTL มีค่าเท่ากับศูนย์ แพ็คเก็ตนั้น ๆ ก็จะถูกดรอปลงไป และเราเตอร์ตัวที่ทำการดรอปแพ็คเก็ตก็จะทำการส่ง ICMP Time Exceeded message กลับไปยังต้นทางผู้ส่งข้อมูล การใช้งาน Traceroute ก็จะนำคุณสมบัติดังกล่าวของ TTL มาใช้ประโยชน์ในการตรวจสอบการทำงานของระบบเครือข่าย โดย Traceroute จะทำการส่งแพ็คเก็ตที่มีการกำหนดค่า TTL เพิ่มขึ้นทีละหนึ่งค่าไปเรื่อย ๆ เพื่อที่จะกำหนดขอบเขตจำนวน hop ที่ต้องการจะตรวจสอบการทำงาน เริ่มจาก hop ที่หนึ่งไปเรื่อย ๆ จนกว่าจะถึงปลายทาง

            จากตัวอย่างด้านบน เป็นการใช้คำสั่ง traceroute บนเราเตอร์ R1 ไปยังเราเตอร์ R4 ซึ่งจะต้องทำการส่งข้อมูลไปทั้งหมด 3 hop ด้วยกัน (hop ที่ 1 และ 2 เป็น hop ระหว่างเส้นทาง ส่วน hop สุดท้ายเป็น hop ปลายทาง) โดยจากข้อมูล traceroute ที่แสดง จะทำให้สามารถทราบข้อมูลได้ดังนี้

1. ลำดับและจำนวน hop ทั้งหมด (มีทั้งหมด 3 hop จากต้นทางไปยังปลายทาง)
2. หมายเลขที่อยู่ของแต่ละ hop (หมายเลข IP address บน incoming interface ของแต่ละ hop)
3. ค่า RTT ที่ใช้ในการส่งข้อมูลไปยังแต่ละ hop

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

Note :โดยปกติในการส่งข้อมูล Traceroute บน Unix-based OS หรือบน Cisco IOS จะใช้ UDP หมายเลขพอร์ตตั้งค่า 33434 ถึง 33534 ในการส่งข้อมูล ส่วนบน Windows OS จะใช้งาน ICMP ในการส่งข้อมูล

            ในการทำงานของ traceroute บน Cisco IOS ต้นทางจะเริ่มต้นจากการส่งแพ็คเก็ต UDP ออกไป และจะรอรับข้อความ ICMP Time Exceeded ตอบกลับมาจากแต่ hop ระหว่างเส้นทาง จากนั้นก็จะทำการบันทึกข้อมูลการทำงานของแต่ละ hop เก็บไว้ ซึ่งในรายละเอียดขั้นตอนการทำงานจะมีดังนี้

1. เริ่มต้น ต้นทางผู้ใช้คำสั่ง traceroute จะทำการส่งแพ็คเก็ตที่มีค่า TTL = 1 ออกไป เพื่อที่จะทำการตรวจสอบการทำงานของ hop ที่หนึ่ง (ในแต่ละ hop จะทำการตรวจสอบ 3 รอบ)
2. เมื่อ hop แรกได้รับแพ็คเก็ตเข้ามา จะทำการลดค่า TTL ลงหนึ่งค่า เหลือ TTL = 0 จึงทำการดรอปแพ็คเก็ตนั้นทิ้งไป และทำการส่งข้อความ ICMP Time Exceeded กลับไปยังต้นทาง 
3. เมื่อต้นทางได้รับข้อความที่ hop แรกตอบกลับมา ก็จะทำการบันทึกค่า RTT ของแต่ละแพ็คเก็ตที่ได้รับการตอบกลับ
4. ต้นทางทำการส่งแพ็คเก็ตที่มีค่า TTL = 2 ออกไป เพื่อที่จะทำการตรวจสอบการทำงานของ hop ที่สอง โดยจะส่งทั้งหมด 3 รอบเช่นเดิม
5. เมื่อ hop แรกได้รับแพ็คเก็ตที่มีค่า TTL = 2 เข้ามา จะทำการลดค่า TTL ลงไปหนึ่งค่า ดังนั้นจึงเหลือ TTL = 1 และทำการส่งต่อแพ็คเก็ตไปยัง hop ถัดไป
6. เมื่อ hop ที่สองได้รับแพ็คเก็ตที่มีค่า TTL = 1 เข้ามา ก็จะทำการดรอปแพ็คเก็ตทิ้งไปและทำการส่งข้อความ ICMP Time Exceeded กลับไปยังต้นทาง
7. เมื่อต้นทางได้รับข้อความที่ hop ที่สองตอบกลับมา ก็จะทำการบันทึกค่า RTT ของแต่ละแพ็คเก็ตที่ได้รับการตอบกลับ
8. จากนั้นต้นทางก็จะทำการเพิ่มค่า TTL ไปเรื่อย ๆ ครั้งละหนึ่งค่า จนกว่าจะทำการส่งแพ็คเก็ตไปถึงยังปลายทางที่ต้องการ
9. เมื่อแพ็คเก็ตถึงปลายทางแล้ว อุปกรณ์ปลายทางจะไม่ทำการตอบกลับมาด้วยข้อความ ICMP Time Exceeded เหมือนอย่าง hop ระหว่างทาง แต่จะทำการตอบกลับมาด้วย ICMP Destination unreachable/Port unreachable (type 3 code 3)  กลับมายังต้นทาง
10. เมื่อต้นทางได้รับข้อความที่ hop ปลายทางตอบกลับมา ก็จะทำการบันทึกค่า RTT ของแต่ละแพ็คเก็ตที่ได้รับการตอบกลับมา

ทำไม Traceroute บน Cisco IOS แล้ว Timeout?

            เคยสังเกตุมั้ยครับว่าเมื่อเราทำการ traceroute ไปยังอุปกรณ์เครือข่ายหลาย ๆ ยี่ห้อ รวมทั้งไปยัง Cisco IOS จะพบว่ามักจะมี timeout เกิดขึ้นใน hop สุดท้ายเสมอ ตัวอย่างเช่น

R1#traceroute 10.3.4.2 numeric

Type escape sequence to abort.

Tracing the route to 10.3.4.2

  1 10.1.2.2 92 msec 48 msec 12 msec

  2 10.2.3.2 20 msec 40 msec 36 msec

  3 10.3.4.2 60 msec *  120 msec

            สำหรับเหตุผลที่เกิด timeout ขึ้นใน hop สุดท้ายนั้น ก่อนอื่นต้องทำความเข้าในก่อนว่า โดย default บน Cisco IOS จะมีการเปิดการทำงานของคุณสมบัติ ICMP unreachable rate limit เอาไว้ เพื่อเป็นการป้องกันการโจมตีแบบ DoS attack ซึ่งโดย default จะทำการตอบกลับ ICMP destination unreachable message ไปหนึ่งครั้งทุก ๆ 500 ms (เฉพาะ ICMP destination unreachable message เท่านั้น ส่วน ICMP message อื่น ๆ จะทำการตอบกลับตามปกติ) โดยเราสามารถตรวจสอบการทำงานของคุณสมบัติ ICMP unreachable rate limit บนอุปกรณ์ Cisco IOS ได้ด้วยการใช้คำสั่ง "show ip icmp rate-limit"

R1#show ip icmp rate-limit

                           DF bit unreachables       All other unreachables

Interval (millisecond)     500                       500

Interface                  # DF bit unreachables     # All other unreachables

---------                  ---------------------     ------------------------

            และก็ต้องเข้าใจด้วยว่า โดย default ของ traceroute บน Cisco IOS จะมีช่วงเวลา timeout อยู่ที่ 2 วินาที  ซึ่งเหตุผลที่เกิด traceroute timeout ใน hop สุดท้ายนี้ก็เพราะว่า ช่วงเวลาของ ICMP destination unreachable rate limit กับช่วงเวลาของ traceroute timeout นี้ไม่สอดคล้องกันนั่นเอง ตัวอย่างเช่น ต้องการ traceroute จากเราเตอร์ A ไปยัง ปลายทางเราเตอร์ B จะมีขั้นตอนการทำงานดังนี้

1. เมื่อเราเตอร์ A ทำการส่ง traceroute probe แรกออกไป และเราเตอร์ B ที่เป็นปลายทางที่ต้องการ traceroute ไปหา เราเตอร์ B จะทำการตอบกลับมาด้วยข้อความ ICMP destination unreachable กลับมายังเราเตอร์ A โดยหลังจากนี้ที่เราเตอร์ B จะไม่สามารถตอบกลับ ICMP destination unreachable ได้อีกเป็นเวลา 500 ms เราเตอร์ A เมื่อได้รับการตอบกลับจากเราเตอร์ B มาก็จะทำการบันทึกค่า RTT ไว้
2. เราเตอร์ A ทำการส่ง traceroute probe ลำดับที่สองออกไป ในครั้งนี้เราเตอร์ B จะไม่สามารถตอบกลับมาด้วยข้อความ ICMP destination unreachable ได้ เนื่องจากช่วงเวลา 500 ms ยังไม่หมดลง
3. เราเตอร์ A รอจนช่วงเวลา Traceroute timeout interval 2 วินาทีหมดลง ทำให้ผลลัพธ์แสดงค่าเป็น timeout จากนั้นจึงทำการส่ง traceroute probe ลำดับที่สามออกไป ในครั้งนี้ ช่วงเวลา ICMP unreachable rate limit interval 500 ms ได้หมดช่วงเวลาเดิมไปแล้ว ดังนั้นเราเตอร์ B จึงทำการตอบกลับมาด้วยข้อความ ICMP destination unreachable กลับมายังเราเตอร์ A ได้ตามปกติ

            ดังนั้น ในการที่เราทำการ traceroute ไปยังอุปกรณ์เครือข่าย Cisco แล้วพบว่าใน hop สุดท้ายเกิด timeout ขึ้นมา ก็เป็นเพราะว่าช่วงเวลาของ traceroute timeout และช่วงเวลาของ ICMP unreachable rate limit ไม่สอดคล้องกันนั่นเอง ซึ่งเราสามารถยกเลิกการทำงานของ ICMP rate limit ที่เราเตอร์ปลายทางได้ด้วยการใช้คำสั่ง "no ip icmp rate-limit unreachable" 

R4(config)# no ip icmp rate-limit unreachable

            เมื่อใช้คำสั่ง "no ip icmp rate-limit unreachable" ในเราเตอร์ปลายทางแล้ว จะพบว่าเมื่อ traceroute จะไม่พบว่ามีการเกิด timeout อีกต่อไป แต่อย่างไรก็ตาม การปิดการทำงานของ ICMP rate limit ก็อาจจะทำให้เกิดการโจมตีแบบ DoS attack บนเราเตอร์ขึ้นได้

R1#traceroute 10.3.4.2 numeric

Type escape sequence to abort.

Tracing the route to 10.3.4.2

  1 10.1.2.2 92 msec 48 msec 12 msec

  2 10.2.3.2 20 msec 40 msec 36 msec

  3 10.3.4.2 60 msec 80 msec 120 msec

            ทั้งนี้ในกรณีที่ทำการ ping ไปยังปลายทางและพบ response กลับมาในรูปแบบ "U.U.U" หรือ destination unreachable สลับกับ timeout ก็เนื่องมาจากเหตุผลเดียวกันนี้เอง

Reference :
http://packetlife.net/blog/2008/may/27/dissecting-unreachable-ping-response
http://packetlife.net/blog/2008/dec/29/traceroute-timeouts