Mogę śledzić adres IP, ale nie mogę go pingować

W systemie Windows, jeśli przejdę do Google, otrzymam następujące informacje;

C:\Users\Dave>tracert -d -w 100 www.google.com

Tracing route to www.google.com [216.58.220.100]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    17 ms     *       16 ms  [redacted]
  3    17 ms    16 ms    17 ms  [redacted]
  4    34 ms    34 ms    34 ms  150.101.33.18
  5    35 ms    43 ms    33 ms  72.14.221.174
  6    33 ms    33 ms    33 ms  66.249.95.234
  7    31 ms    31 ms    31 ms  209.85.142.11
  8    33 ms    33 ms    38 ms  216.58.220.100

Trace complete.

Teraz, jeśli wyślę ping do trzeciego ostatniego adresu IP 66.249.95.234, otrzymam to ...

C:\Users\Dave>ping 66.249.95.234

Pinging 66.249.95.234 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 66.249.95.234:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Jak to się dzieje, że wewnętrzne polecenie ping do tracerta działa inaczej niż prawdziwy ping? Czym się różnią? Co muszę zrobić, aby ping działał jak tracert?

Wszystko to ma związek z działaniem tracert. Ping jest prostym ICMP od punktu A do punktu B, który przemierza sieci poprzez reguły routingu. Tracert działa zupełnie inaczej, mimo że używa ICMP.

Tracert działa, celując w ostatni przeskok, ale ograniczając TTL i czekając na komunikat przekroczony czas, a następnie zwiększając go o jeden do następnej iteracji. Dlatego odpowiedź, którą otrzymuje, nie jest odpowiedzią echa ICMP na żądanie echa ICMP od hosta po drodze, ale wiadomość przekroczoną w czasie z tego hosta - więc nawet jeśli używa ICMP, używa go w zupełnie inny sposób .

Możesz przeczytać więcej szczegółów na ten temat tutaj .

Przede wszystkim twoje dwa polecenia wysyłają pakiety o różnych docelowych adresach IP. Oznacza to, że mogą podążać różnymi trasami.

Gdy zobaczysz 66.249.95.234trasę w kierunku 216.58.220.100, możesz założyć, że pakiety z adresem docelowym 66.249.95.234będą korzystać z tej samej trasy, aż dotrą do tego punktu. Nie jest to jednak prawidłowe założenie.

Jest całkowicie ważne, aby trasa 66.249.95.234była dłuższa niż ta do 216.58.220.100. Czasami zdarza się nawet, że nie ma trasy, która mogłaby zabrać twoje pakiety do tego routera pośredniego, ale nie byłaby to dobrze zaprojektowana sieć, gdyby tak było.

Nie wiem, czy używane polecenia tracerti pingużywają tego samego protokołu. Większość implementacji ping używa pakietów żądań echa ICMP. Istnieją jednak implementacje traceroute obsługujące szeroki zakres protokołów, w tym żądanie echa ICMP, TCP SYN i pakiety UDP. Jeśli obie wykorzystują różne protokoły, może to mieć wpływ na uzyskanie różnych wyników.

Wreszcie, nawet jeśli wszystkie pakiety miałyby dotrzeć 66.249.95.234, możliwe, 66.249.95.234że zachowywałyby się zupełnie inaczej w zależności od tego, czy muszą:

• Prześlij pakiet
• Wywołaj błąd ICMP na pakiecie skierowanym do siebie
• Wywołaj błąd ICMP na pakiecie skierowanym do kogoś innego

Wybór dyskretnego upuszczenia pakietów tylko w jednym z trzech przypadków oczywiście zepsuje wiele narzędzi do diagnostyki sieci, co i tak nie powstrzymuje niektórych administratorów systemu.

Ponieważ bezpieczeństwo w sieci stale rośnie, jedną łatwą rzeczą, którą wiele osób robi teraz, jest w zasadzie wyłączenie niektórych aspektów protokołu ICMP. Zapobiega to reagowaniu na traceroutes i zwracaniu nazwy FQDN z przeskoku. Czasami administratorzy blokują pewne rzeczy, aby nawet ping nie działał. Jest to decyzja administratora danego systemu.

Istnieje również możliwość, że system obsługuje duże obciążenie sieciowe, ICMP ma generalnie bardzo niski priorytet przetwarzania w porównaniu do rzeczywistych danych.