traceroute - in các gói tuyến đường đi đến máy chủ mạng
Tóm tắc
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g cổng ]
[ -i iface ] [ -m max_ttl] [ -p cổng ]
[ -q nqueries ] [ -s src_addr ] [ -t tos ]
[ -w waittime ] [ -z pauseemsecs ]
máy chủ
Sự miêu tả
Internet là một tập hợp phần cứng mạng lớn và phức tạp, được kết nối với nhau bằng cổng. Theo dõi các gói của một người theo dõi (hoặc tìm cổng bị hỏng mà loại bỏ các gói dữ liệu của bạn) có thể khó khăn. Traceroute sử dụng trường giao thức IP 'thời gian để sống' và cố gắng gợi ra một phản hồi ICMP TIME_EXCEEDED từ mỗi cổng dọc theo đường dẫn tới một số máy chủ.
Thông số bắt buộc duy nhất là tên máy chủ đích hoặc số IP . Chiều dài datagram thăm dò mặc định là 40 byte , nhưng điều này có thể được tăng lên bằng cách xác định chiều dài gói (tính bằng byte) sau tên máy chủ đích.
Các tùy chọn khác là:
-f
Đặt thời gian sử dụng ban đầu được sử dụng trong gói đầu dò đi đầu tiên.
-F
Đặt bit "không phân đoạn".
-d
Bật gỡ lỗi cấp ổ cắm.
-g
Chỉ định một cổng nguồn tuyến đường lỏng (tối đa 8).
-tôi
Chỉ định giao diện mạng để lấy địa chỉ IP nguồn cho các gói đầu dò đi. Điều này thường chỉ hữu ích trên một máy chủ đa homed. (Xem cờ -s để biết cách khác để làm điều này.)
-TÔI
Sử dụng ICMP ECHO thay vì UDP datagrams.
-m
Đặt thời gian chờ tối đa (số lần nhảy tối đa) được sử dụng trong các gói đầu dò đi. Mặc định là 30 bước nhảy (cùng một mặc định được sử dụng cho các kết nối TCP).
-n
In các địa chỉ hop bằng số chứ không phải là biểu tượng và số (lưu một tra cứu địa chỉ tên máy chủ tên cho mỗi cổng được tìm thấy trên đường dẫn).
-p
Đặt số cổng UDP cơ sở được sử dụng trong đầu dò (mặc định là 33434). Traceroute hy vọng rằng không có gì là lắng nghe trên các cổng UDP cơ sở đến + nhops - 1 tại máy đích đích (vì vậy một tin nhắn ICMP PORT_UNREACHABLE sẽ được trả về để chấm dứt theo dõi tuyến đường). Nếu một cái gì đó đang lắng nghe trên một cổng trong phạm vi mặc định, tùy chọn này có thể được sử dụng để chọn một dải cổng không sử dụng.
-r
Bỏ qua các bảng định tuyến thông thường và gửi trực tiếp đến một máy chủ trên một mạng được đính kèm. Nếu máy chủ không nằm trên mạng được đính kèm trực tiếp, lỗi sẽ được trả lại. Tùy chọn này có thể được sử dụng để ping một máy chủ lưu trữ cục bộ thông qua một giao diện không có đường đi qua nó (ví dụ, sau khi giao diện bị bỏ đi bằng cách định tuyến (8C)).
-S
Sử dụng địa chỉ IP sau (thường được đưa ra dưới dạng một số IP, không phải là tên máy chủ) làm địa chỉ nguồn trong các gói thăm dò đi. Trên các máy chủ đa hom (có nhiều hơn một địa chỉ IP), tùy chọn này có thể được sử dụng để ép buộc địa chỉ nguồn là địa chỉ IP khác với địa chỉ IP của giao diện mà gói thăm dò được gửi đi. Nếu địa chỉ IP không phải là một trong những địa chỉ giao diện của máy này, lỗi sẽ được trả lại và không có gì được gửi. (Xem cờ -i để biết cách khác để làm điều này.)
-t
Đặt loại dịch vụ trong các gói đầu dò thành giá trị sau (mặc định là 0). Giá trị phải là số nguyên thập phân trong phạm vi từ 0 đến 255. Tùy chọn này có thể được sử dụng để xem liệu các loại kết quả dịch vụ khác nhau có khác nhau hay không. (Nếu bạn không chạy 4.4bsd, điều này có thể là do các dịch vụ mạng thông thường như telnet và ftp không cho phép bạn kiểm soát TOS). Không phải tất cả các giá trị của TOS đều hợp pháp hoặc có ý nghĩa - xem thông số IP cho các định nghĩa. Các giá trị hữu ích có thể là ` -t 16 '(độ trễ thấp) và` -t 8 ' (thông lượng cao).
-v
Báo cáo dài dòng. Các gói ICMP đã nhận khác hơn TIME_EXCEEDED và UNREACHABLE được liệt kê.
-w
Đặt thời gian (tính bằng giây) để chờ phản ứng với đầu dò (mặc định là 5 giây).
-x
Chuyển đổi tổng kiểm tra ip. Thông thường, điều này ngăn chặn traceroute từ tính toán checksum ip. Trong một số trường hợp, hệ điều hành có thể ghi đè lên các phần của gói gửi đi nhưng không tính toán lại tổng kiểm tra (vì vậy trong một số trường hợp, mặc định là không tính tổng kiểm tra và sử dụng -x khiến chúng được tính toán). Lưu ý rằng tổng kiểm tra thường được yêu cầu cho bước nhảy cuối cùng khi sử dụng đầu dò ICMP ECHO ( -I ). Vì vậy, chúng luôn được tính toán khi sử dụng ICMP.
-z
Đặt thời gian (tính bằng mili giây) để tạm dừng giữa các đầu dò (mặc định 0). Một số hệ thống như Solaris và bộ định tuyến như tin nhắn icmp giới hạn tốc độ Ciscos. Một giá trị tốt để sử dụng với điều này là 500 (ví dụ 1/2 giây).
Chương trình này cố gắng theo dõi lộ trình một gói IP sẽ theo dõi một số máy chủ internet bằng cách khởi chạy các gói thăm dò UDP với một ttl nhỏ (thời gian sống) sau đó lắng nghe một câu trả lời "vượt quá thời gian" ICMP từ một cổng. Chúng tôi bắt đầu đầu dò với một ttl của một và tăng một cho đến khi chúng tôi nhận được cổng ICMP "không thể truy cập" (có nghĩa là chúng tôi phải "lưu trữ") hoặc nhấn một giá trị tối đa (mặc định là 30 bước nhảy và có thể thay đổi bằng -m cờ). Ba đầu dò (thay đổi với cờ -q ) được gửi ở mỗi thiết lập ttl và một dòng được in hiển thị ttl, địa chỉ của cổng và thời gian chuyến đi vòng của mỗi đầu dò. Nếu câu trả lời của đầu dò đến từ các cổng khác nhau, địa chỉ của mỗi hệ thống trả lời sẽ được in. Nếu không có phản hồi trong vòng 5 giây. khoảng thời gian chờ (thay đổi với cờ -w ), "*" được in cho đầu dò đó.
Chúng ta không muốn host đích xử lý các gói thăm dò UDP để cổng đích được đặt thành một giá trị không mong muốn (nếu một số clod trên đích đang sử dụng giá trị đó, nó có thể được thay đổi bằng cờ -p ).
Việc sử dụng và đầu ra mẫu có thể là:
[yak 71]% traceroute nis.nsf.net. traceroute đến nis.nsf.net (35.1.1.48), 30 bước nhảy tối đa, gói 38 byte 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 msLưu ý rằng các dòng 2 & 3 giống nhau. Điều này là do một hạt nhân lỗi trên hệ thống hop 2 - lbl-csam.arpa - chuyển tiếp các gói tin với một số không ttl (một lỗi trong phiên bản phân tán của 4.3BSD). Lưu ý rằng bạn phải đoán đường dẫn mà các gói đang sử dụng xuyên quốc gia vì NSFNet (129.140) không cung cấp các bản dịch địa chỉ cho các NSS của nó.
Một ví dụ thú vị hơn là:
[yak 72]% traceroute allspice.lcs.mit.edu. traceroute đến allspice.lcs.mit.edu (18.26.0.115), 30 bước nhảy tối đa 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 msLưu ý rằng các cổng 12, 14, 15, 16 và 17 sẽ không gửi các tin nhắn ICMP "vượt quá thời gian" hoặc gửi chúng với một ttl quá nhỏ để đến với chúng tôi. 14 - 17 đang chạy mã MIT C Gateway không gửi "thời gian vượt quá" s. Chúa chỉ biết chuyện gì đang diễn ra với 12.
Cổng vào im lặng 12 ở trên có thể là kết quả của một lỗi trong mã mạng BSD 4. [23] (và các dẫn xuất của nó): 4.x (x <= 3) gửi một thông điệp không thể truy cập bằng bất cứ ttl nào vẫn còn trong bản gốc datagram. Vì, đối với các cổng, số ttl còn lại bằng 0, thời gian ICMP "vượt quá" được đảm bảo để không trả lại cho chúng tôi. Hành vi của lỗi này hơi thú vị hơn khi nó xuất hiện trên hệ thống đích:
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 Cô ! 39 ms! 39 ms!Lưu ý rằng có 12 "cổng" (13 là đích cuối cùng) và chính xác nửa cuối của chúng là "thiếu". Điều thực sự xảy ra là rip (Sun-3 chạy Sun OS3.5) đang sử dụng ttl từ datagram đến của chúng tôi như ttl trong trả lời ICMP của nó. Vì vậy, câu trả lời sẽ hết thời gian trên đường dẫn trở lại (không có thông báo được gửi đến bất kỳ ai vì ICMP không được gửi cho ICMP) cho đến khi chúng tôi thăm dò với một ttl có ít nhất gấp đôi chiều dài đường dẫn. Tức là, rip thực sự chỉ còn 7 bước nhảy. Trả lời trả về bằng ttl là 1 là một đầu mối tồn tại. Traceroute in một "!" sau thời gian nếu ttl là <= 1. Vì các nhà cung cấp gửi rất nhiều lỗi thời (phần mềm Ultrix, Sun 3.x) hoặc phần mềm không chuẩn (HPUX) của DEC, hy vọng sẽ gặp vấn đề này thường xuyên và / hoặc cẩn thận chọn mục tiêu máy chủ của đầu dò của bạn.
Các chú thích có thể khác sau thời gian này là H ,! N , hoặc ! P (máy chủ, mạng hoặc giao thức không thể truy cập được), S (tuyến nguồn không thành công) ,! F- (phân mảnh cần thiết - giá trị RU1191 Path MTU Discovery được hiển thị), ! X (thông tin hành chính bị cấm) ,! V (vi phạm ưu tiên máy chủ) ,! C (ưu tiên cắt bỏ hiệu lực), hoặc ! (Mã ICMP không thể truy cập được). Chúng được xác định bởi RFC1812 (thay thế cho RFC1716). Nếu gần như tất cả các đầu dò kết quả trong một số loại không thể truy cập, traceroute sẽ bỏ và thoát.
Chương trình này được thiết kế để sử dụng trong kiểm tra, đo lường và quản lý mạng. Nó nên được sử dụng chủ yếu để phân tách lỗi thủ công. Bởi vì tải nó có thể áp đặt trên mạng, nó là không khôn ngoan để sử dụng traceroute trong hoạt động bình thường hoặc từ các kịch bản tự động.
Xem thêm
pathchar (8), netstat (1), ping (8)