Lệnh theo dõi cho Linux

Những điều cần biết

Tham số duy nhất bạn phải bao gồm với lệnh theo dõi là tên máy chủ hoặc địa chỉ IP của đích.
Bắt đầu các cuộc thăm dò với TTL là một và tăng lên một cho đến khi bạn nhận được ICMP "không thể truy cập cổng" hoặc đạt đến giá trị tối đa của số lần thử.

Bài viết này bao gồm thông tin về quy trình theo dõi áp dụng cho các máy Linux và bao gồm các giải thích về công tắc lệnh cùng với thông tin về cách diễn giải kết quả. Traceroute được sử dụng khác nhau trong Windows.

Traceroute hoạt động như thế nào

Lệnh traceroute ánh xạ hành trình mà một gói thông tin thực hiện từ nguồn đến đích của nó. Một cách sử dụng cho quy trình theo dõi là xác định thời điểm xảy ra mất dữ liệu trên toàn mạng, điều này có thể báo hiệu một nút bị hỏng.

Vì mỗi bước trong bản ghi phản ánh một máy chủ hoặc bộ định tuyến mới giữa PC gốc và mục tiêu dự định, nên việc xem xét kết quả quét theo lộ trình sẽ xác định các điểm chậm có thể ảnh hưởng xấu đến lưu lượng mạng của bạn.

Khắc phục sự cố với Traceroute

Việc đánh giá tuyến đường cụ thể mà lưu lượng mạng đi theo (hoặc tìm kiếm cổng kết nối sai trái đang loại bỏ các gói của bạn) đưa ra một số thách thức khắc phục sự cố. Traceroute sử dụng giao thức IP thời gian tồn tại trường để thu hút phản hồi ICMP TIME_EXCEEDED từ mỗi cổng dọc theo đường dẫn đến máy chủ đích.

Tham số duy nhất bạn phải bao gồm khi thực hiện lệnh theo dõi là tên máy chủ hoặc địa chỉ IP của đích.

Cú pháp và chuyển mạch theo dõi

Traceroute tuân theo cú pháp chung sau:

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 ]

Bạn có thể thay đổi hiệu suất hoặc đầu ra của lệnh bằng cách chỉ định một hoặc nhiều công tắc tùy chọn.

Công tắc Lệnh theo dõi Chuyển đổi Giải thích -f Đặt thời gian tồn tại ban đầu được sử dụng trong gói thăm dò gửi đi đầu tiên. -F Đặt bit "không phân mảnh". -d Bật gỡ lỗi mức ổ cắm. -g Chỉ định cổng định tuyến nguồn lỏng lẻo (tối đa 8). -i Chỉ định giao diện mạng để lấy địa chỉ IP nguồn cho các gói thăm dò gửi đi. Điều này thường chỉ hữu ích trên một máy chủ nhiều tầng. (Xem -s gắn cờ cho một cách khác để thực hiện việc này.) -I Sử dụng ICMP ECHO thay vì biểu đồ dữ liệu UDP. -m Đặt thời gian tồn tại tối đa (số bước nhảy tối đa) được sử dụng trong các gói thăm dò gửi đ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 địa chỉ hop theo số thay vì biểu tượng và số (lưu tra cứu địa chỉ-tên của máy chủ định danh 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 các đầu dò (mặc định là 33434). Traceroute hy vọng rằng không có gì đang nghe trên các cổng UDP base to base + nhops - 1 tại máy chủ đích (do đó, một thông báo ICMP PORT_UNREACHABLE sẽ được trả về để chấm dứt việc dò tìm tuyến đường). Nếu có nội dung nào đó đang 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 phạm vi 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ủ lưu trữ trên mạng được đính kèm. Nếu máy chủ lưu trữ không nằm trên mạng được gắn trực tiếp, lỗi sẽ được trả về. Tùy chọn này có thể được sử dụng để ping một máy chủ cục bộ thông qua một giao diện không có đường dẫn thông qua nó (ví dụ:sau khi giao diện bị ngắt do đã định tuyến (8C)). -s Sử dụng địa chỉ IP sau (thường được cung cấp dưới dạng số IP, không phải tên máy chủ) làm địa chỉ nguồn trong các gói thăm dò gửi đi. Trên các máy nhiều chủ (những máy có nhiều hơn một địa chỉ IP), tùy chọn này có thể được sử dụng để buộc địa chỉ nguồn phải là một địa chỉ nào đó khác với địa chỉ IP của giao diện mà gói thăm dò được gửi đến. Nếu địa chỉ IP không phải là một trong các địa chỉ giao diện của máy này, lỗi sẽ được trả về và không có gì được gửi. (Xem -i gắn cờ cho một cách khác để thực hiện việc này.) -t Đặt loại dịch vụ trong các gói thăm dò đến giá trị sau (mặc định là 0). Giá trị phải là một 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 dịch vụ khác nhau có dẫn đến các đường dẫn khác nhau hay không. (Nếu bạn không chạy 4.4bsd, điều này có thể mang tính hàn lâm, vì 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 — hãy xem thông số IP để biết đị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ông phải TIME_EXCEEDED và UNREACHABLE được liệt kê. -w Đặt thời gian (tính bằng giây) để đợi phản hồi cho một đầ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 quy trình theo dõi tính toán tổng kiểm tra 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; do đó, trong một số trường hợp, mặc định là không tính toán 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 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 là 0). Một số hệ thống như Solaris và bộ định tuyến của Cisco, thông báo icmp giới hạn tốc độ. Giá trị tốt để sử dụng với giá trị này là 500 (ví dụ:1/2 giây).

Diễn giải kết quả

Traceroute phác thảo đường dẫn một gói IP đi theo một 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ỏ, sau đó lắng nghe câu trả lời "đã vượt quá thời gian" của ICMP từ một cổng. Bắt đầu thăm dò với TTL là một và tăng thêm một cho đến khi bạn nhận được ICMP "cổng không thể truy cập" (có nghĩa là gói đã đến đích) hoặc đạt giá trị tối đa của lần thử, giá trị này mặc định là 30 bước và có thể thay đổi bằng dấu -m cờ.

Khi thực thi theo dõi, nó sẽ gửi ba đầu dò ở mỗi cài đặt TTL và sau đó in một dòng tới bảng điều khiển hiển thị TTL, địa chỉ của cổng và thời gian khứ hồi của mỗi đầu dò. Nếu câu trả lời thăm dò đến từ các cổng khác nhau, địa chỉ của mỗi hệ thống trả lời sẽ in. Nếu quy trình theo dõi không nhận được phản hồi trong vòng năm giây (được thay đổi bằng -w cờ), nó in dấu hoa thị cho đầu dò đó.

Để ngăn quá trình xử lý gói thăm dò UDP lấn át máy chủ đích, theo dõi sẽ đặt cổng đích thành một giá trị mà thiết bị không thể sử dụng. Nếu mạng hoặc dịch vụ tại điểm đến sử dụng cổng đó, hãy thay đổi giá trị bằng cách sử dụng -p cờ.

Ví dụ về kết quả theo dấu vết

Việc sử dụng và xuất mẫu sẽ trả về kết quả tương tự như ví dụ này:

[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

Dòng thứ hai và thứ ba giống nhau. Kết quả này liên quan đến một hạt nhân có lỗi trên hệ thống hop thứ hai — lbl-csam.arpa — chuyển tiếp các gói có TTL bằng không (một lỗi trong phiên bản phân tán 4.3 BSD). Bạn phải đoán xem các gói đang đi theo đường nào xuyên quốc gia vì NSFNet (129.140) không cung cấp các bản dịch từ địa chỉ sang tên cho các NSS của nó.

Ví dụ về cổng im lặng

Một ví dụ thú vị hơn là:

[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 ms 279 ms 279 ms

Note that the gateways at 12, 14, 15, 16, and 17 hops away either don't send ICMP "time exceeded" messages or send them with a TTL too small to reach us. Lines 14 through 17 are running the MIT C Gateway code that doesn't send "time exceeded" messages.

The silent gateway 12 in the above example may be the result of a bug in the 4.[23]BSD network code and its derivatives: Machines running 4.3 code and earlier send an unreachable message using whatever TTL remains in the original datagram. For gateways, the remaining TTL is zero, the ICMP "time exceeded" is guaranteed to not make it back to us.

Destination System Silent Gateway Example

The behavior of this bug is slightly more interesting when it appears on the destination system:

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 ms ! 39 ms ! 39 ms !

Notice that 12 "gateways" exist (13 is the final destination), and the last half of them are missing. What's really happening is that the server named rip (a Sun-3 running Sun OS 3.5) is using the TTL from our arriving datagram as the TTL in its ICMP reply. So, the reply will time out on the return path (with no notice sent to anyone since ICMPs aren't sent for ICMPs) until we probe with a TTL that's at least twice the path length—in other words, rip is really only seven hops away.

A reply that returns with a TTL of 1 is a clue this problem exists. Traceroute prints a ! after the time if the TTL is less than or equal to 1. Since vendors ship a lot of obsolete (DEC's Ultrix, Sun 3.x) or non-standard (HPUX) software, expect to see this problem frequently and take care picking the target host of your probes.

Other possible annotations after the time are !H, !N, or !P (host, network, or protocol unreachable), !S (source route failed), !F- (fragmentation needed—the RFC1191 Path MTU Discovery value is displayed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or ! (ICMP unreachable code). These codes are defined by RFC1812, which supersedes RFC1716. If almost all the probes result in some kind of unreachable host, traceroute will give up and exit.

This program is intended for use in network testing, measurement, and management. It should be used primarily for manual fault isolation. Because of the load it could impose on the network, it's unwise to use traceroute during normal operations or from automated scripts.