Jika Anda pernah bekerja di ruang jaringan, atau mendukung hal itu, Anda mungkin memiliki cerita bagus tentang pemecahan masalah koneksi yang hilang. Tak pelak lagi, beberapa sistem baru diinstal dan dikonfigurasi, tetapi kami tidak dapat mengirimkan lalu lintas ke atau dari sistem.
Salah satu cerita yang saya ingat adalah seperti ini.
Kasus penggunaan
Saya sedang memecahkan masalah susunan penyimpanan back-end yang baru saja dipasang oleh perusahaan keuangan Amerika yang besar dan terkenal. Pelanggan mencoba mengonfigurasi replikasi data dari situs produksinya (PROD) di Houston ke situs pemulihan bencana (DR) di San Antonio. Sistem pemulihan bencana telah lama diterapkan dan memiliki reputasi sebagai konfigurasi yang dikenal baik.
Tempat produksi masih baru, dan tentu saja, penyebab semua masalah kami. Masalah sebenarnya adalah bahwa kami tidak dapat memindahkan lalu lintas di antara dua antarmuka replikasi yang telah kami konfigurasikan. Kami dapat menjangkau di luar gateway di situs DR, tetapi kami tidak dapat menjangkau di luar situs PROD. Lalu lintas mengenai perangkat gateway dan terputus.
Dalam setengah jam pemecahan masalah, saya bertanya kepada klien apakah mereka memiliki firewall di situs PROD yang dapat memblokir lalu lintas di port yang diperlukan. "Tentu saja tidak, tidak ada firewall di antara situs-situs ini." Tanggapan ini sangat mengejutkan mengingat ini adalah salah satu lembaga keuangan terbesar di seluruh negeri. Namun, karena semua posisi yang berhubungan dengan pelanggan berjalan, Anda harus bersikap hormat dan sopan.
Jadi, saya memeriksa setiap cek yang bisa saya pikirkan dari sisi saya. Firewall penyimpanan internal dinonaktifkan:centang. Port terbuka dari DR ke PROD:periksa. Port terbuka dari PROD ke DR? Tidak.
Ternyata, setelah empat jam pemecahan masalah dan konfigurasi ulang antarmuka, pelanggan berkata, "Biarkan saya memanggil petugas firewall kami."
Priamu yang mana?
Itu adalah posisi yang aneh untuk disewa mengingat Anda tidak memiliki firewall di antara situs-situs ini. Tapi itu tidak aneh, karena tentu saja, mereka memiliki firewall. Masalah terpecahkan. Sekarang setelah mimpi buruk itu berakhir, alat yang saya gunakan untuk mencari tahu di mana masalah terjadi adalah Telnet model lama yang bagus (yang dapat kita bahas di artikel selanjutnya) dan tentu saja, traceroute .
Perintah
Sekarang Anda dapat melihat kasus penggunaan yang jelas untuk traceroute , mari kita bicara tentang perintah itu sendiri, dan informasi apa yang bisa Anda dapatkan darinya. Bagaimanapun juga, tujuan artikel ini adalah agar Anda mendapatkan sedikit lebih banyak pengetahuan tentang utilitas yang traceroute penawaran.
Sintaksnya agak sederhana. Perintah traceroute <x> (x di sini menjadi IP atau nama host) adalah versi paling dasar dan akan mulai mengirim paket ke target yang ditentukan. Hasil ini akan memungkinkan Anda untuk melacak jalur paket yang dikirim dari mesin Anda ke setiap sistem antara Anda dan tujuan yang Anda inginkan.
Misalnya, jika saya ingin melacak jalur dari komputer saya ke google.com , saya akan memasukkan sesuatu seperti ini:
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 119.355 ms 119.315 ms 119.508 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 120.321 ms 119.836 ms 120.009 ms
5 66.sub-69-83-106.myvzw.com (69.83.106.66) 119.042 ms 119.489 ms 119.156 ms
6 2.sub-69-83-107.myvzw.com (69.83.107.2) 120.039 ms 125.954 ms 101.450 ms
7 112.sub-69-83-96.myvzw.com (69.83.96.112) 110.757 ms 108.485 ms 122.108 ms
8 112.sub-69-83-96.myvzw.com (69.83.96.112) 115.028 ms 121.073 ms 125.537 ms
9 116.sub-69-83-96.myvzw.com (69.83.96.116) 121.793 ms 124.769 ms 124.434 ms
10 Bundle-Ether10.GW6.DFW13.ALTER.NET (140.222.237.123) 128.082 ms 128.400 ms 126.509 ms
11 google-gw.customer.alter.net (204.148.43.118) 106.276 ms 107.885 ms 105.718 ms
12 108.170.252.129 (108.170.252.129) 99.725 ms 101.797 ms 108.170.252.161 (108.170.252.161) 101.671 ms
13 108.170.230.109 (108.170.230.109) 101.207 ms 100.515 ms 99.730 ms
14 dfw06s48-in-f100.1e100.net (216.58.194.100) 99.059 ms 94.502 ms 94.015 ms
[root@rhel8dev ~]# Kerusakan
Mari kita uraikan hasil ini menjadi gigitan yang lebih kecil. Perintah ini dapat menghasilkan banyak informasi, dan seperti kata pepatah, "Cara terbaik untuk memakan gajah adalah satu gigitan dalam satu waktu:"
[root@rhel8dev ~]# traceroute www.google.com
traceroute to www.google.com (216.58.194.100), 30 hops max, 60 byte packets
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms Kami hanya melihat hop pertama di sini. Namun, kita bisa menggunakan hop ini untuk membedah info yang ditampilkan. Pertama, kita melihat apa yang sebenarnya dikirim, dan ke mana:
traceroute to www.google.com(IP), 30 hops max, 60 byte packets
Dari keluaran ini, kami menyimpulkan bahwa kami mengirimkan lalu lintas ke target yang diinginkan (www.google.com ). Traceroute, secara default, mengukur 30 hop dari paket 60-byte.
Selanjutnya, kita melihat hop pertama terjadi. Di sini kita mencapai gerbang eksternal:
1 _gateway (192.168.2.1) 2.396 ms 2.726 ms 3.057 ms
Anda dapat mengetahui di sini di mana hop satu benar-benar mendarat, lalu ada tiga nilai numerik. Ini dikenal sebagai Round-Trip Time (RTT), yang mengacu pada jumlah waktu yang dibutuhkan paket tertentu untuk mencapai tujuannya dan merutekan kembali pesan ICMP ke sumbernya. Secara default, traceroute merutekan tiga paket data untuk menguji setiap hop. Anda dapat menemukan informasi lebih lanjut tentang proses ini secara online, namun kekurangannya adalah bahwa setiap paket merutekan pesan kesalahan ICMP kembali ke sumbernya ketika mencapai perangkat di jaringan. Tindakan ini memungkinkan traceroute untuk menentukan RTT paket itu dan tidak selalu menunjukkan kesalahan.
Sekarang, mari kita lihat hop 2 hingga 4:
2 145.sub-66-174-43.myvzw.com (66.174.43.145) 109.206 ms 109.400 ms 109.423 ms
3 * * *
4 10.209.189.140 (10.209.189.140) 124.793 ms 123.585 ms 124.585 ms Kita bisa melihat sesuatu yang baru di sini. Hop 2 terlihat normal:Perangkat dipukul dengan waktu RTT dalam rentang 100 milidetik. Kemudian, itu menjadi menarik. Kami hanya melihat bintang (*).
Apa arti dari bintang-bintang ini (tanda bintang)? Apakah paket-paket itu dijatuhkan? Apakah mereka kehabisan waktu?
Mari saya jelaskan. Ada dua kemungkinan dalam hal bintang-bintang ini. Pertama, ICMP/UDP mungkin tidak dikonfigurasi. Jika traceroute perintah selesai dengan sukses dan Anda melihat bintang-bintang ini, kemungkinan besar perangkat yang terkena tidak dikonfigurasi untuk membalas lalu lintas ICMP/UDP. Hasil ini tidak berarti bahwa lalu lintas tidak berlalu. Kemungkinan kedua adalah bahwa paket-paket tersebut dihapus karena ada masalah pada jaringan. Hasil ini biasanya berupa waktu tunggu paket, atau lalu lintas telah diblokir oleh firewall.
Seperti yang Anda lihat pada contoh di atas, bahkan setelah kita melihat bintang di hop 2, paket-paket terus berlanjut dan dirutekan kembali di hop 4. Perilaku ini menghasilkan traceroute yang berhasil seperti yang kita lihat bahwa Google telah dijangkau.
Bawa pulang
Traceroute dapat menjadi alat yang sangat berharga dalam hal pemecahan masalah jaringan. Ini sangat membantu untuk memvisualisasikan di mana masalah sebenarnya terjadi. Tentu saja, ada operasi lain yang terjadi di balik layar traceroute yang tidak tercakup di sini.
Saya sangat menyarankan jika Anda ingin melihat lebih jauh pada alat ini, Anda melakukan riset online. Ada banyak info tentang Time-to-Live (TTL) dan RTT yang, demi kepentingan waktu, tidak disertakan dalam artikel ini. Tujuan saya adalah Anda sekarang memiliki pemahaman yang lebih baik tentang kapan dan mengapa Anda harus menggunakan traceroute alat, dan bagaimana menafsirkan data yang ditawarkannya. Untuk informasi lebih lanjut tentang pemecahan masalah dan konsep jaringan, lihat artikel terkait kami di sini.