Dlaczego mogę śledzić ten adres IP, ale nie mogę pingować?

21

Mam adres IP i mogę go śledzić, ale nie mogę pingować.

Widzisz, mogę śledzić 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

Ale nie mogę pingować:

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

Jeśli istnieje zakaz na ICMP, traceroutenie powinien również działać. Jaki jest tego powód?

Sprawdziłem, czy zapora serwera jest zatrzymana.

ping  networking  icmp  traceroute 
— 244boy
źródło
czy może być tak, że limit czasu dla ping jest zbyt restrykcyjny i byłby udany, biorąc pod uwagę łagodniejsze terminy? Traceroute dał ponad 500 ms dla niektórych węzłów.
— vsz
Czy jakaś odpowiedź ci pomogła? Jeśli tak, powinieneś zaakceptować odpowiedź, aby pytanie nie wyskakiwało wiecznie w poszukiwaniu odpowiedzi. Alternatywnie możesz podać i zaakceptować własną odpowiedź.
— Ron Maupin

Odpowiedzi:

39

Na podobne pytanie tutaj Luke Savage wyjaśnił to doskonale:

Traceroute nie jest samym protokołem, jest aplikacją, a stosowane protokoły zależą od implementacji, której używasz. Przede wszystkim jest to ICMP.

Istnieją dwie główne implementacje:

tracert - tracert to aplikacja Windows, która wykorzystuje pakiety ICMP z rosnącym polem TTL do mapowania przeskoków do końcowego adresu docelowego.

traceroute - traceroute to aplikacja * nix dostępna w większości systemów opartych na Linuksie, w tym na urządzeniach sieciowych i na urządzeniach Cisco. Wykorzystuje to pakiety UDP z rosnącym polem TTL do mapowania chmielu do końcowego miejsca docelowego.

Różnica między nimi jest przydatna, ponieważ niektóre sieci domyślnie blokują teraz ICMP, więc zarówno PING, jak i tracert z komputera z systemem Windows zawiodą, ale traceroute z urządzenia Linux może nadal działać.

— naïveRSA
źródło
2
więc dlaczego mój adres IP serwera może śledzić, ale nie pingować?
— 244boy
10
Z twojego wspólnego wyjścia widzę, że używasz traceroutepolecenia, a nie to, tracertco skłoniło mnie do myślenia, że ​​używasz systemu operacyjnego opartego na Uniksie lub GNU. W odpowiedzi wspomniałem widać, że systemy UNIX nie jest używany ICMPdla traceroute. Innymi słowy, ponieważ PINGużywanie ICMP(które moim zdaniem jest blokowane przez system, do którego próbujesz dotrzeć), a traceroute używa UDPpakietów z metodą inkrementacji TTLpola (które moim zdaniem nie jest blokowane w systemie, do którego próbujesz dotrzeć) PINGkończy się niepowodzeniem ale się Tracerouteudaje.
— naïveRSA
4
Zamiast dodawać nowy komentarz do swojego postu, gdy ktoś taki jak 244boy zasugeruje ulepszenie, lepiej będzie edytować swój post, aby przyszłe osoby czytające odpowiedź nie musiały czytać wszystkich komentarzy, aby uzyskać pełną odpowiedź.
— Keeta
@ naïveRSA Ściśle mówiąc, traceroutejest za pomocą ICMP, nawet jeśli jest wysyłanie UDP, a mianowicie, że spodziewa się i ocenia TTL exceededwiadomości z chmielu w drodze. Host, który blokuje wszystkie ICMP, to zły pomysł, ale pingnie powiedzie się, gdy ICMP echożądania lub odpowiedzi zostaną zablokowane na hoście docelowym
— Hagen von Eitzen
17

Aby dodać do odpowiedzi @ naïveRSA , jeśli na ścieżce znajduje się filtrowanie / zapora ogniowa, można również mieć sytuację, w której pakiet ICMP „odpowiedź echa” (ping) jest zablokowany, ale pakiet ICMP „czas przekroczony” (tracert) jest dozwolony . Dałoby to takie same wyniki, nawet jeśli używany jest tylko ICMP (Windows).

W obu przypadkach (nadawca korzystający z UDP lub ICMP) komunikacją o błędzie będzie ICMP (tj. Węzeł odpowiada na pakiet ping lub znacznik *).

— Arjan
źródło
6

Spójrzmy, co się stanie, prawda?

8.8.8.8 stanowi dobry przykład, ponieważ przynajmniej z mojej lokalizacji mogę do niego dotrzeć zarówno za pomocą, jak traceroutei ping.

Najpierw spróbujmy ping 8.8.8.8zobaczyć, co się stanie:

$ 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

pingWysyła więc żądanie echa ICMP i oczekuje odpowiedzi echa ICMP.

Teraz 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

Tak więc tracerouteprzynajmniej implementacja, którą zainstalowałem, nie wysyła ICMP. Raczej wysyła pakiety UDP.

Co nie jest widoczne w tym śladu (choć byłoby, gdybym dał aby zwiększyć szczegółowość) to, że pierwsze sondy mają TTL 1, a następnie zwiększa ona TTL dla późniejszych sond. To powoduje, że routery między mną a 8.8.8.8 odpowiadają błędem przekroczenia ttl ICMP, w ten sposób traceroute wykrywa routery pomiędzy tu i tam.tcpdump-v

Ostatecznie ttl jest wystarczająco długi, aby przejść do wersji 8.8.8.8, a 8.8.8.8 odpowiada błędem nieosiągalnego portu ICMP, ponieważ nie ma procesu nasłuchującego na porcie UDP 44838. W ten sposób traceroute wie, że osiągnął ostateczne miejsce docelowe .

Jeśli coś pomiędzy tu i tam blokuje cały ICMP, to ping ani traceroute nie będą działać.

Ale zwykle nie jest tak, że cały ICMP jest zablokowany, chociaż nie jest to również rzadkie. Blokowanie wszystkich ICMP jest problematyczne: na przykład psuje ścieżkę wykrywania MTU , która polega na błędzie wymaganym fragmentacji ICMP. Pakiety ICMP mają typ i kod, a odpowiedzialni operatorzy sieci będą tylko selektywnie blokować niektóre typy lub kody, które stwarzają ryzyko nadużycia lub ujawniają określone informacje.

Na przykład niektóre hosty w ogóle nie odpowiadają na żądanie echa ICMP, dlatego ping nie będzie działał. Chodzi o to, że nie odpowiadając na pingi, atakującemu trudniej jest dowiedzieć się, jakie hosty istnieją w sieci. W praktyce jest to wątpliwe, ponieważ istnieją inne sposoby sondowania hosta. Na przykład można wysłać TCP SYN do portu 80, aby znaleźć serwery WWW.

Wiele hostów również nie wyśle ​​błędu nieosiągalnego portu ICMP, gdy otrzyma datagram UDP lub TCP SYN do portu, na którym nie ma procesu nasłuchującego, a to psuje traceroute. Ponownie chodzi o to, aby utrudnić atakującemu mapowanie sieci, ale znowu jest to tylko niewielka frustracja dla atakującego.

Ponieważ traceroute jest programem, a nie żadnym konkretnym protokołem, ma inne sposoby sondowania. Wszystkie polegają na zwiększaniu TTL w celu wykrycia routerów, ale można wysyłać różne rodzaje sond, które mogą mieć mniej lub bardziej szansę na wywołanie odpowiedzi z punktu końcowego. Na przykład moja man tcpdumplista zawiera -Iopcję korzystania z sond echowych ICMP, takich samych jak ping. Musi także -Tużywać sond TCP SYN zamiast UDP. Jeśli wiesz, że gospodarz zareaguje, pingwówczas -Ima to sens. Jeśli wiesz, że host nasłuchuje na określonym porcie TCP, to -Tma sens, być może w połączeniu z -popcją wyboru portu.

Niestety te opcje mogą wymagać uprawnień roota lub specjalnych, więc UDP stanowi domyślną opcję domyślną. W rzeczywistości podobne narzędzie, tracepathma to do powiedzenia na swojej stronie podręcznika:

OPIS

Śledzi ścieżkę do miejsca docelowego, odkrywając MTU wzdłuż tej ścieżki. Wykorzystuje port portu UDP lub jakiś losowy port. Jest podobny do traceroute, tylko nie wymaga uprawnień administratora i nie ma żadnych wymyślnych opcji.

— Phil Frost
źródło
2

TLDR; pingi mogą być blokowane (blok ICMP) na zdalnym hoście, ale traceroute nadal może znaleźć drogę do niego za pomocą standardowego routingu sieciowego UDP lub TCP / IP (naprawdę dowolny protokół; zob. /networkengineering//a/36509/ 58968 ). Pamiętaj, że twój ping prawdopodobnie może również dotrzeć do hosta (chyba że masz bardzo inteligentną zaporę blokującą gdzieś ruch ping ICMP), host po prostu nie odpowiada.

— Roel Van de Paar
źródło
0

Możesz zainstalować nmap (insecure.org) i używać nping z UDP lub TCP i dowolnym portem. Działa świetnie w sieciach z wychodzącymi zablokowanymi pingami.

Aby wysłać ping do serwera WWW, nping --tcp -p 80,443

Aby wysłać polecenie ping do serwera czasu nping --udp -p 123

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

— Michael Hubbard
źródło
0

Krótka odpowiedź na twoje pytanie jest taka, że pingnarzędzie opiera się na protokole ICMP, który czasami jest blokowany w zaporze sieciowej lub zaporze na samym urządzeniu. Najczęstszym powodem, dla którego administratorzy sieci blokują ICMP, jest zapobieganie „skanowaniu” sieci, którą uważają za zagrożenie bezpieczeństwa. tracerouteNarzędzie Linux korzysta z UDP, zupełnie innego protokołu, która w tym przypadku nie został zablokowany przez administratorów sieci. UDP ma wiele zastosowań, a jego zablokowanie spowodowałoby, że wiele rzeczy byłoby bezużytecznych w sieci. Potrzebny typ „komunikatu sterującego” ICMP pingjest podzbiorem protokołu, co oznacza, że ​​blokowanie tego typu pakietu ICMP powoduje mniej problemów w sieci i dlatego jest bardziej prawdopodobne, że zostanie zablokowane niż UDP.

— Cybernauta
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.