Saya dapat tracert ke alamat IP, tetapi tidak melakukan ping

Di Windows, jika saya tracert ke Google saya mendapatkan yang berikut;

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.

Sekarang, jika saya ping alamat IP terakhir ketiga dari 66.249.95.234, saya mendapatkan ini ...

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),

Bagaimana mungkin 'ping' internal ke tracert bekerja dengan cara berbeda dengan ping sebenarnya? Bagaimana mereka berbeda? Apa yang harus saya lakukan agar ping berfungsi seperti tracert?

Itu semua ada hubungannya dengan bagaimana tracert bekerja. Ping adalah ICMP langsung dari titik A ke titik B, yang melintasi jaringan melalui aturan perutean. Tracert bekerja sangat berbeda, meskipun menggunakan ICMP.

Tracert bekerja dengan menargetkan hop terakhir, tetapi membatasi TTL dan menunggu waktu melebihi pesan, dan kemudian meningkatkannya dengan satu untuk iterasi berikutnya. Oleh karena itu, respons yang didapat bukanlah jawaban gema ICMP untuk permintaan gema ICMP dari host di sepanjang jalan, tetapi waktu melebihi pesan dari host tersebut - jadi meskipun menggunakan ICMP, ia menggunakannya dengan cara yang sangat berbeda. .

Anda dapat membaca lebih detail tentang ini di sini .

Pertama-tama, kedua perintah Anda adalah mengirim paket dengan alamat IP tujuan yang berbeda. Itu berarti mereka dapat mengambil rute yang berbeda.

Ketika Anda melihat 66.249.95.234rute menuju 216.58.220.100, Anda mungkin berasumsi bahwa paket dengan alamat tujuan 66.249.95.234akan menggunakan rute yang sama hingga mencapai titik itu. Namun itu bukan asumsi yang valid.

Ini sepenuhnya berlaku untuk rute yang 66.249.95.234lebih panjang dari rute ke 216.58.220.100. Kadang-kadang bahkan terjadi bahwa tidak ada rute yang dapat membawa paket Anda ke router perantara, tetapi itu tidak akan menjadi jaringan yang dirancang dengan baik, jika itu masalahnya.

Saya tidak tahu apakah tracertdan pingperintah yang Anda gunakan keduanya menggunakan protokol yang sama. Sebagian besar implementasi ping menggunakan paket permintaan gema ICMP. Namun implementasi traceroute mendukung berbagai protokol termasuk permintaan gema ICMP, TCP SYN, dan paket UDP. Jika keduanya menggunakan protokol yang berbeda, itu bisa menjadi faktor yang berkontribusi untuk melihat hasil yang berbeda.

Akhirnya, bahkan jika semua paket harus dijangkau 66.249.95.234, ada kemungkinan bahwa 66.249.95.234akan berperilaku sangat berbeda tergantung pada apakah perlu:

• Teruskan paket
• Menghasilkan kesalahan ICMP pada paket yang ditujukan untuk dirinya sendiri
• Menghasilkan kesalahan ICMP pada paket yang ditujukan kepada orang lain

Memilih untuk secara diam-diam menjatuhkan paket hanya dalam satu dari tiga kasus ini jelas akan merusak banyak alat diagnostik jaringan, yang bagaimanapun juga tidak menghentikan beberapa administrator sistem untuk melakukannya.

Karena keamanan pada jaringan terus meningkat, satu hal mudah yang banyak orang lakukan sekarang adalah pada dasarnya menonaktifkan aspek protokol ICMP. Ini mencegah menanggapi traceroute dan mengembalikan FQDN dari hop. Terkadang administrator mengunci sesuatu dengan ketat sehingga ping tidak berfungsi. Ini adalah keputusan administrator sistem yang terlibat.

Ada juga kemungkinan bahwa sistem ini menangani beban jaringan yang luas, ICMP umumnya sangat rendah prioritasnya dalam pemrosesan dibandingkan dengan data nyata.