Topik ini membahas tiga alat standar untuk menguji konektivitas dari baris perintah, yaitu ping untuk mengukur jangkauan sebuah host, curl untuk menguji sebuah layanan HTTP, dan dig untuk menguji resolusi nama. Ketiganya bekerja pada lapisan yang berbeda sehingga menjawab pertanyaan yang berbeda pula, dan urutan pemakaiannya menentukan cepat atau lambatnya sebuah masalah jaringan terdiagnosis.
Mengukur jangkauan dengan ping#
Perintah ping mengirim pesan ICMP Echo Request ke sebuah host dan menunggu Echo Reply sebagai balasannya, sehingga jangkauan host serta waktu tempuh paket dapat diukur. Opsi -c 4 membatasi pengiriman pada empat paket agar perintah berhenti dengan sendirinya.
# tidak-dijalankan
# uji jangkauan sebuah host dengan empat paket ICMP echo
ping -c 4 127.0.0.1Blok di atas tidak dapat dieksekusi pada sandbox penulisan karena container tersebut tidak diberi kapabilitas CAP_NET_RAW, yaitu hak istimewa yang dibutuhkan untuk mengirim pesan ICMP mentah. Eksekusinya berhenti dengan pesan error ping: socket: Operation not permitted. Pada mesin Ubuntu atau mesin virtual biasa, perintah yang sama berjalan normal. Keluarannya berupa satu baris per balasan, yang berisi nomor urut dan waktu tempuh, kemudian ditutup dengan ringkasan berisi jumlah paket terkirim dan persentase paket yang hilang.
Perlu ditegaskan bahwa ping 127.0.0.1 hanya menguji tumpukan TCP/IP pada mesin itu sendiri dan tidak menyentuh jaringan luar sama sekali. Untuk menguji jangkauan host lain, alamat tujuannya diganti, misalnya ping -c 4 192.168.1.1. Ingat pula bahwa ping bekerja pada lapisan ICMP, sehingga host yang menjawab ping belum tentu menjalankan layanan web atau layanan lain yang dituju.
Menguji layanan HTTP dengan curl#
Perintah curl mengirim permintaan (request) HTTP dan menampilkan respons (response) yang diterima, sehingga pengujian sampai ke lapisan aplikasi. Opsi -I meminta hanya bagian header melalui metode HEAD, sedangkan opsi -s meniadakan indikator kemajuan yang tidak diperlukan pada skrip.
# minta hanya header respons dari layanan lokal pada port 81
curl -sI http://127.0.0.1:81 | head -n 3HTTP/1.1 200 OK
Content-Length: 4178
Content-Type: text/htmlContoh di atas menyasar layanan yang benar-benar berjalan pada sandbox penulisan, yaitu proxy Caddy pada port 81 loopback. Respons 200 OK berarti koneksi TCP ke 127.0.0.1:81 berhasil dibuat, permintaan HTTP diterima, dan layanan di belakang proxy memberikan jawaban lengkap. Kode status apa pun yang muncul tetap merupakan informasi tingkat aplikasi, termasuk kode error seperti 502 Bad Gateway apabila layanan tujuannya sedang tidak tersedia. Dalam pengujian konektivitas, respons apa pun sudah menjadi bukti bahwa jaringan dan layanannya hidup.
Kode status dapat diambil sendirian tanpa menyimpan badan respons dengan kombinasi -o /dev/null dan -w.
# ambil hanya kode status HTTP dari layanan yang sama
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:81200Format -w '%{http_code}\n' menyuruh curl mencetak kode status HTTP diikuti baris baru. Pola ini paling sering dipakai di dalam skrip karena keluarannya langsung dapat dibandingkan atau disimpan ke variabel. Pengujian yang sama dapat diarahkan ke luar untuk memastikan konektivitas keluar mesin juga sehat.
# uji konektivitas keluar menuju situs publik
curl -s -o /dev/null -w '%{http_code}\n' https://example.com200Keluaran 200 berarti permintaan HTTPS keluar berhasil melewati resolusi DNS, penerusan paket, sampai jabat tangan TLS. Apabila keluaran yang muncul justru 000, curl tidak berhasil menyelesaikan permintaan dan penyebabnya perlu dicari pada pesan error yang ditampilkannya.
Menguji resolusi nama dengan dig#
Perintah dig mengirim kueri DNS langsung ke server nama yang tercantum pada konfigurasi resolver, sehingga jawabannya murni berasal dari DNS dan tidak dipengaruhi mekanisme lain. Opsi +short memadatkan keluaran menjadi alamat jawabannya saja.
# minta alamat IP untuk nama localhost langsung dari server DNS
dig +short localhost127.0.0.1Tanpa +short, dig mencetak bagian HEADER, QUESTION SECTION, ANSWER SECTION, beserta statistik waktu kueri yang berguna saat menganalisis perilaku server DNS. Yang penting diingat, dig berbicara langsung dengan server DNS dan tidak membaca berkas /etc/hosts, sehingga jawabannya bisa berbeda dari jawaban yang diterima aplikasi biasa. Server tujuan juga dapat ditunjuk secara eksplisit dengan tanda @, misalnya dig @1.1.1.1 +short example.com untuk menanyakan langsung ke resolver publik tertentu. Dengan cara ini, server mana pun dapat dibandingkan tanpa mengubah konfigurasi sistem. Perbedaan sumber jawaban tersebut mendasari perbedaan kegunaan dig dan getent yang dijelaskan pada topik resolusi DNS.
Urutan diagnosis yang efektif#
Ketiga alat bekerja pada lapisan yang berbeda, sehingga urutan pemanggilannya mempersempit letak masalah dengan cepat. Urutan yang lazim dipakai bergerak dari nama, ke jangkauan, lalu ke layanan:
- Uji nama dengan
dig +short nama-domain. Apabila tidak menghasilkan alamat, masalahnya pada resolusi DNS dan dua langkah berikutnya belum perlu dikerjakan. - Uji jangkauan dengan
ping -c 4 alamat-ip. Apabila tidak ada balasan, masalahnya pada rute atau jaringan di antara kedua mesin, bukan pada layanan. - Uji layanan dengan
curl -sI http://alamat-ip:port. Apabila munculConnection refused, mesin tujuan hidup tetapi tidak ada layanan yang mendengarkan di port itu. Apabila munculConnection timed out, paket terbuang di tengah jalan, yang sering disebabkan firewall.
Pada langkah ketiga, perbedaan refused dan timed out adalah petunjuk penting. Pesan Connection refused berarti paket sampai ke tujuan dan ditolak secara eksplisit karena portnya tertutup, sedangkan Connection timed out berarti tidak ada jawaban sama sekali. Membedakan keduanya menghemat waktu pencarian penyebab.
Kesalahan umum#
- Menggunakan ping untuk menguji sebuah layanan web. Host dapat menjawab ping sementara layanannya mati, atau sebaliknya menolak ICMP sementara layanannya sehat. Uji layanan langsung dengan
curlke port layanannya. - Membaca respons 502 sebagai kegagalan jaringan. Status 502 adalah jawaban dari proxy atau aplikasi, yang justru membuktikan jaringan bekerja. Cari penyebabnya pada layanan yang berada di belakang proxy tersebut.
- Mencetak seluruh halaman hanya untuk melihat kode status. Tanpa
-o /dev/null, badan respons ikut tercetak dan memenuhi terminal. Gunakan-w '%{http_code}'agar keluarannya ringkas dan mudah diuji di skrip. - Menganggap keluaran dig sebagai jawaban yang diterima aplikasi. Aplikasi mengikuti urutan sumber jawaban sistem, sedangkan dig hanya menanyakan DNS. Gunakan
getentbila ingin meniru perilaku aplikasi.
Ringkasan#
pingmenguji jangkauan host melalui ICMP dan tidak menyentuh layanan mana pun, sehingga hasilnya tidak mewakili kesehatan layanan.curl -sImenguji layanan HTTP sampai lapisan aplikasi, dan-o /dev/null -w '%{http_code}'merampingkan keluarannya untuk skrip.dig +shortmenguji server DNS secara langsung tanpa membaca/etc/hosts.- Diagnosis yang efisien bergerak dari resolusi nama, ke jangkauan host, lalu ke layanan, dengan membedakan
refuseddantimed out.
Referensi#
- ping(8) — Linux man-pages project — Mekanisme ICMP echo serta opsi-opsi perintah ping.
- curl man page — curl.se
— Opsi
-s,-I,-o, dan-wbeserta arti kode keluar curl. - dig(1) — Ubuntu Manpages
— Opsi kueri DNS pada dig, termasuk
+short.