Network Connection Issues

Keluhan jaringan hampir selalu datang sebagai cerita, bukan pesan error: “wifi nyambung tapi tidak bisa browsing”, “ke kantor lancar, di rumah lambat”, “hanya aplikasi tim yang tidak mau nyambung”. Chapter ini membalik pola diagnosis dari Section Networking : kalau pola lima lapis berangkat dari bawah ke atas, kita di sini berangkat dari gejala yang dilaporkan lalu menurunkannya ke lapisan yang bersalah. Setiap kasus ditutup dengan perintah pembuktian — klaim “jaringannya yang rusak” tanpa angka hanya opini.

Tabel Triase: Dari Gejala ke Lapisan #

Dua baris pertama adalah wilayah Chapter Troubleshooting Network — kabel tanpa carrier dan DHCP yang tidak dijawab dibedah lengkap di sana. Empat gejala sisanya yang paling sering menyesatkan kita bahas satu per satu.

Kasus 1: Wifi Terhubung tapi Internet Mati #

Gejala klasik: ikon wifi penuh, tetapi browser berkata nama domain tidak ditemukan. Pemisah diagnosisnya paling murah adalah membandingkan dua pertanyaan — apakah alamat IP menjawab, dan apakah nama terjawab. Berikut contoh tampilan keduanya pada mesin yang bermasalah:

$ ping -c 2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=1.93 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=1.71 ms

$ getent hosts intranet.kantor.example.com
$ echo "exit: $?"
exit: 2

Alamat IP dijawab, nama domain tidak — link, alamat, dan gateway sehat, yang mati hanya penerjemahan nama. getent dipakai karena jalurnya persis seperti yang ditempuh aplikasi, bukan bertanya langsung ke server DNS. Lanjut diagnosisnya: isi /etc/resolv.conf menunjukkan resolver yang dituju — formatnya ada di resolv.conf(5) — dan pada sistem modern systemd-resolved sering jadi perantaranya; mekanisme lengkapnya dibedah di Chapter DNS .

Kasus 2: Hanya Situs Tertentu yang Gagal #

Gejala paling aneh di daftar: chat dan ping jalan, tetapi situs yang sama terasa cepat di koneksi lain selalu menggantung di rumah. Tersangkanya sering MTU (Maximum Transmission Unit) jalur — VPN atau PPPoE memotong kapasitas paket per jalur, sehingga paket kecil lolos sementara paket besar seperti handshake HTTPS dibuang diam-diam. Diagnosis resminya mengirim paket dengan ukuran menaik dan bendera do not fragment: ping -M do -s 1472 tujuan, lalu menurunkan ukuran sampai ditemukan payload terbesar yang lolos — pola yang bisa kita latih dengan simulator berikut:

cat > ping-sim.sh <<'AKHIR'
#!/bin/bash
# Simulasi: jalur ini menolak payload di atas 1450 byte.
if [ "$1" -le 1450 ]; then
  echo "ok $1"
else
  echo "gagal $1: message too long" >&2
  exit 1
fi
AKHIR
for ukuran in 1472 1452 1442; do
  if hasil=$(bash ping-sim.sh "$ukuran" 2>/dev/null); then
    break
  fi
  echo "payload $ukuran byte: ditolak jalur"
done
echo "payload pertama lolos: $hasil"
echo "MTU jalur = $ukuran + 28 byte header = $((ukuran + 28))"

Output yang Dihasilkan:

payload 1472 byte: ditolak jalur
payload 1452 byte: ditolak jalur
payload pertama lolos: ok 1442
MTU jalur = 1442 + 28 byte header = 1470

Payload 1442 byte lolos, jadi MTU jalur ini 1470 (payload plus 28 byte header). Bedah polanya:

1. ping-sim.sh: pengganti ping sungguhan yang di lingkungan latihan ini tidak punya izin raw socket — logikanya sama: payload di atas ambang gagal, di bawahnya lolos.
2. for ukuran in 1472 1452 1442: turun 10 byte setiap gagal; ping -M do aslinya mencari batas dengan cara serupa.
3. if hasil=$(...); then break: assignment di dalam kondisi if menangkap keluaran sekaligus menguji exit code-nya; break menghentikan pencarian di keberhasilan pertama.
4. Perbaikannya: turunkan MTU interface ke nilai temuan, misalnya sudo ip link set dev wlan0 mtu 1400, atau tetapkan permanen lewat konfigurasi NetworkManager.

Kasus 3: Hanya Port Tertentu yang Ditolak #

Bila keluhannya spesifik — “SSH jalan, aplikasi tim di port 8443 tidak” — pemeriksaan pertama tetap di sisi server: ss -tln memastikan ada yang mendengarkan di port itu. Bila port terbuka dan layanan hidup, giliran firewall yang diperiksa: sudo nft list ruleset menampilkan aturan nftables, dan sudo ufw status ringkasan versi Ubuntu. Perbedaan connection refused versus timeout — penolakan tegas versus kebisuan — sudah dibedah sebagai kasus penutup Chapter Troubleshooting Network ; menulis aturan firewallnya adalah bahasan Section Security .

Kasus 4: Wifi yang Sering Putus #

Putus-nyambung berkala biasanya bukan masalah lapisan protokol, melainkan radio: power saving yang mematikan radio terlalu agresif, driver yang belum stabil, atau dua access point yang berebut klient saat berkeliaran. Ketenangan datang dari log: journalctl -u NetworkManager -b memperlihatkan pola pemutusan lengkap dengan alasannya, journalctl -u iwd -b bila memakai iwd. Nonaktifkan sementara power saving dengan sudo iw dev wlan0 set power_save off untuk menguji dugaan pertama; pengelolaan wifi dibahas di Chapter Wifi Management , dan masalah driver perangkat di Chapter Hardware Compatibility .

Praktik: Diagnosis Berlapis pada Fixture #

Seluruh tabel di atas bisa dinyatakan sebagai pemeriksaan berurutan yang berhenti di lapisan pertama yang gagal. Kita latih dengan fixture yang merekam hasil pemeriksaannya:

cat > status-jaringan.txt <<'AKHIR'
carrier=ya
dhcp=ya
gateway=ya
dns=tidak
AKHIR
cat > diagnose.sh <<'AKHIR'
#!/bin/bash
# Diagnosis berlapis: berhenti di lapisan pertama yang gagal.
baca() { sed -n "s/^$1=//p" status-jaringan.txt; }
for lapisan in carrier dhcp gateway dns; do
  printf 'lapis %-8s: %s\n' "$lapisan" "$(baca "$lapisan")"
  if [ "$(baca "$lapisan")" != ya ]; then
    case "$lapisan" in
      carrier) saran="ip -br link: cek kabel, carrier, rfkill";;
      dhcp)    saran="ip -br addr: alamat 169.254 berarti DHCP tak dijawab";;
      gateway) saran="ip route: ping alamat gateway";;
      dns)     saran="resolv.conf dan getent hosts: periksa resolver";;
    esac
    echo "  -> BERHENTI DI SINI: $saran"
    exit 0
  fi
done
echo "semua lapisan bawah OK: kecurigaan berpindah ke aplikasi atau port tujuan"
AKHIR
bash diagnose.sh
sed -i 's/^dns=tidak/dns=ya/' status-jaringan.txt
bash diagnose.sh

Output yang Dihasilkan:

lapis carrier : ya
lapis dhcp    : ya
lapis gateway : ya
lapis dns     : tidak
  -> BERHENTI DI SINI: resolv.conf dan getent hosts: periksa resolver
lapis carrier : ya
lapis dhcp    : ya
lapis gateway : ya
lapis dns     : ya
semua lapisan bawah OK: kecurigaan berpindah ke aplikasi atau port tujuan

Eksekusi pertama berhenti di lapisan DNS — persis Kasus 1; setelah sed membetulkan satu baris fixture (di mesin nyata: membetulkan resolver), eksekusi kedua melewati semua lapisan dan membebaskan kita untuk mencurigai aplikasi. Bagian penting skripnya:

1. baca() { sed -n "s/^$1=//p" ... }: fungsi kunci-ke-nilai; sed mengupas prefiks kunci= dan flag p plus -n mencetak hanya baris yang cocok.
2. Urutan for: carrier, dhcp, gateway, dns — urutan lapisan dari bawah; lapisan atas diperiksa hanya setelah bawahnya sehat.
3. exit 0 setelah kegagalan: diagnosis berhenti di lapisan pertama yang gagal, karena perbaikan di atasnya percuma sebelum lapisan bawah dibereskan.
4. sed -i di antara dua eksekusi: memperlihatkan siklus perbaikan — ubah satu hal, jalankan ulang pemeriksaannya.

Referensi perintah lengkap: ip(8) untuk link, addr, dan route; resolv.conf(5) untuk resolver; dan Wi-Fi ArchWiki untuk ikhtisar power saving dan driver wireless.

Dari kabel sampai resolver, setiap keluhan jaringan kini punya jalur diagnosisnya sendiri. Ada satu kelas kegagalan yang belum tersentuh: aplikasi yang jalan di jaringan sehat lalu berhenti sendiri — layanan yang gagal start atau bergantung pada service lain yang lebih dulu tumbang. Itulah topik Chapter Service Failures .