Tại sao một số triển khai theo dõi phổ biến mặc định sử dụng các đầu dò UDP?

Gần đây tôi đã khắc phục sự cố meta kết nối mạng, trong đó tôi biết một điểm đến cụ thể có thể truy cập được, nhưng tôi không thể chứng minh điều đó traceroutevì đường dẫn bị lạnh sau một số bước nhảy nhất định. Cho rằng bước nhảy quan sát cuối cùng chỉ nằm ở thượng nguồn từ nút quan tâm, tôi đã đánh hơi lưu lượng truy cập, hy vọng xác nhận rằng các đầu dò đang chạm tới nó và để tìm hiểu quy tắc bộ lọc nào đang chặn chúng. Chắc chắn, tôi đã học được rằng các đầu dò là các datagram UDP dành cho một cổng cao (và khác nhau) mà dĩ nhiên tôi đã chặn lưu lượng truy cập vào.

Điều này làm tôi ngạc nhiên, vì tôi cho rằng tất cả các traceroutethăm dò sẽ mặc định là ICMP, vì các phản hồi là ICMP. Tôi đã làm một cuộc khảo sát tài liệu và thấy rằng các triển khai khác nhau tạo ra các lựa chọn khác nhau và một số không cho phép người dùng thực hiện lựa chọn không mặc định.

• UDP
  • Cisco
  • Linux
  • FreeBSD
• ICMP
  • Cây bách xù
  • Thổ cẩm
  • các cửa sổ

Bản tóm tắt của phương pháp thăm dò Traceroute và suy luận đường dẫn IP chuyển tiếp hỗ trợ trực giác của tôi rằng các đầu dò ICMP sẽ thường thành công hơn trong việc đến đích.

Cho phép các phương pháp thăm dò khác nhau có vẻ như là một ý tưởng tuyệt vời, nhưng mặc định cho một cái gì đó khác ngoài ICMP có vẻ như là một ý tưởng tồi. Ai đó có thể mô tả lý do đằng sau tại sao tốt hơn là sử dụng UDP theo mặc định?

Phiên bản đầu tiên tracerouteđược viết bởi Van Jacobson và nó đã sử dụng ICMP nhưng nó không hoạt động tốt. Giải thích của nhà cung cấp về ICMP trong RFC792 là các bộ định tuyến không nên gửi thông báo lỗi ICMP để phản hồi gói ICMP (xem ghi chú chỉnh sửa bên dưới). Do đó, hầu hết các bộ định tuyến sẽ không gửi thông báo "vượt quá thời gian" để đáp ứng yêu cầu tiếng vang với chỉ số TTL là 1 hoặc 0. Vì vậy, ông đã thay đổi nó để sử dụng UDP và lo và thấy nó hoạt động rất tốt và có nhiều sự vui mừng (và chấp nhận). Công traceroutecụ trên Linux và FreeBSD (và tôi giả sử Cisco) dựa trên công việc của Van Jacobson.

Thông số kỹ thuật sau đó đã được thay đổi thành "để đáp ứng với gói lỗi ICMP ." Thế giới đã phát triển, các nhà cung cấp đã thay đổi ngăn xếp của họ cho phép các thông báo lỗi ICMP đáp ứng các yêu cầu tiếng vang và với sự gia tăng của tường lửa và ACL, các gói UDP đi lạc đôi khi bị chặn, nhưng yêu cầu tiếng vang ICMP có thể vượt qua. Tất nhiên, thành công của bạn ngày hôm nay rất khác nhau. Tôi hy vọng rằng tracertcác công cụ khác được viết vào thời điểm khi sử dụng phản hồi tiếng vang ICMP không có vấn đề gì.

Ngày nay, bạn không thể thực sự nói UDP tốt hơn ICMP. Hoặc một trong hai điều đó tốt hơn TCP. Nó hoàn toàn phụ thuộc vào con đường bạn đang đi qua và các chính sách bảo mật tại chỗ. Bạn có thể cần phải thử một, cả hai hoặc cả ba triển khai.

Nguồn:

http://ftp.arl.army.mil/~mike/ping.html http://www.inetdaemon.com/tutorials/troubledhasing/tools/traceroute/def định.shtml

Chỉnh sửa :

Đã thay đổi RFC từ IP (RFC791) thành ICMP (RFC792) có trong phần giới thiệu:

Để tránh hồi quy vô hạn của tin nhắn về tin nhắn, v.v., không có tin nhắn ICMP nào được gửi về tin nhắn ICMP.

Đó là bit khiến các nhà cung cấp không gửi lỗi "Vượt quá thời gian" cho các yêu cầu tiếng vang.

RFC1122, Yêu cầu đối với Máy chủ Internet, trong phần 3.2.2. là bản cập nhật cho biết các máy chủ không nên phản hồi các thông báo lỗi ICMP .