Keluhan “jaringan mati” adalah yang paling sering kita terima dan paling sering menyesatkan: bisa berarti kabel dicabut, DHCP gagal, gateway salah, DNS jatuh, atau aplikasi yang tidak jalan — sementara mesinnya sendiri sehat. Menebak-nebak perintah mengikuti firasat hanya membuang waktu. Chapter ini menyusun metode diagnosis berlapis yang bergerak dari kartu jaringan sampai pintu aplikasi, dengan satu pertanyaan pengantar di tiap lapisan: bagian ini sehat atau tidak?

Diagnosis dari Bawah ke Atas #

Setiap lapisan bergantung pada lapisan di bawahnya, sehingga pemeriksaan yang efisien berjalan dari bawah: tidak ada gunanya menguji DNS bila kartu jaringan tidak memiliki carrier. Lima lapisan kita, masing-masing dengan pertanyaan dan alatnya:

  1. Link — kartu jaringan menyala dan kabel tersambung? (ip link)
  2. Alamat IP — mesin punya alamat yang sah? (ip addr)
  3. Gateway — rute keluar jaringan setempat ada? (ip route)
  4. DNS — nama domain diterjemahkan menjadi alamat? (getent)
  5. Port dan layanan — program tujuan mendengarkan dan menjawab? (ss, curl)

Ketika satu lapisan gagal, berhenti di situ dan perbaiki dulu — masalah di atasnya biasanya sekadar akibat.

ip link menampilkan semua interface beserta status tautannya. Karena keluaran lengkapnya panjang, mode ringkas -br (brief) lebih ramah mata; kita periksa interface loopback lo yang pasti ada di semua mesin:

bash 
ip -br link show lo
ip -br addr show lo

Output yang Dihasilkan:

text 
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
lo               UNKNOWN        127.0.0.1/8 ::1/128

Baris pertama menjawab lapisan link: kolom UNKNOWN di situ adalah status khusus loopback — untuk kartu fisik, kolom ini menampilkan UP saat tautan baik, atau DOWN bila tidak. Baris kedua menjawab lapisan alamat: 127.0.0.1/8 adalah alamat IPv4 milik lo dan ::1/128 pasangan IPv6-nya. Pada kartu fisik seperti enp3s0, alamat yang tidak pernah muncul setelah boot adalah petunjuk kuat DHCP atau konfigurasi statis yang tidak jalan. Gejala link yang paling khas terlihat pada contoh tampilan berikut:

text 
enp3s0           DOWN           00:11:22:33:44:55 <NO-CARRIER,BROADCAST,MULTICAST,UP>

Bendera NO-CARRIER berarti kartu siap (UP) tetapi tidak mendeteksi sinyal di ujung kabel — ganti kabel, colok ulang, atau periksa port di switch. Ini kegagalan yang tidak akan pernah tertangani oleh perbaikan perangkat lunak.

Lapisan Gateway #

Setelah mesin punya alamat, pertanyaan berikutnya: bagaimana paket keluar dari jaringan setempat? Jawabannya dibaca dari routing table lewat ip route. Berikut contoh tampilan mesin yang sehat:

text 
default via 192.0.2.1 dev enp3s0
192.0.2.0/24 dev enp3s0 proto kernel scope link src 192.0.2.20

Baris default adalah pintu keluar ke semua jaringan di luar 192.0.2.0/24 — baris kedua. Tanpa baris default, paket menuju 8.8.8.8 maupun situs mana pun langsung dibuang di dalam mesin: alamat ada, tapi dunia luar tidak terjangkau. Ketiadaan default biasanya berarti DHCP tidak menyerahkan gateway atau konfigurasi statis lupa menulisnya.

Lapisan DNS #

Semua lapisan di bawah bisa sehat, namun curl tetap gagal bila nama tidak diterjemahkan. Kita memeriksa jalur resolver persis seperti yang ditempuh aplikasi — lewat getent, bukan dengan bertanya langsung ke server DNS:

bash 
getent ahosts localhost

Output yang Dihasilkan:

text 
::1             STREAM localhost
::1             DGRAM  
::1             RAW    
127.0.0.1       STREAM 
127.0.0.1       DGRAM  
127.0.0.1       RAW

Keluaran tersebut menegaskan resolver mengenal localhost di dua keluarga alamat sekaligus — ::1 dan 127.0.0.1 — beserta tiga jenis socket yang bisa dipakai masing-masing. Untuk pengujian dunia nyata, ganti localhost dengan nama yang biasa dipakai aplikasi yang sedang diperiksa. Kegagalan di sini sementara alamat IP langsung tetap bisa dihubungi adalah tanda khas masalah DNS, dan tempat berikutnya yang diperiksa adalah isi /etc/resolv.conf dari Chapter DNS .

Lapisan Port dan Layanan #

Lapisan terakhir bertanya: apakah program tujuan benar-benar mendengarkan? Alat ss -tln mendaftar semua socket TCP yang mendengarkan (-t), termasuk yang hanya di loopback (-l), dalam bentuk numerik (-n). Karena daftar socket asli mesin berbeda-beda, kita uji dengan server HTTP mini di port 8765 — file statis, loopback, lalu mati:

bash 
printf 'halo' > index.html
python3 -m http.server 8765 --bind 127.0.0.1 >/dev/null 2>&1 &
server=$!
for i in 1 2 3 4 5; do
  curl -s -o /dev/null 127.0.0.1:8765/ && break
  sleep 0.2
done
ss -tln | grep 8765
curl -s 127.0.0.1:8765/
printf '\n'
kill "$server"

Output yang Dihasilkan:

text 
LISTEN 0      5          127.0.0.1:8765       0.0.0.0:*   
halo

Mari kita bedah baris demi baris:

  1. Baris 1 (printf 'halo' > index.html): menyiapkan isi halaman yang pasti deterministik — teks halo — sehingga balasan server mudah dikenali.
  2. Baris 2-3: server HTTP Python dijalankan di background, dibatasi ke 127.0.0.1 dengan --bind, dan PID-nya disimpan agar bisa dimatikan bersih.
  3. Baris 4-7 (for i in ...): menunggu server siap — curl dicoba berulang sampai koneksi diterima, lalu break.
  4. Baris 8 (ss -tln | grep 8765): bukti lapisan port — satu baris LISTEN pada 127.0.0.1:8765, persis jawaban atas pertanyaan “ada yang mendengarkan di sini?”.
  5. Baris 9-10: sebagai client, curl mengambil isi halaman dan menampilkan halo; printf '\n' hanya merapikan baris baru karena file kita tidak berakhir dengan newline.
  6. Baris 11 (kill "$server"): server dimatikan — kebiasaan yang wajib agar proses tidak tertinggal di session.

Sebaliknya, mari lihat apa yang terjadi setelah server itu mati — koneksi ke port yang tidak ada didengarkan siapa pun:

bash 
curl -s --max-time 1 127.0.0.1:8765/
printf 'kode keluar curl: %d\n' "$?"

Output yang Dihasilkan:

text 
kode keluar curl: 7

curl tidak mencetak apa pun karena opsi -s meredam pesannya; yang bersuara adalah kode keluar 7, artinya connection refused — paket sampai ke mesin, tetapi tidak ada program yang mendengarkan di port itu. Kode-kode curl yang paling sering membantu: 7 ditolak atau port salah, 28 tenggat waktu habis (biasanya firewall yang diam-diam membuang paket), dan 6 nama tidak dapat diterjemahkan.

Tabel Gejala dan Penyebab #

Dengan lima lapisan di tangan, keluhan “jaringan mati” bisa dipetakan ke satu baris tabel:

Gejala yang terlihatPenyebab paling mungkinPemeriksaan
NO-CARRIER di ip -br linkkabel lepas, port switch matiganti kabel, cek LED
Tidak ada alamat pada kartuDHCP gagal atau konfigurasi salahip -br addr, log daemon
Ada alamat, tidak ada defaultgateway tidak diterimaip route
IP hidup, nama gagalDNS salah atau tidak terjangkaugetent hosts, /etc/resolv.conf
connection refused (kode 7)layanan tidak jalan, port salahss -tln
Timeout ke mesin jauhrouting atau firewall di luar mesinlanjut ping/traceroute

Statistik Kartu dan Log Driver #

Dua sumber bukti terakhir sering melengkapi gambar. Statistik ip -s link menampilkan penghitung per kartu — paket yang dikirim dan diterima beserta kolom errs, drop, dan carrier: angka error yang terus bertambah menunjuk pada kabel atau negosiasi link yang bermasalah, bukan perangkat lunak. Riwayat kernel sendiri dibaca lewat dmesg — pesan seperti kegagalan mengambil firmware kartu atau link yang naik-turun tercatat lengkap dengan waktunya, dan journalctl -u NetworkManager memberi sudut pandang yang sama dari sisi pengelola koneksi.

Kelima lapisan di atas membatasi diri pada satu mesin — server kita sendiri. Bila semua lapisan lokal sehat namun tujuan di ujung sana tetap tidak menjawab, pertanyaan bergeser ke jalur di antara kedua mesin. Momen itu adalah pekerjaan ping, traceroute, dan mtr, Chapter berikutnya.

Referensi lanjut: halaman manual ip(8) untuk semua subperintah ip, serta ss(8) untuk opsi pemeriksaan socket.