Mengapa saya bisa melacak ke alamat IP ini, tetapi tidak melakukan ping?

21

Saya memiliki alamat IP dan dapat melacaknya, tetapi saya tidak bisa melakukan ping.

Anda lihat, saya dapat melacak 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

Tapi saya tidak bisa melakukan ping:

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

Jika ada larangan ICMP, tracerouteseharusnya tidak berhasil juga. Apa alasannya?

Saya memeriksa firewall server dihentikan.

ping  networking  icmp  traceroute 
— 244boy
sumber
mungkinkah batas waktu untuk ping terlalu ketat, dan itu akan berhasil, mengingat batas waktu yang lebih lunak? Traceroute memberikan lebih dari 500 ms untuk beberapa node.
— vsz
Apakah ada jawaban yang membantu Anda? Jika demikian, Anda harus menerima jawabannya sehingga pertanyaan tidak terus muncul selamanya, mencari jawaban. Atau, Anda dapat memberikan dan menerima jawaban Anda sendiri.
— Ron Maupin

Jawaban:

39

Pada pertanyaan serupa di sini Luke Savage menjelaskannya dengan sempurna:

Traceroute bukan protokol itu sendiri, itu adalah aplikasi dan protokol yang digunakan tergantung pada implementasi yang Anda gunakan. Terutama ini adalah ICMP.

Ada dua implementasi utama:

tracert - tracert adalah aplikasi Windows yang menggunakan paket ICMP dengan bidang TTL yang bertambah untuk memetakan hop ke alamat tujuan akhir.

traceroute - traceroute adalah aplikasi * nix yang tersedia di sebagian besar sistem berbasis Linux, termasuk perangkat jaringan, dan pada perangkat Cisco. Ini menggunakan paket UDP dengan bidang TTL yang bertambah untuk memetakan hop ke tujuan akhir.

Perbedaan antara ini berguna untuk diketahui karena beberapa jaringan sekarang memblokir ICMP secara default sehingga PING dan tracert dari mesin Windows akan gagal tetapi traceroute dari perangkat Linux mungkin masih berfungsi.

— naïveRSA
sumber
2
jadi, mengapa IP server saya dapat traceroute tetapi tidak ping?
— 244boy
10
Dari output yang Anda bagikan, saya dapat melihat bahwa Anda menggunakan tracerouteperintah dan bukan tracertyang membuat saya berpikir bahwa Anda menggunakan sistem operasi berbasis Unix atau gnu. Dalam jawaban yang saya sebutkan Anda dapat melihat bahwa sistem berbasis unix tidak digunakan ICMPuntuk traceroute. Dengan kata lain, karena PINGmenggunakan ICMP(yang saya pikir diblokir oleh sistem yang Anda coba jangkau) dan traceroute menggunakan UDPpaket dengan TTLbidang metode penambahan (yang menurut saya tidak diblokir pada sistem yang Anda coba jangkau) PINGgagal tetapi Tracerouteberhasil.
— naïveRSA
4
Daripada menambahkan komentar baru ke posting Anda ketika seseorang seperti 244boy menyarankan peningkatan, akan lebih baik untuk mengedit posting Anda sehingga orang-orang di masa depan yang membaca jawabannya tidak harus membaca semua komentar untuk mendapatkan jawaban lengkap.
— Keeta - mengembalikan Monica
@ naïveRSA Tegasnya, tracerouteyang menggunakan ICMP, bahkan jika itu mengirim UDP, yaitu mereka mengharapkan dan mengevaluasi TTL exceededpesan dari hop di jalan. Sebuah host yang memblokir semua ICMP adalah ide yang buruk, tetapi pingakan gagal juga ketika ICMP echopermintaan atau balasan diblokir di host target
— Hagen von Eitzen
17

Untuk menambahkan jawaban @ naïveRSA , jika ada pemfilteran / firewall di jalur, orang juga dapat memiliki situasi di mana paket ICMP "echo reply" (ping) diblokir, tetapi paket ICMP "melebihi waktu" (tracert) dibolehkan . Ini akan memberikan hasil yang sama bahkan ketika hanya ICMP (Windows) yang digunakan.

Dalam kedua kasus (pengirim menggunakan UDP atau ICMP) komunikasi kesalahan akan menjadi ICMP (yaitu node membalas paket ping atau tracer *).

— Arjan
sumber
6

Mari kita lihat apa yang terjadi, oke?

8.8.8.8 membuat contoh yang baik, karena setidaknya dari lokasi saya, saya dapat mencapainya dengan traceroutedan ping.

Pertama mari kita coba ping 8.8.8.8dan perhatikan apa yang terjadi:

$ 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

Maka pingkirimkan permintaan gema ICMP, dan mengharapkan balasan gema ICMP.

Sekarang 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

Jadi traceroute, setidaknya implementasi yang saya instal, tidak mengirim ICMP. Sebaliknya, ia mengirim paket UDP.

Apa yang tidak terlihat dalam jejak ini (meskipun itu akan, jika saya memberikan tcpdumpsebuah -vmeningkatkan bertele-tele) adalah bahwa probe pertama memiliki TTL dari 1, dan kemudian akan menambahkan TTL untuk probe nanti. Hal ini menyebabkan router antara saya dan 8.8.8.8 merespons dengan kesalahan melebihi ICMP, yang merupakan cara traceroute menemukan router antara sana-sini.

Akhirnya ttl cukup panjang untuk mencapai 8.8.8.8, dan 8.8.8.8 merespons dengan kesalahan ICMP port unreachable, karena ia tidak memiliki proses mendengarkan pada port UDP 44838. Ini adalah bagaimana traceroute tahu itu mencapai tujuan akhir .

Jika sesuatu antara sini dan di sana memblokir semua ICMP, maka ping atau traceroute tidak akan berfungsi.

Tapi biasanya tidak semua ICMP diblokir, meskipun itu juga tidak jarang. Memblokir semua ICMP bermasalah: misalnya memecah jalur penemuan MTU , yang bergantung pada kesalahan fragmentasi ICMP yang diperlukan. Paket ICMP memiliki jenis dan kode, dan operator jaringan yang bertanggung jawab hanya akan secara selektif memblokir beberapa jenis atau kode, yang berpotensi menimbulkan penyalahgunaan atau mengungkapkan informasi tertentu.

Misalnya, beberapa host tidak akan menanggapi permintaan gema ICMP sama sekali, dan dengan demikian ping tidak akan berfungsi. Idenya adalah bahwa dengan tidak menanggapi ping, penyerang akan lebih sulit untuk menemukan host apa yang ada di jaringan. Dalam praktiknya hal ini dipertanyakan, karena ada cara lain untuk mencari host. Misalnya, seseorang dapat mengirim TCP SYN ke port 80 untuk menemukan server web.

Banyak host juga tidak akan mengirim kesalahan ICR port ICMP ketika mereka mendapatkan datagram UDP atau TCP SYN ke port di mana mereka tidak memiliki proses mendengarkan, dan ini merusak traceroute. Sekali lagi idenya adalah untuk membuatnya lebih sulit bagi penyerang untuk memetakan jaringan, tetapi sekali lagi ini hanya frustrasi kecil bagi penyerang.

Karena traceroute adalah program dan bukan protokol tertentu, ia memiliki cara lain untuk menyelidik. Mereka semua bergantung pada peningkatan TTL untuk menemukan router, tetapi berbagai jenis probe dapat dikirim yang mungkin memiliki lebih atau kurang dari kesempatan untuk memperoleh respons dari titik akhir. Misalnya, man tcpdumpdaftar saya -Iopsi untuk menggunakan probe gema ICMP, sama seperti ping. Itu juga harus -Tmenggunakan probe TCP SYN bukan UDP. Jika Anda tahu tuan rumah akan merespons pingmaka -Imasuk akal. Jika Anda tahu host mendengarkan pada port TCP tertentu, maka -Tmasuk akal, mungkin bersama dengan -popsi untuk memilih port.

Sayangnya opsi ini mungkin memerlukan root atau kemampuan khusus, sehingga UDP membuat default yang adil. Bahkan alat serupa,, tracepathmengatakan ini di halaman manualnya:

DESKRIPSI

Ini melacak jalur ke tujuan menemukan MTU di sepanjang jalur ini. Menggunakan port port UDP atau port acak. Ini mirip dengan traceroute, hanya saja tidak memerlukan hak pengguna super dan tidak memiliki opsi mewah.

— Phil Frost
sumber
2

TLDR; ping dapat diblokir (blok ICMP) pada host jarak jauh tetapi traceroute masih dapat menemukan rute ke sana menggunakan routing jaringan standar UDP atau TCP / IP (protokol apa pun; ref /networkengineering//a/36509/ 58968 ). Perhatikan bahwa ping Anda kemungkinan juga dapat mencapai host (kecuali jika Anda memiliki firewall yang sangat pintar memblokir lalu lintas ping ICMP di suatu tempat), host tersebut tidak membalas.

— Roel Van de Paar
sumber
0

Linux menggunakan UDP bukan ICMP untuk traceroute, firewall tidak memblokir port UDP itu

— farshad khazaee
sumber
0

Anda dapat menginstal nmap (insecure.org) dan menggunakan nping dengan UDP atau TCP dan port apa saja. Berfungsi bagus pada jaringan dengan ping diblokir keluar.

Untuk melakukan ping ke server web dengan --tcp -p 80.443

Untuk melakukan ping ke server waktu dengan --udp -p 123

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

— Michael Hubbard
sumber
0

Jawaban singkat untuk pertanyaan Anda adalah bahwa pingutilitas bergantung pada protokol ICMP yang kadang-kadang diblokir di firewall jaringan atau firewall pada perangkat itu sendiri. Alasan paling umum mengapa admin jaringan memblokir ICMP adalah untuk mencegah "pemindaian" jaringan yang mereka anggap sebagai masalah keamanan. The tracerouteutilitas di Linux menggunakan UDP, protokol yang sama sekali berbeda, yang dalam hal ini di tidak terhalang oleh admin jaringan. UDP memiliki beragam kegunaan dan memblokir ini akan menyebabkan banyak hal tidak dapat digunakan pada jaringan. Jenis 'pesan kontrol' ICMP yang dibutuhkan oleh pingadalah bagian dari protokol yang berarti memblokir jenis paket ICMP yang menyebabkan lebih sedikit masalah pada jaringan dan karena itu lebih mungkin diblokir daripada UDP.

— Cybernaut
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.