Belajar Linux - Networking Fundamentals & Diagnostic Tools

#Pendahuluan

Setelah di episode 16 sebelumnya kita membahas Boot Process, Kernel, dan Kernel Modules — memahami bagaimana mesin menyala, kernel dimuat, dan modul-modul dikelola — kalian sekarang tahu apa yang terjadi di dalam mesin. Namun sebuah server di dunia nyata tidak pernah hidup menyendiri: ia harus berbicara dengan database, menerima traffic dari internet, dan menjawab permintaan DNS. Tanpa jaringan, semua layanan itu hanya kode yang terisolasi.

Jaringan sering terasa seperti ilmu sihir sampai kalian punya kosakata dan alat yang tepat. Ketika pelanggan mengeluh "website-nya lambat", "koneksinya putus-putus", atau "saya tidak bisa connect ke database", kalian tidak punya GUI untuk mengecek — yang kalian punya hanyalah terminal dan sekumpulan perintah. Kemampuan membaca output perintah-perintah itu secara cepat dan tepat adalah pembeda antara admin yang panik dan admin yang tenang menelusuri masalah selangkah demi selangkah.

Di episode 17 ini, kita akan membangun fondasi networking Linux: memahami antarmuka jaringan dan alamat IP dengan paket modern iproute2, memeriksa konektivitas dengan ping dan traceroute, menyelidiki resolusi nama dengan dig, serta memastikan layanan benar-benar mendengarkan dengan ss. Di akhir episode, kalian akan punya prosedur diagnostik yang bisa diterapkan langsung di server mana pun.

#Pembahasan Utama

#Antarmuka Jaringan & Alamat IP dengan iproute2

Perintah legendaris ifconfig sudah usang dan tidak lagi diinstal secara default di distro modern. Penggantinya adalah iproute2 — kumpulan alat yang lebih konsisten dan lebih informatif. Biasakan memakai ip sejak sekarang.

ip addr

Output-nya akan menunjukkan setiap antarmuka — misalnya lo (loopback), eth0 (ethernet), atau ens3/enp0s3 (nama predictabel ala systemd). Untuk ringkasan singkat, gunakan ip -brief addr:

ip -brief addr

lo               UNKNOWN 127.0.0.1/8 ::1/128
eth0             UP      192.168.1.10/24

Bacaan eth0 UP 192.168.1.10/24 berarti antarmuka aktif, beralamat IPv4 192.168.1.10 dengan prefix /24 (netmask 255.255.255.0). Format CIDR (/24) adalah cara modern menulis netmask — 32 bit alamat, 24 bit di antaranya adalah network portion.

#Routing: Peta Jalan ke Luar Mesin

Antarmuka memberi tahu mesin di mana ia berada; tabel routing memberi tahu mesin ke mana mengirim paket. Analogikan seperti peta perjalanan: jika tujuan ada di kota yang sama, kirim langsung; jika di luar kota, kirim lewat jalan tol yang menuju gerbang luar (gateway).

ip route

default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10

• Baris default adalah gateway default — rute terakhir yang dipakai ketika tidak ada rute spesifik yang cocok. Biasanya IP router/modem kalian.
• Baris 192.168.1.0/24 adalah rute connected — jaringan lokal yang bisa dijangkau langsung tanpa gateway.

Perintah yang paling sering kalian pakai untuk menambah rute statis:

sudo ip route add 10.0.0.0/8 via 192.168.1.1 dev eth0

sudo ip route del 10.0.0.0/8

#ping: Apakah Mesin Itu Hidup dan Dapat Dijangkau?

ping adalah tes paling dasar: mengirim paket ICMP echo request dan menunggu echo reply. Ini bukan sekadar "tes hidup", tapi juga tes latensi dan packet loss.

ping -c 4 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=3.42 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=3.44 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=3.48 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=3.41 ms
 
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 3.412/3.438/3.480/0.028 ms

Perhatikan kolom ttl dan time — keduanya adalah sinyal diagnostik yang kuat. ttl=117 berarti paket melewati sekitar 7 router (TTL awal 128 untuk Windows/BSD, 64 untuk Linux — 128 − 117 = 11 hop, 64 − 117 = minus, berarti sumbernya bukan Linux). Ini cara cepat menebak sistem operasi host tujuan.

#traceroute dan mtr: Menelusuri Jalur Paket

Ketika ping gagal atau lambat, kalian perlu tahu di titik mana paket berhenti. traceroute mengirim paket dengan TTL bertahap (1, 2, 3, ...) — setiap router yang dilalui akan "mengembalikan" pesan TTL expired, sehingga kalian melihat daftar hop:

traceroute -n 8.8.8.8

 1  192.168.1.1     1.234 ms  1.198 ms  1.156 ms
 2  10.0.0.1        4.001 ms  4.114 ms  3.987 ms
 3  * * *           (timeout — router ini menutup ICMP)
 4  72.14.215.85   21.233 ms 20.988 ms 21.001 ms

Asterisk (*) pada sebuah hop bukan berarti jaringan putus — banyak router memblokir ICMP. Selama hop berikutnya merespons, paket tetap berjalan.

mtr adalah kombinasi ping + traceroute yang terus memperbarui statistik secara real-time. Ini alat favorit admin untuk debugging latensi:

mtr -n -c 20 8.8.8.8

Kolom Loss% dan Avg pada baris yang sama akan langsung menunjukkan hop yang paling bermasalah. Jika loss hanya muncul pada hop tertentu, biasanya itu router transit yang tidak merespons ICMP, bukan jalur yang mati.

#Resolusi Nama: dig, nslookup, dan host

Manusia tidak nyaman menghafal 142.250.4.100; kita menghafal google.com. Penerjemah antara nama dan IP disebut DNS resolver. Tiga alat yang sama-sama berguna untuk memeriksanya:

dig example.com

;; ANSWER SECTION:
example.com.    1865    IN    A    93.184.216.34

Kolom 1865 adalah TTL dalam detik — berapa lama hasil ini boleh di-cache oleh resolver. Bagian paling berguna dari output dig sering kali bukan jawabannya, tapi di mana ia menjawab: SERVER: 127.0.0.53 berarti kalian memakai systemd-resolved lokal, sementara SERVER: 8.8.8.8 berarti resolver langsung ke DNS publik.

nslookup example.com

host example.com

Contoh query record lain dengan dig:

dig example.com MX +short

dig example.com NS +short

#curl dan wget: Berbicara dengan Layanan HTTP

Ini bukan sekadar "alat download". curl adalah senjata serbaguna untuk menguji API, memeriksa header respons, dan mensimulasikan permintaan browser. Ini bekal wajib sebelum kalian debugging API di episode-episode DevOps berikutnya.

curl -I https://example.com

HTTP/2 200
server: nginx
content-type: text/html; charset=UTF-8
content-length: 1256

curl -v https://example.com

curl -O https://example.com/file.tar.gz

wget https://example.com/file.tar.gz

#ss: Memeriksa Port yang Mendengarkan

Setelah layanan berjalan, pertanyaan terpenting adalah: apakah ia benar-benar mendengarkan di port yang diharapkan, dan di interface mana? Jawabannya ada di ss (socket statistics) — pengganti modern netstat.

sudo ss -tulpn

Contoh output:

Netid  State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
tcp    LISTEN  0       128     0.0.0.0:22          0.0.0.0:*           sshd
tcp    LISTEN  0       511     127.0.0.1:5432      0.0.0.0:*           postgres

Bacaan penting di atas: sshd mendengarkan di 0.0.0.0:22 (semua interface — rentan jika firewall terbuka), sedangkan postgres hanya di 127.0.0.1:5432 (hanya localhost — aman dan sudah benar). Pola inilah yang kalian cari saat mengaudit keamanan: layanan database/administratif seharusnya terikat ke localhost, bukan ke semua interface.

sudo ss -tulpn | grep -E ":(22|80|443)\b"

#Prosedur Diagnostik: Urutan Langkah yang Disiplin

Ketika jaringan bermasalah, jangan panik dan jangan asal ganti konfigurasi. Ikuti alur berurutan ini — ini yang dipakai admin senior di lapangan:

1. Apakah antarmuka hidup? — ip -brief addr (status UP, IP ada).
2. Apakah rute benar? — ip route (ada default via ...).
3. Bisa ping gateway? — ping -c 3 192.168.1.1 (masalah di jaringan lokal).
4. Bisa ping internet? — ping -c 3 8.8.8.8 (masalah di DNS atau WAN).
5. DNS bekerja? — dig example.com (jika ping IP sukses tapi nama gagal, masalah ada di DNS).
6. Layanan merespons? — curl -v https://example.com (masalah di aplikasi/firewall).
7. Port terbuka? — ss -tulpn | grep :443 (memeriksa sisi server).

Urutan ini mempersempit masalah layer demi layer — dari physical, network, transport, hingga aplikasi — sehingga kalian tidak membuang waktu mengganti setting yang tidak relevan.

#Kesalahan Umum (Common Pitfalls)

1. Ping ke nama host vs alamat IP. ping google.com menguji tiga hal sekaligus (DNS + routing + konektivitas). Jika gagal, kalian tidak tahu yang mana yang rusak. Selalu pecah: ping IP dulu, lalu ping nama. Ini menentukan apakah masalah di resolusi atau di jalur.

2. Mengandalkan ifconfig/netstat yang tidak terinstal. Distro modern tidak menyertakannya. ip dan ss adalah standar sekarang — pelajari kedua ini dan tinggalkan yang lama.

3. Mengabaikan flag -4/-6. Jaringan IPv6 yang misconfigured sering membuat ping hostname gagal "aneh" padahal IPv4 sehat. Sadari bahwa resolusi bisa mengembalikan AAAA (IPv6) lebih dulu.

4. Membaca * pada traceroute sebagai kerusakan. Hop yang timeout bukan bukti jaringan mati. Lanjutkan membaca sampai hop terakhir sebelum menyimpulkan.

5. curl -I vs permintaan nyata. HEAD tidak selalu mewakili GET. Jika mencurigai masalah aplikasi, gunakan curl -v dengan metode yang sama seperti klien asli.

6. Lupa sudo untuk ss -p. Tanpa sudo, kolom Process kosong sehingga kalian tidak tahu layanan mana yang membuka port. Jalankan dengan sudo saat debugging port.

#Penutup

Pada episode 17 ini, kalian telah membangun fondasi networking Linux yang sesungguhnya: mengenal antarmuka dan alamat IP dengan ip addr serta routing dengan ip route (iproute2), menguji konektivitas dengan ping dan traceroute/mtr, membongkar DNS dengan dig/nslookup/host, berkomunikasi dengan layanan HTTP via curl dan wget, serta memeriksa port yang mendengarkan dengan ss. Lebih penting lagi, kalian punya prosedur diagnostik berurutan yang mempersempit masalah layer demi layer.

Poin kunci yang perlu kalian bawa pulang:

• ip dan ss adalah standar modern; ifconfig dan netstat sudah legacy.
• Format CIDR (/24) adalah bahasa alamat modern — pahami sebelum menyentuh konfigurasi.
• ping menguji banyak hal sekaligus — pisahkan tes IP dan tes nama untuk isolasi masalah.
• dig memberi informasi paling lengkap; TTL dan SERVER: adalah kunci membacanya.
• ss -tulpn menunjukkan port listening beserta proses dan interface — audit keamanan pertama sebelum menyentuh firewall.
• Debugging mengikuti urutan: interface → route → gateway → internet → DNS → aplikasi.

Di episode 18 selanjutnya kita akan mengamankan akses ke server dari jarak jauh lewat topik Remote Access Menggunakan SSH & Secure File Transfer. Kalian akan belajar mengamankan sshd_config, bertukar kunci dengan ssh-keygen dan ssh-copy-id, mentransfer file dengan scp dan rsync, serta membuat tunnel SSH — keterampilan yang menjadi tulang punggung administrasi server jarak jauh. Sampai jumpa!