Tại sao tôi có thể theo dõi địa chỉ IP này, nhưng không ping?


21

Tôi có một địa chỉ IP và có thể truy tìm địa chỉ đó, nhưng tôi không thể ping.

Bạn thấy đấy, tôi có thể theo dõi 43.224.226.50:

dele-MBP:~ ll$ traceroute 43.224.226.50
traceroute to 43.224.226.50 (43.224.226.50), 64 hops max, 52 byte packets
 1  router.asus.com (192.168.2.1)  2.082 ms  1.039 ms  0.924 ms
 2  100.64.0.1 (100.64.0.1)  3.648 ms  3.795 ms  3.955 ms
 3  118.112.212.225 (118.112.212.225)  4.252 ms  4.569 ms  4.168 ms
 4  171.208.203.73 (171.208.203.73)  6.378 ms
    171.208.198.25 (171.208.198.25)  6.943 ms
    171.208.203.61 (171.208.203.61)  7.055 ms
 5  202.97.36.225 (202.97.36.225)  38.149 ms
    202.97.36.221 (202.97.36.221)  39.949 ms
    202.97.36.225 (202.97.36.225)  40.780 ms
 6  202.97.90.158 (202.97.90.158)  37.894 ms
    202.97.94.146 (202.97.94.146)  39.885 ms  39.354 ms
 7  202.97.38.166 (202.97.38.166)  45.324 ms
    202.97.39.149 (202.97.39.149)  40.097 ms
    202.97.94.77 (202.97.94.77)  40.580 ms
 8  202.97.51.118 (202.97.51.118)  374.218 ms
    202.97.27.238 (202.97.27.238)  187.573 ms
    202.97.86.138 (202.97.86.138)  197.524 ms
 9  218.30.53.190 (218.30.53.190)  201.597 ms
    218.30.54.190 (218.30.54.190)  194.194 ms
    218.30.53.190 (218.30.53.190)  204.027 ms
10  182.54.129.91 (182.54.129.91)  220.026 ms  282.360 ms
    et-11-1-5.r01.laxus01.us.bb.bgp.net (182.54.129.38)  185.700 ms
11  182.54.129.91 (182.54.129.91)  229.700 ms  508.509 ms  266.683 ms
12  * 212.95.128.2 (212.95.128.2)  565.161 ms *
13  43.224.226.50 (43.224.226.50)  200.531 ms  201.911 ms  191.566 ms

Nhưng tôi không thể ping nó:

dele-MBP:~ ll$ ping 43.224.226.50
PING 43.224.226.50 (43.224.226.50): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11

Nếu có lệnh cấm đối với ICMP, traceroutethì cũng không nên hoạt động. Lý do của nó là gì?

Tôi đã kiểm tra tường lửa của máy chủ bị dừng.


có thể là thời gian chờ cho ping quá hạn chế và nó đã thành công, với các giới hạn thời gian nhẹ nhàng hơn? Traceroute đã cho hơn 500 ms cho một số nút.
vsz

Câu trả lời:


39

Về một câu hỏi tương tự ở đây, Luke Savage đã giải thích nó một cách hoàn hảo:

Traceroute không phải là một giao thức, nó là một ứng dụng và các giao thức được sử dụng phụ thuộc vào việc triển khai bạn đang sử dụng. Chủ yếu đây là ICMP.

Có hai cách thực hiện chính:

tracert - tracert là một ứng dụng Windows sử dụng các gói ICMP với trường tăng dần để ánh xạ các bước nhảy đến địa chỉ đích cuối cùng.

traceroute - traceroute là một ứng dụng * nix có sẵn trên hầu hết các hệ thống dựa trên Linux, bao gồm các thiết bị mạng và trên các thiết bị của Cisco. Điều này sử dụng các gói UDP với trường TTL tăng dần để ánh xạ các bước nhảy đến đích cuối cùng.

Sự khác biệt giữa những điều này rất hữu ích khi một số mạng hiện đang chặn ICMP theo mặc định, vì vậy cả PING và tracert từ máy Windows sẽ không thành công nhưng một traceroute từ thiết bị Linux vẫn có thể hoạt động.


2
vậy, tại sao IP máy chủ của tôi có thể theo dõi nhưng không ping?
244boy

10
Từ đầu ra được chia sẻ của bạn, tôi có thể thấy rằng bạn đang sử dụng traceroutelệnh và tracertđiều đó khiến tôi nghĩ rằng bạn đang sử dụng hệ điều hành dựa trên Unix hoặc gnu. Trong câu trả lời tôi đã đề cập, bạn có thể thấy rằng các hệ thống dựa trên unix không được sử dụng ICMPcho traceroute. Nói cách khác, kể từ khi PINGđang sử dụng ICMP(mà tôi nghĩ bị chặn bởi hệ thống mà bạn đang cố gắng để đạt) và traceroute đang sử dụng UDPcác gói dữ liệu với một phương pháp incrementation của TTLtrường (mà tôi nghĩ không bị chặn tại hệ thống mà bạn đang cố gắng để tầm) PINGthất bại nhưng Traceroutethành công
naïveRSA

4
Thay vì thêm một bình luận mới vào bài đăng của bạn khi ai đó như 244boy gợi ý cải tiến, sẽ tốt hơn nếu bạn chỉnh sửa bài đăng của mình để những người trong tương lai đọc câu trả lời không phải đọc tất cả các bình luận để có câu trả lời đầy đủ.
Keeta - phục hồi Monica

@ naïveRSA Nói đúng ra, tracerouteđang sử dụng ICMP, ngay cả khi nó đang gửi UDP, cụ thể là nó mong đợi và đánh giá TTL exceededcác tin nhắn từ các bước nhảy trên đường. Một máy chủ chặn tất cả ICMP là một ý tưởng tồi, nhưng pingsẽ thất bại khi ICMP echocác yêu cầu hoặc trả lời bị chặn tại máy chủ đích
Hagen von Eitzen

17

Để thêm vào câu trả lời của @ naïveRSA , nếu có lọc / tường lửa trong đường dẫn, người ta cũng có thể gặp phải trường hợp gói "phản hồi tiếng vang" (ping) của ICMP bị chặn, nhưng gói "vượt thời gian" (tracert) của ICMP được cho phép . Điều này sẽ cho kết quả tương tự ngay cả khi chỉ sử dụng ICMP (Windows).

Trong cả hai trường hợp (người gửi sử dụng UDP hoặc ICMP), giao tiếp lỗi sẽ là ICMP (tức là nút trả lời gói ping hoặc tracer *).


6

Chúng ta hãy nhìn vào những gì xảy ra, phải không?

8.8.8.8 là một ví dụ tốt, bởi vì ít nhất từ ​​vị trí của tôi, tôi có thể tiếp cận nó cả với tracerouteping.

Trước tiên hãy thử ping 8.8.8.8và xem những gì sẽ xảy ra:

$ tcpdump -n host 8.8.8.8 or icmp
15:36:51.045994 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 0, length 64
15:36:51.062458 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 0, length 64
15:36:52.048350 IP 10.4.27.179 > 8.8.8.8: ICMP echo request, id 7215, seq 1, length 64
15:36:52.073657 IP 8.8.8.8 > 10.4.27.179: ICMP echo reply, id 7215, seq 1, length 64

Vì vậy, pinggửi một yêu cầu tiếng vang ICMP và mong đợi một phản hồi tiếng vang ICMP.

Bây giờ traceroute -n 8.8.8.8:

15:41:31.803324 IP 10.4.27.179.44838 > 8.8.8.8.33435: UDP, length 24
15:41:31.815184 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.815343 IP 10.4.27.179.44838 > 8.8.8.8.33436: UDP, length 24
15:41:31.819654 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.819791 IP 10.4.27.179.44838 > 8.8.8.8.33437: UDP, length 24
15:41:31.824609 IP 10.250.32.2 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.824754 IP 10.4.27.179.44838 > 8.8.8.8.33438: UDP, length 24
15:41:31.830506 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.830649 IP 10.4.27.179.44838 > 8.8.8.8.33439: UDP, length 24
15:41:31.834469 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.834565 IP 10.4.27.179.44838 > 8.8.8.8.33440: UDP, length 24
15:41:31.840962 IP 64.124.23.161 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.841061 IP 10.4.27.179.44838 > 8.8.8.8.33441: UDP, length 24
15:41:31.847440 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.847634 IP 10.4.27.179.44838 > 8.8.8.8.33442: UDP, length 24
15:41:31.853664 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.853761 IP 10.4.27.179.44838 > 8.8.8.8.33443: UDP, length 24
15:41:31.859221 IP 64.125.26.21 > 10.4.27.179: ICMP time exceeded in-transit, length 148
15:41:31.859269 IP 10.4.27.179.44838 > 8.8.8.8.33444: UDP, length 24
15:41:31.864149 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.864192 IP 10.4.27.179.44838 > 8.8.8.8.33445: UDP, length 24
15:41:31.870843 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.870922 IP 10.4.27.179.44838 > 8.8.8.8.33446: UDP, length 24
15:41:31.876200 IP 64.125.31.15 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.876352 IP 10.4.27.179.44838 > 8.8.8.8.33447: UDP, length 24
15:41:31.882148 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.882249 IP 10.4.27.179.44838 > 8.8.8.8.33448: UDP, length 24
15:41:31.890076 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.890156 IP 10.4.27.179.44838 > 8.8.8.8.33449: UDP, length 24
15:41:31.896100 IP 64.125.13.111 > 10.4.27.179: ICMP time exceeded in-transit, length 36
15:41:31.896163 IP 10.4.27.179.44838 > 8.8.8.8.33450: UDP, length 24
15:41:31.905037 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.905235 IP 10.4.27.179.44838 > 8.8.8.8.33451: UDP, length 24
15:41:31.913206 IP 108.170.242.225 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.913283 IP 10.4.27.179.44838 > 8.8.8.8.33452: UDP, length 24
15:41:31.923428 IP 108.170.242.241 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.923520 IP 10.4.27.179.44838 > 8.8.8.8.33453: UDP, length 24
15:41:31.932266 IP 108.170.237.9 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.932441 IP 10.4.27.179.44838 > 8.8.8.8.33454: UDP, length 24
15:41:31.939961 IP 209.85.251.9 > 10.4.27.179: ICMP time exceeded in-transit, length 76
15:41:31.940043 IP 10.4.27.179.44838 > 8.8.8.8.33455: UDP, length 24
15:41:31.947460 IP 108.170.237.21 > 10.4.27.179: ICMP time exceeded in-transit, length 60
15:41:31.947508 IP 10.4.27.179.44838 > 8.8.8.8.33456: UDP, length 24
15:41:31.954824 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33456 unreachable, length 36
15:41:31.954888 IP 10.4.27.179.44838 > 8.8.8.8.33457: UDP, length 24
15:41:31.963601 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33457 unreachable, length 36
15:41:31.963671 IP 10.4.27.179.44838 > 8.8.8.8.33458: UDP, length 24
15:41:31.972407 IP 8.8.8.8 > 10.4.27.179: ICMP 8.8.8.8 udp port 33458 unreachable, length 36

Vì vậy traceroute, ít nhất là việc triển khai tôi đã cài đặt, không gửi ICMP. Thay vào đó, nó sẽ gửi các gói UDP.

Có gì không hiển thị trong dấu vết này (mặc dù nó sẽ là, nếu tôi đưa cho tcpdumpmột -vđể tăng tính cách rườm rà) là tàu thăm dò đầu tiên có một ttl trong tổng số 1, và sau đó nó increments ttl cho tàu thăm dò sau đó. Điều này khiến các bộ định tuyến giữa tôi và 8.8.8.8 phản hồi với lỗi vượt quá ttl ICMP, đó là cách traceroute khám phá các bộ định tuyến giữa đây và đó.

Cuối cùng, ttl đủ dài để biến nó thành 8.8.8.8 và 8.8.8.8 phản hồi với lỗi không thể truy cập cổng ICMP, bởi vì nó không có quá trình lắng nghe trên cổng UDP 44838. Đây là cách traceroute biết nó đã đến đích cuối cùng .

Nếu một cái gì đó giữa đây và có chặn tất cả ICMP, thì cả ping và traceroute đều không hoạt động.

Nhưng thường thì không phải tất cả ICMP đều bị chặn, mặc dù nó cũng không phải là hiếm. Chặn tất cả ICMP là có vấn đề: ví dụ: nó phá vỡ đường dẫn phát hiện MTU , dựa trên lỗi yêu cầu phân mảnh ICMP. Các gói ICMP có một loại và một mã, và các nhà khai thác mạng có trách nhiệm sẽ chỉ chặn có chọn lọc một số loại hoặc mã, những loại có khả năng lạm dụng hoặc tiết lộ thông tin cụ thể.

Ví dụ: một số máy chủ sẽ không đáp ứng yêu cầu tiếng vang ICMP, và do đó ping sẽ không hoạt động. Ý tưởng là bằng cách không trả lời ping, kẻ tấn công sẽ khó phát hiện ra máy chủ nào tồn tại trên mạng. Trong thực tế điều này là nghi vấn, vì có nhiều cách khác để thăm dò máy chủ. Ví dụ: người ta có thể gửi TCP TCP đến cổng 80 để tìm máy chủ web.

Nhiều máy chủ cũng sẽ không gửi lỗi ICMP cổng không thể truy cập khi họ nhận được một datagram UDP hoặc TCP SYN đến một cổng mà họ không có quá trình lắng nghe và điều này phá vỡ traceroute. Một lần nữa ý tưởng là làm cho kẻ tấn công lập bản đồ mạng khó khăn hơn, nhưng một lần nữa, đây chỉ là một sự thất vọng nhỏ đối với kẻ tấn công.

Bởi vì traceroute là một chương trình và không phải bất kỳ giao thức cụ thể nào, nên nó có các cách thăm dò khác. Tất cả đều dựa vào việc tăng TTL để khám phá các bộ định tuyến, nhưng các loại đầu dò khác nhau có thể được gửi đi có thể có ít nhiều cơ hội để gợi ra phản hồi từ điểm cuối. Ví dụ, man tcpdumpdanh sách của tôi là một -Itùy chọn để sử dụng đầu dò echo ICMP, giống như ping. Nó cũng -Tphải sử dụng các đầu dò TCP SYN thay vì UDP. Nếu bạn biết một máy chủ sẽ phản hồi pingsau đó -Icó rất nhiều ý nghĩa. Nếu bạn biết máy chủ đang lắng nghe trên một cổng TCP cụ thể, thì -Tcó nghĩa là có thể kết hợp với -ptùy chọn để chọn cổng.

Thật không may, các tùy chọn này có thể yêu cầu khả năng root hoặc đặc biệt, vì vậy UDP làm cho một mặc định công bằng. Trong thực tế, một công cụ tương tự tracepath, có điều này để nói trong trang man của nó:

SỰ MIÊU TẢ

Nó theo dõi đường dẫn đến đích khám phá MTU dọc theo con đường này. Nó sử dụng cổng cổng UDP hoặc một số cổng ngẫu nhiên. Nó tương tự như traceroute, chỉ không yêu cầu đặc quyền siêu người dùng và không có tùy chọn ưa thích.


2

TLDR; ping có thể bị chặn (khối ICMP) trên một máy chủ từ xa nhưng traceroute vẫn có thể tìm thấy tuyến đến nó bằng cách sử dụng định tuyến mạng UDP hoặc TCP / IP (bất kỳ giao thức nào thực sự; ref /networkengineering//a/36509/ 58968 ). Lưu ý rằng ping của bạn có khả năng cũng có thể đến máy chủ (trừ khi có lẽ bạn có tường lửa rất thông minh chặn lưu lượng ping ICMP ở đâu đó), máy chủ sẽ không trả lời.


0

Linux sử dụng UDP thay vì ICMP để theo dõi, tường lửa không chặn cổng UDP đó


0

Bạn có thể cài đặt nmap (insecure.org) và sử dụng nping với UDP hoặc TCP và bất kỳ cổng nào. Hoạt động tuyệt vời trên các mạng với ping bị chặn ra bên ngoài.

Để ping một máy chủ web nping --tcp -p 80,443

Để ping máy chủ thời gian nping --udp -p 123

https://nmap.org/book/nping-man.html


0

Một câu trả lời ngắn gọn cho câu hỏi của bạn là pingtiện ích dựa trên giao thức ICMP đôi khi bị chặn tại tường lửa mạng hoặc tường lửa trên chính thiết bị. Lý do phổ biến nhất khiến quản trị viên mạng chặn ICMP là để ngăn chặn việc "quét" mạng mà họ cho là mối quan tâm bảo mật. Các traceroutetiện ích trên Linux sử dụng UDP, một giao thức hoàn toàn khác nhau, mà trong trường hợp này trong không bị chặn bởi các quản trị viên mạng. UDP có nhiều cách sử dụng và việc chặn này sẽ khiến nhiều thứ không thể sử dụng được trên mạng. Loại 'thông điệp điều khiển' ICMP cần pingcó là một tập hợp con của giao thức, nghĩa là chặn loại gói ICMP đó gây ra ít vấn đề hơn trên mạng và do đó có nhiều khả năng bị chặn hơn UDP.

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.