Làm thế nào để theo dõi các giao diện gửi đi?

Lệnh Unix traceroutetheo dõi địa chỉ IP của các nút từ nút nguồn đến nút đích. Mỗi nút ở giữa có một giao diện đến và đi.

Thực hiện traceroute -n dsttrên srcsẽ hiển thị các địa chỉ IP của src, dst và tất cả các giao diện đến của các bước nhảy ở giữa.

Nhưng làm thế nào để theo dõi các địa chỉ IP outging?

Cập nhật

Tôi đã thử ping -Rđề xuất nhưng nó dường như không hoạt động. Đây là traceroute đến một máy chủ web công cộng:

$ ping -n -c 1 -R 212.227.222.9
PING 212.227.222.9 (212.227.222.9) 56 (124) byte dữ liệu.
64 byte từ 212.227.222.9: icmp numq = 1 ttl = 57 time = 47,4 ms
RR: 192.168.2.111
        169.254.1.1
        87.186.224.94
        62.154.76.34
        62.154.12.175
        212.227.117.13
        212.227.117.8
        10.71.3.253
        212.227.222.9


--- 212.227.222.9 thống kê ping ---
1 gói được truyền, 1 nhận, mất 0% gói, thời gian 0ms
rtt tối thiểu / avg / max / mdev = 47.441 / 47.441 / 47.441 / 0.000 ms

Và đây là địa chỉ IP của kết nối quay số của tôi.

$ curl -s https://toolbox.googl OKs.com/apps/browserinfo/info/ | jq -r .remoteAddr
93.192,75.247

Nhưng nó đã không được ghi lại bằng lệnh ping. Nguyên nhân có thể là gì?

Tôi không chính xác câu trả lời cho câu hỏi của bạn, nhưng đó là một cách đơn giản (nhưng hạn chế) để làm (trong trường hợp nhất định) những gì bạn muốn. Tôi đang đối phó-đăng tùy chọn -R của trang ping man:

-R Ghi tuyến đường. Bao gồm tùy chọn RECORD_ROUTE trong gói ECHO_REQUEST và hiển thị bộ đệm tuyến trên các gói được trả về. Lưu ý rằng tiêu đề IP chỉ đủ lớn cho chín tuyến đường như vậy. Nhiều máy chủ bỏ qua hoặc loại bỏ tùy chọn này.

Vì vậy, bạn cũng có thể thấy đường dẫn trở lại của ECHO_REQUEST, đó không phải là giao diện thoát (mà bạn đang hỏi về) trừ khi đường dẫn đi giống với đường dẫn quay lại. Chỉ trong trường hợp này, đường dẫn trở lại là địa chỉ IP của giao diện gửi đi mà bạn đang yêu cầu.

Đó là một ví dụ thực tế trên mạng nhà cung cấp internet của tôi, có thể không rõ ràng lắm, nhưng tôi không có một số bộ định tuyến để liên kết với nhau :)

traceroute 10.2.105.178
traceroute to 10.2.105.178 (10.2.105.178), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  3.418 ms  3.575 ms  4.021 ms
 2  10.189.48.1 (10.189.48.1)  11.237 ms * *
 3  10.2.105.178 (10.2.105.178)  15.235 ms * *

ping -R 10.2.105.178 PING 10.2.105.178 (10.2.105.178) 56 (124) byte dữ liệu.

64 byte từ 10.2.105.178: icmp numq = 5 ttl = 253 time = 74.1 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.178

10.189.48.1

192.168.1.254

192.168.1.133

---- bỏ qua ----

64 byte từ 10.2.105.178: icmp numq = 6 ttl = 253 time = 13.0 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.218 ## thay đổi mỗi lần, Idon không biết tại sao ##

10.189.48.1

192.168.1.254

192.168.1.133

Theo RFC1812 , địa chỉ nguồn của thông điệp ICMP do bộ định tuyến tạo ra phải là giao diện đầu ra mà gói thông thường sẽ trả về cho người gửi.

Trong thực tế, rất có khả năng bạn sẽ phải đối mặt với hành vi không chuẩn trong đó bộ định tuyến sẽ lấy nguồn trả lời ICMP bằng nguồn giao diện xâm nhập. Điều này thường làm cho traceroute dễ đọc hơn nhiều.

Theo câu hỏi của YLearn, tôi đang đăng sơ đồ mạng và một số kết quả đầu ra.

Giả sử chúng ta đang sử dụng traceroute từ loopback của R5 5.5.5.5 đến loopback của R1 1.1.1.1. Như bạn có thể thấy, đường dẫn chuyển tiếp là thông qua R4-R2, trong khi đường dẫn ngược là R3-R4.

R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 4", distance 20, metric 0
Tag 2, type external
Last update from 10.1.24.2 00:02:42 ago
Routing Descriptor Blocks:
* 10.1.24.2, from 10.1.24.2, 00:02:42 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2

R1#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "bgp 1", distance 20, metric 0
Tag 3, type external
Last update from 10.1.13.3 00:14:18 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.13.3, 00:14:18 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2
  Route tag 3
  MPLS label: none

Đầu ra theo dõi từ R5 trông như sau:

R5#traceroute
Protocol [ip]:
Target IP address: 1.1.1.1
Source address: 5.5.5.5
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 208 msec 140 msec 100 msec
2 10.1.24.2 96 msec 44 msec 104 msec
3 10.1.12.1 224 msec 220 msec 112 msec

Vì vậy, trong khi lưu lượng truy cập ICMP thực tế do R1 tạo ra sẽ quay trở lại R5 thông qua R3, tiêu đề IP của thông báo Không thể truy cập ICMP sẽ có nguồn giao diện xâm nhập 10.1.12.1.

Theo kinh nghiệm của tôi, đây là cách các bộ định tuyến của Cisco và Juniper hoạt động, tôi không chắc chắn về các nhà cung cấp khác.