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
źródło
Odpowiedzi:
Na podobne pytanie tutaj Luke Savage wyjaśnił to doskonale:
źródło
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żywanyICMPdlatraceroute. Innymi słowy, ponieważPINGużywanieICMP(które moim zdaniem jest blokowane przez system, do którego próbujesz dotrzeć), a traceroute używaUDPpakietów z metodą inkrementacjiTTLpola (które moim zdaniem nie jest blokowane w systemie, do którego próbujesz dotrzeć)PINGkończy się niepowodzeniem ale sięTracerouteudaje.traceroutejest za pomocą ICMP, nawet jeśli jest wysyłanie UDP, a mianowicie, że spodziewa się i oceniaTTL exceededwiadomości z chmielu w drodze. Host, który blokuje wszystkie ICMP, to zły pomysł, alepingnie powiedzie się, gdyICMP echożądania lub odpowiedzi zostaną zablokowane na hoście docelowymAby 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 *).
źródło
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
tracerouteiping.Najpierw spróbujmy
ping 8.8.8.8zobaczyć, co się stanie:pingWysyła więc żądanie echa ICMP i oczekuje odpowiedzi echa ICMP.Teraz
traceroute -n 8.8.8.8: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-vOstatecznie 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:źródło
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.
źródło
Linux używa UDP zamiast ICMP dla traceroute, zapora nie blokowała tego portu UDP
źródło
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
źródło
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” ICMPpingjest 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.źródło