Là đầu ra theo dõi chính xác liên quan đến đường dẫn thực tế đến một mục tiêu


3

Các trang nam đối với traceroute nói "traceroute theo dõi các gói tuyến đường được lấy từ một mạng IP trên đường đến một máy chủ nhất định." , nhưng trong khi nghiên cứu về chủ đề này, tôi không thể tìm thấy bất kỳ dữ liệu thống kê / công trình khoa học nào về việc Traceroute chính xác thực sự như thế nào nếu tuyến đường được hiển thị là tuyến đường thực sự (có thể các gói khác nhau sử dụng các tuyến hoàn toàn khác nhau) và lỗi là gì lề là và liệu có thể, do các giao thức định tuyến khác nhau, ping Traceroute có thể hiển thị một đường dẫn hoàn toàn khác với yêu cầu TCP tiếp theo hoặc thậm chí các gói ping thực tế sẽ mất.

Tác phẩm duy nhất tôi tìm thấy, ngụ ý rằng dấu vết Ping có thể không hoàn hảo là tài liệu về kẻ lừa đảo trong đó nói "ping rất hữu ích để đo độ trễ đầu cuối và mất, tìm kiếm địa chỉ IP phản hồi và phân loại hành vi của máy chủ bằng cách kiểm tra cách chúng phản hồi với đầu dò. "và (theo như tôi hiểu) sử dụng MDA traceroute để phát hiện đường dẫn. Do đó, ngụ ý rằng sử dụng PING có thể không có kết quả mong muốn.

Vì vậy, câu hỏi của tôi là: Làm thế nào đáng tin cậy là phát hiện đường dẫn bằng Traceroute (cũng tại sao)? Tôi đánh giá rất cao các liên kết đi sâu vào chi tiết về chủ đề đó, nhưng một lời giải thích chung tại sao hoặc tại sao không cũng đủ.


Có một số thông tin tốt về tác dụng của cân bằng tải tại paris-traceroute.net . (Đây là một công cụ tuyên bố là vượt trội so với traceroute thông thường khi đối mặt với bộ cân bằng tải).
Duncan Jones

Câu trả lời:


3

Điều quan trọng nhất cần nhớ là tuyến đường không tĩnh . Theo thiết kế, các tuyến đường trên internet công cộng luôn thay đổi. Đôi khi các tuyến đường thay đổi do cân bằng tải; đôi khi chúng thay đổi vì một nút đi xuống; đôi khi chúng thay đổi bởi vì các bộ định tuyến quyết định ngẫu nhiên theo nghĩa đen để thay đổi các quy tắc định tuyến (chỉ để làm mọi thứ rung chuyển).

Từ góc nhìn của người dùng cuối không có quyền truy cập cấp Quản trị viên hệ thống đến mọi bộ định tuyến trung gian và trung tâm internet duy nhất giữa nguồn gốc và đích của gói, bạn phải coi nó giống như Nguyên tắc không chắc chắn của Heisenberg.

Những điều cần cân nhắc:

  1. Dựa trên "đích" IP được khai báo trong gói của bạn, các bộ định tuyến trung gian có thể quyết định định tuyến bạn khác . Do đó, nếu một traceroute là một nỗ lực để ánh xạ tuần tự các bộ định tuyến giữa nguồn và đích, thì một traceroute có thể bị loại bỏ khỏi khóa học bằng cách các tuyến có các đường khác nhau tùy thuộc vào nút nào bạn đang cố gắng tiếp cận.

  2. Không phải tất cả các bộ định tuyến sẽ lắng nghe các ping ICMP hoặc UDP. Họ có thể chọn âm thầm bỏ qua lưu lượng này và chỉ thả nó tại NIC (thường là để giúp chống lại DDoS). Điều này có thể làm nản lòng nỗ lực của bạn để lập bản đồ một tuyến đường.

  3. Ngay cả khi bạn ánh xạ thành công tuyến đường và tất cả các nút trung gian trả lời ping của bạn và không cố gắng thực hiện với nỗ lực ánh xạ của bạn, tuyến đường có thể thay đổi cho các gói tiếp theo bạn gửi bằng giao thức "thực" (hoặc ngay cả khi bạn thử một traceroute lần thứ hai).

  4. QoS có thể khiến các mạng hoạt động bình thường định tuyến lưu lượng khác nhau. Chẳng hạn, VoIP hoặc phát trực tuyến video có thể đi theo một con đường, trong khi duyệt web thông thường có thể đi theo một con đường khác.

  5. Các kiểu lưu lượng có thể làm cho định tuyến khác nhau. Chẳng hạn, ngay cả khi không xem xét QoS, bạn có thể nhận được một đường dẫn khác cho FTP so với bạn nhận được cho SSH. Các nút trung gian có thể tập thể dục bất cứ quyết định nào .

  6. Về lý thuyết, các bộ định tuyến trung gian cũng có thể, nếu họ muốn, biến nỗ lực theo dõi của bạn thành một chu kỳ vô hạn: nút A trỏ đến nút B, nút B trỏ đến nút C và nút C quay lại nút A. Không có gì dừng lại các bộ định tuyến thực hiện điều này (tôi không chắc tại sao họ lại chọn, nhưng đó là khả năng) cho các gói được phát hiện là "traceroutes" (ping ICMP hoặc UDP). Nó có thể làm điều này để cố gắng giảm bớt nỗ lực của bạn, hoặc vì bất kỳ lý do nào khác.

Thuật toán Khám phá Đa năng rất hữu ích, nhưng nó không thể khắc phục những hạn chế về mặt lý thuyết này.

Về cơ bản, để xác định đường dẫn, bạn phải gửi một hoặc nhiều gói. Các gói đó có thể được định tuyến theo bất kỳ cách nào mà các nút trung gian thấy phù hợp. Nhưng ngay khi bạn gửi một gói khác, hoàn toàn không có gì ngăn cản các bộ định tuyến thay đổi đường dẫn. Đây là một dạng tương tự mạng của Nguyên lý bất định Heisenberg.

Đường dẫn là không lâu tạm thời . Bạn không nên dựa vào thông tin nhận được từ một traceroute cho bất kỳ điều gì quan trọng, ngoại trừ để chẩn đoán sự cố kết nối trên mạng nơi bạn đã có kiến ​​thức sâu về cấu trúc liên kết (ví dụ trên mạng LAN công ty phức tạp) và có thể kiểm soát hành vi của các nút tham gia. Nếu bất kỳ nút nào trong số các nút tham gia không phải là "của bạn" (nếu bạn không thể đăng nhập vào chúng bằng các đặc quyền của quản trị viên hệ thống), thì kết quả của traceroute là tùy ý.

Mặt khác, nếu tất cả các nút tham gia của bạn, bạn có thể, với tư cách là quản trị viên, kiểm soát hành vi chính xác của từng nút. Chẳng hạn, bạn có thể kích hoạt ICMP và thiết lập tĩnh tuyến đường (tuyến đường không thay đổi). Sau đó, bạn có thể tự tin rằng traceroute của bạn là chính xác. Nhưng nếu bạn đặt một bộ cân bằng tải ở giữa, thì bạn sẽ phải nhận thức được hành vi của bộ cân bằng tải và cách nó có thể chuyển tuyến khá nhiều khi cần thiết (mặc dù nó thường không ngẫu nhiên và thường không cố gắng lừa dối bạn về mục đích).


1
Cảm ơn bạn vì câu trả lời xuyên suốt và chi tiết này cung cấp một lời giải thích tuyệt vời về các tính chất lý thuyết của traceroute. Nhưng liên quan đến kết luận của bạn, tôi (chỉ) đã chạy qua ["Y. Zhang, V.Paxson và S.Shenker, tạm thời Sự ổn định của các thuộc tính đường dẫn Internet: Định tuyến, mất và thông lượng, báo cáo trong Báo cáo kỹ thuật ACIRI, tháng 5 năm 2000.] nói rằng hầu hết các tuyến dường như ổn định ít nhất trong một ngày liên quan đến nhiều lần chạy traceroute. Mặc dù nó không giải quyết được QoP và các điểm khác do bạn thực hiện liên quan đến các giao thức "thực".
Sim

1
Đó là một bài báo thú vị (không đọc hết) và kết quả có thể đúng về mặt thực nghiệm, nhưng xin lưu ý rằng bài báo đó là từ năm 2000 ; Internet đã thay đổi rất nhiều kể từ đó. Kết quả của họ có thể không còn hiệu lực nữa.
allquixotic

về nguyên nhân, tôi chỉ muốn đề cập đến nó ở đây để biết thêm thông tin. Đáng buồn thay, đây là bài báo cập nhật nhất mà tôi tìm thấy cho đến nay
Sim
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.