Troubleshooting Jaringan Linux: ip, ss, dan dig Menemukan Masalah

“Situs tidak bisa dibuka” bukan diagnosis, hanya laporan. Masalahnya bisa ada di DNS, routing, MTU, atau socket, dan tiap lapis punya perintah berbeda. Artikel ini menelusurinya berurutan dengan ip, ss, dan dig, termasuk kasus nyata di mesin uji Ubuntu 26.04.1 LTS.

Ringkasan

• Diagnosis berurutan: antarmuka, rute, DNS, socket, lalu MTU, dari yang paling murah dicek.
• ip -br a menampilkan antarmuka; UP tanpa LOWER_UP menandakan belum ada carrier.
• ip route get <tujuan> menjawab kernel benar-benar akan mengirim paket ke mana.
• dig membedakan NXDOMAIN dari NOERROR tanpa jawaban, dua kegagalan yang berbeda artinya.
• ss tanpa -l menyembunyikan socket LISTEN; Recv-Q pada LISTEN selalu nol.
• Path MTU bisa lebih kecil dari MTU antarmuka; ping -M do menemukan batasnya.
• Kode keluar curl memisahkan DNS gagal, koneksi ditolak, dan timeout secara presisi.

Lima Lapis yang Harus Diperiksa Berurutan

Urutannya penting karena biaya pemeriksaan naik: memastikan nama host hampir selalu lebih murah daripada menggali paket. Artikel ini memverifikasi tiap langkah dengan output nyata dari mesin uji Ubuntu 26.04.1 LTS, kernel 7.0.0-31, iproute2 dari paket iproute2, systemd 259 dengan systemd-resolved aktif, glibc 2.43, dan curl 8.18.0. Semua perintah dijalankan tanpa hak root kecuali yang secara eksplisit butuh sudo.

Empat perintah ini cukup untuk memutuskan lapis mana yang perlu dijejak lebih dalam, dan biayanya hanya sepersekian detik.

ip -br a           # antarmuka dan alamat
ip route           # isi tabel rute
ss -s              # ringkasan jumlah socket
resolvectl status  # resolver dan DNS server yang aktif

Kalau ip route sudah menampilkan default via, lapis 1 dan 2 tidak perlu ditelusuri lagi. Kalau resolvectl status menunjukkan Current DNS Server, ada kandidat yang jelas untuk diuji di lapis DNS.

Lapis 1: Antarmuka dan Alamat

ip -br a menghasilkan satu baris per antarmuka dengan tiga kolom: nama, state, lalu alamat.

$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
wlo1             UP             192.168.1.9/24 fe80::5ba4:3bf0:dbd9:b9ae/64
br-478f569b5cf5  DOWN           172.20.0.1/16
docker0          DOWN           172.17.0.1/16

lo berstatus UNKNOWN bukan tanda rusak: loopback tidak punya carrier fisik, jadi kernel memang tidak pernah menaikkan flag LOWER_UP. Sebaliknya, br-478f569b5cf5 dan docker0 berstatus DOWN karena bridge Docker tidak punya kabel. Keduanya masih punya alamat, dan itulah jebakannya: ip -br a menampilkan antarmuka yang terlihat lengkap tetapi tidak bisa membawa trafik. Rute kernel menandai hal yang sama.

$ ip route
default via 192.168.1.1 dev wlo1 proto dhcp src 192.168.1.9 metric 600
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.9 metric 600

Flag linkdown pada rute bridge berarti kernel tahu perangkatnya tidak aktif. Urutan flag antarmuka dijelaskan di ip(8) dan ip-link(8): UP adalah permintaan administratif, sedangkan LOWER_UP baru naik ketika perangkat melaporkan carrier nyata.

Untuk memastikan lapisan fisik, ip -d link memperlihatkan MTU beserta batasannya.

$ ip -d link show wlo1 | head -1
2: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000

Kalau RX errors atau RX dropped pada ip -s link naik terus, masalahnya ada di driver, kabel, atau port pada switch, bukan di konfigurasi. Periksa juga lapisan ARP dengan ip neigh; status FAILED atau INCOMPLETE berarti kernel gagal menyelesaikan alamat MAC untuk IP gateway.

$ ip neigh
192.168.1.1 dev wlo1 lladdr f8:64:b8:c5:50:85 REACHABLE
fe80::1 dev wlo1 lladdr f8:64:b8:c5:50:85 router STALE

Lapis 2: Rute yang Benar-Benar Dipakai

ip route menampilkan isi tabel, tetapi tidak memberi tahu rute mana yang benar-benar dipilih kernel untuk satu tujuan. Untuk itu ada ip route get, dan bedanya terasa begitu ada beberapa jalur, VPN, atau policy routing.

$ ip route get 1.1.1.1
1.1.1.1 via 192.168.1.1 dev wlo1 src 192.168.1.9 uid 1000

Satu baris ini menjawab apa yang tidak bisa dijawab ip route: lewat gateway mana, dari alamat sumber mana, dan untuk UID berapa. Kalau hasilnya menunjuk antarmuka yang tidak seharusnya, periksa metric, yang mendefinisikan bahwa rute dengan nilai lebih rendah lebih diutamakan menurut ip-route(8).

Tiga kegagalan rute yang paling sering disalahartikan:

Perlu diingat bahwa perintah ip hanya mengubah kernel yang sedang berjalan. Semua perubahannya hilang setelah reboot karena tabel rute dibangun ulang dari konfigurasi.

Lapis 3: DNS dan Membaca Output dig

Output lengkap dig memuat lebih dari yang dibutuhkan untuk diagnosis. Bentuk pendek lebih praktis.

$ dig kal.my.id +noall +answer
kal.my.id.		300	IN	A	172.67.205.75
kal.my.id.		300	IN	A	104.21.37.72

Lima kolom itu adalah nama, TTL, kelas, tipe, dan nilai. TTL 300 berarti resolver boleh menyimpan jawaban lima menit, dan itu sebabnya resolver lokal sering melaporkan angka berbeda untuk nama yang sama.

Bagian HEADER dipakai saat diagnosis, bukan saat membaca jawaban biasa.

$ dig kal.my.id +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6290
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

status adalah bagian yang wajib dibaca lebih dulu, karena ia membedakan dua kegagalan yang sering tertukar:

Perbedaan NODATA dan NXDOMAIN terbukti langsung di mesin uji. Subdomain yang tidak ada pada zona yang di-proksi Cloudflare tetap dijawab NOERROR dengan ANSWER: 0, sedangkan nama di zona yang benar-benar tidak ada menghasilkan NXDOMAIN. Keduanya terlihat gagal bagi skrip yang hanya memeriksa “ada jawaban atau tidak”, padahal artinya berlawanan.

$ dig tidak-ada-zzz.kal.my.id +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37330
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig qzzx-no-such-host-9981.example +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41675
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Tiga perintah berikut menyelesaikan sebagian besar masalah DNS.

dig @1.1.1.1 contoh.id      # lewati resolver sistem, uji uplink langsung
dig @127.0.0.53 contoh.id   # bungkus stub systemd-resolved
dig +tcp contoh.id          # paksa TCP, dipakai saat jawaban UDP terpotong

Perbedaan ketiganya juga memisahkan kasus NOERROR dan timeout. Kalau @1.1.1.1 berhasil tetapi dig biasa gagal, masalahnya ada di resolver sistem atau stub-nya, bukan di uplink. resolv.conf(5) menjelaskan urutannya: paling banyak tiga nameserver, dicoba sesuai urutan yang ditulis.

Cache DNS dan Statistiknya

Resolver lokal tidak hanya meneruskan query, ia juga menyimpan jawaban sesuai TTL. systemd-resolved membukakan statistiknya sehingga cache bisa diamati langsung.

$ resolvectl statistics
Transactions
                       Current Transactions:   0
                         Total Transactions: 542
Cache
                         Current Cache Size:  22
                                 Cache Hits: 240
                               Cache Misses: 308
Failure Transactions
                             Total Timeouts:   3

Cache miss yang melampaui hit pada sesi pendek wajar terjadi di awal pemakaian, ketika cache masih kosong. Yang penting adalah perbandingan setelah sistem berjalan beberapa saat: hit yang terus naik menunjukkan resolver bekerja, sedangkan Total Timeouts yang bertambah di bagian Failure Transactions menunjukkan jalur ke resolver sedang bermasalah.

Bukti lain bahwa cache benar-benar bekerja: TTL untuk nama yang sama berbeda tergantung dari mana ditanyakan. Di sini dig ke stub 127.0.0.53 melaporkan TTL 128, sementara dig @1.1.1.1 melaporkan 300, karena angka pertama sudah dipotong oleh cache stub.

$ dig @127.0.0.53 kal.my.id +noall +answer
kal.my.id.		128	IN	A	104.21.37.72

resolvectl flush-caches menghapus seluruh cache DNS lokal. systemd-resolved(8) menyebut perintah ini setara dengan mengirim SIGUSR2 ke service. Gunanya untuk membedakan jawaban basi dari gangguan resolver yang sebenarnya.

Ketika /etc/resolv.conf Bukan Milik Anda

Pada sistem dengan systemd-resolved, /etc/resolv.conf dibuat otomatis dan header berkasnya sendiri memperingatkan agar tidak diedit.

$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
...
nameserver 127.0.0.53
options edns0 trust-ad
search .

Stub resolver mendengarkan di 127.0.0.53 dan 127.0.0.54 pada loopback, sesuai systemd-resolved(8). Mengedit berkas ini secara manual akan ditimpa saat jaringan berubah, karena isinya symlink ke berkas yang dibuat stub. Ubah lewat netplan atau NetworkManager, bukan lewat editor.

Bukti nyata bahwa options edns0 tidak selalu bisa dipakai ada di journal, dan cara membacanya sudah dibahas di artikel logging blog ini.

$ journalctl -u systemd-resolved -n 2 --no-pager
systemd-resolved[1059]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.1.1.

Ketika EDNS0 ditolak, resolver mundur ke UDP biasa dengan batas 512 byte. Itu sebabnya jawaban besar kadang perlu dig +tcp.

Untuk diagnosis yang lebih dalam, resolvectl status menunjukkan resolver mana yang dipakai per link, dan opsi resolver bisa diubah sementara sesuai resolv.conf(5). Salah satunya no-aaaa, yang mematikan query AAAA sementara; opsi ini tersedia sejak glibc 2.36, sedangkan mesin uji memakai glibc 2.43. resolv.conf(5) menyebutnya alat diagnosis sementara, dan perlu diingat bahwa opsi ini tidak cocok dengan EDNS0 maupun validasi DNSSEC.

Lapis 4: Socket dan Keadaan Koneksi

ss adalah pengganti netstat yang membaca data langsung dari kernel. Perilaku defaultnya sering mengejutkan: tanpa opsi apa pun, ss menampilkan socket yang tidak mendengarkan, sehingga socket LISTEN milik server lokal justru tidak terlihat.

$ ss -ltnp 'sport = :18080'
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      5          127.0.0.1:18080      0.0.0.0:*    users:(("python3",pid=10473,fd=3))

Angka Send-Q bernilai 5 pada socket LISTEN bukan data tertahan, melainkan panjang antrean backlog, yaitu batas koneksi yang belum diterima aplikasi. Kolom Recv-Q pada socket listening selalu 0 karena belum ada koneksi. Keduanya hanya berisi data setelah koneksi terbentuk.

Perhatikan juga alamat di socket itu: 127.0.0.1 membuat layanan hanya terjangkau dari mesin sendiri, sedangkan 0.0.0.0 atau * membuatnya terbuka untuk semua jaringan yang bisa menjangkau host. Server pengembangan lokal sebaiknya di-bind ke loopback, lalu diakses lewat SSH tunnel.

Opsi -p menampilkan proses pemilik socket, tetapi hanya untuk socket milik pengguna yang menjalankan perintah. Di mesin uji, socket milik user biasa terlihat, sedangkan socket milik service lain tampil kosong.

$ ss -tunpe state established | head -2
udp 0 0 192.168.1.9%wlo1:68  192.168.1.1:67  ino:24990 sk:6001 cgroup:/system.slice/NetworkManager.service
tcp 0 0 192.168.1.9:42860 172.65.90.23:443 users:(("opencode",pid=7530,fd=32)) uid:1000 ino:43535 sk:3001

Kolom tambahan dari -e berguna saat menelusuri kebocoran: uid pemilik socket, ino inode di VFS, sk cookie, dan cgroup yang menunjukkan unit atau sesi asal socket. Filter ekspresi membuat pencarian spesifik jadi ringkas; ss(8) mendokumentasikan operator and, or, not, serta predikat seperti dport, sport, dan dev.

ss -o state established '( dport = :443 )'   # koneksi HTTPS aktif beserta timer
ss -tan state time-wait | wc -l             # berapa koneksi yang menganggur
ss -a -A 'all,!tcp'                        # semua tabel socket selain TCP

Untuk gambaran jumlah socket, ss -s mencetak ringkasan tanpa mem-parsing /proc/net/tcp, dan ss(8) merekomendasikan cara ini ketika daftar socket sangat besar.

$ ss -s
TCP:   13 (estab 7, closed 0, orphaned 0, timewait 0)

Untuk koneksi yang benar-benar berjalan, ss -ti membuka statistik internal TCP. Contoh berikut diambil saat unduhan file besar sedang berjalan.

$ ss -tin state established '( dport = :443 )'
 cubic wscale:13,10 rto:218 rtt:17.389/4.205 ato:40 mss:1348 pmtu:1500 rcvmss:1348
 advmss:1448 cwnd:68 ssthresh:49 bytes_sent:5880433 bytes_acked:5880434
 segs_out:4979 segs_in:2617 send 42171028bps lastsnd:6013 lastrcv:1548

Lima field yang paling sering dipakai saat diagnosis:

Output ss -ti cukup panjang untuk pemeriksaan yang sedang tidak kritis, sehingga ss -s lebih hemat untuk pemantauan berkala.

Lapis 5: Path MTU yang Lebih Kecil dari Antarmuka

Kasus yang paling sering terlewat adalah MTU. Antarmuka bisa ber-MTU 1500, sementara jalur internet punya batas lebih kecil karena tunnel, VPN, atau enkapsulasi. Gejalanya khas: permintaan kecil berhasil, transfer besar menggantung atau gagal di tengah jalan.

Di mesin uji, antarmuka ber-MTU 1500, tetapi batas jalurnya 1400. Batas itu bisa dipastikan dengan ping yang menetapkan bit DF.

$ ping -c 1 -W 3 -M do -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
ping: sendmsg: Message too long

$ ping -c 2 -W 3 -M do -s 1372 1.1.1.1
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

$ ping -c 1 -W 3 -M do -s 1373 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1373(1401) bytes of data.
ping: sendmsg: Message too long

Angka -s adalah ukuran payload; header ICMP 8 byte dan header IP 20 byte menambah total 28 byte. Batas yang berhasil pada 1400 byte dan gagal pada 1401 byte berarti path MTU tepat 1400. Opsi -M do berarti do not fragment: kernel menolak mengirim alih-alih memecah paket, sehingga batas jalur terlihat jelas. Tanpa -M, kernel akan memecah sendiri dan gejalanya hilang.

$ ping -c 2 -W 3 -M want -s 1472 1.1.1.1
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

tracepath memberi tahu di hop mana batas itu turun, dan tidak butuh hak root.

$ tracepath -n 1.1.1.1
 1?: [LOCALHOST]                      pmtu 1500
 2:  192.168.1.1                      1.418ms pmtu 1400
     Too many hops: pmtu 1400

Nilainya sama untuk 1.1.1.1, 8.8.8.8, maupun 104.21.37.72, jadi penyebabnya bukan ISP tujuan, melainkan perangkat di dekat Anda, yaitu router 192.168.1.1. tracepath(8) menyebut keterbatasan yang relevan: banyak router IPv4 tidak mengirim informasi cukup dalam pesan ICMP error, sehingga Path MTU Discovery tidak selalu dapat diandalkan.

Perbaikan sementara bisa diberikan per rute. ip-route(8) membedakan mtu biasa dengan mtu lock, dan bedanya penting: dengan mtu biasa kernel masih dapat memperbarui nilai dari Path MTU Discovery, sedangkan mtu lock mematikan mekanisme tersebut.

sudo ip route change 1.1.1.1 mtu 1400        # sementara, hilang setelah reboot
sudo ip route change 1.1.1.1 mtu lock 1400    # nilai dipaksa, tanpa PMTU discovery

Perbaikan yang bertahan harus ditulis di konfigurasi jaringan, bukan hanya di kernel.

Kasus Nyata: IPv4 Normal, IPv6 Rusak

Kasus berikut terjadi di mesin uji dan cukup sering ditemui: DNS mengembalikan A dan AAAA dengan benar, IPv4 berjalan normal, tetapi IPv6 mati total. Penyebabnya ada di router, bukan di komputer.

Rute IPv6 terlihat lengkap, didapat dari router advertisement.

$ ip -6 route
fe80::/64 dev wlo1 proto kernel metric 1024 pref medium
default via fe80::1 dev wlo1 proto ra metric 600 pref medium

proto ra pada rute default berarti rute itu datang dari Router Advertisement, bukan dari konfigurasi manual. Router tersebut ternyata tidak benar-benar punya uplink IPv6.

$ ping -6 -c 1 -W 3 2606:4700:3037::6815:2548
From fe80::1%wlo1 icmp_seq=1 Destination unreachable: No route

Router menjawab “no route” atas paket yang sebelumnya ia advertise sendiri. Akibatnya, aplikasi yang mencoba AAAA lebih dulu gagal, sementara A tetap bekerja.

$ curl -6 -v https://kal.my.id/
*   Trying [2606:4700:3037::6815:2548]:443...
* Failed to connect to kal.my.id port 443 after 75 ms: Could not connect to server

$ curl -4 -o /dev/null -w 'ipv4 ttfb=%{time_starttransfer}s\n' https://kal.my.id/
ipv4 ttfb=0.187078s

Pasangan curl -4 dan curl -6 adalah tes paling hemat waktu untuk memisahkan masalah DNS dari masalah jalur per-protokol. Kalau keduanya gagal sementara dig sukses, jalur yang rusak bukan DNS.

Untuk sistem uji, options no-aaaa menjadi workaround sementara, karena resolv.conf(5) menyebutnya secara eksplisit sebagai alat diagnosis. Penyebab sebenarnya ada di konfigurasi uplink router, dan itu harus diperbaiki di sana.

Timeout atau Ditolak? Baca Kode Keluar curl

Satu rangkuman timing memisahkan waktu yang terpakai di tiap tahap, sehingga Anda tahu di mana letak masalahnya.

$ curl -sS -o /dev/null -w 'code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://kal.my.id/
code=200 dns=0.002524s connect=0.124240s tls=0.159633s ttfb=0.310872s total=0.313936s

time_namelookup 2,5 milidetik berarti DNS sehat, jadi lapis DNS bisa langsung disingkirkan. time_connect yang besar menandakan masalah jaringan, sedangkan time_appconnect yang melonjak berarti masalah TLS. Kode keluar pada curl(1) membuat diagnosis lebih tegas lagi, karena setiap kode menunjuk lapis yang berbeda.

Dua kode bisa dibedakan langsung. curl http://127.0.0.1:1/ memberi kode 7 seketika karena port ditutup, sedangkan curl --connect-timeout 3 http://10.255.255.1/ memberi kode 28 setelah tiga detik karena paket hilang tanpa balasan. Kode 7 berarti ada yang menjawab, yaitu menolak; kode 28 berarti tidak ada yang menjawab.

Perubahan Sementara atau Permanen

Semua perintah ip di artikel ini mengubah kernel yang sedang berjalan. Perubahan itu hilang saat reboot, karena tabel rute dan konfigurasi antarmuka dibangun ulang dari berkas konfigurasi. Yang bertahan adalah konfigurasi, bukan perintahnya.

Perbedaan distribusi yang perlu diperhatikan: Ubuntu dan Debian memakai netplan dengan berkas YAML di /etc/netplan, sedangkan Fedora dan RHEL memakai NetworkManager dengan nmcli. Keduanya menghasilkan tabel rute yang identik menurut ip-route(8), jadi yang perlu disesuaikan adalah cara menulis konfigurasinya.

Semua output di artikel ini berasal dari mesin uji tanpa hak root, kecuali contoh yang memakai sudo. Karena itu, ss -p sebagai user biasa hanya menampilkan socket milik user itu sendiri; untuk melihat seluruh socket jalankan dengan sudo. Itu limitasi alat, bukan tanda adanya masalah jaringan.