Belajar UFW - Troubleshooting Koneksi & Rules

#Pendahuluan

Semua admin pasti mengalaminya: port tidak kebuka, koneksi macet, atau — yang paling menakutkan — server tiba-tiba tidak bisa diakses. Episode 18 melatih kalian berpikir seperti dokter: diagnosis sistematis, bukan tebak-tebakan.

Mengapa episode ini penting? Karena troubleshooting yang panik menghasilkan perubahan acak yang memperparah masalah. Dengan metodologi — memeriksa layer demi layer dari aplikasi sampai ke kernel — kalian bisa menemukan akar masalah dalam hitungan menit, bukan jam.

#Kotak Alat Diagnosis

Empat perintah yang menjadi tulang punggung diagnosis:

#Langkah Diagnosis: Dari Atas ke Bawah

Pendekatan sistematis — mulai dari yang paling dekat dengan aplikasi, turun ke jaringan:

#Langkah 1: Apakah Layanan Mendengarkan?

sudo ss -tlnp

State  Local Address:Port   Process
LISTEN 0.0.0.0:80           nginx
LISTEN 127.0.0.1:8080       node

Perhatikan perbedaannya: 0.0.0.0:80 mendengarkan di semua interface (bisa diakses publik), sedangkan 127.0.0.1:8080 hanya di loopback (tidak bisa diakses dari luar — itu benar untuk aplikasi belakang proxy, episode 15). Jika layanan yang kalian harapkan tidak ada di sini, masalahnya di aplikasi, bukan firewall.

#Langkah 2: Apa Kata UFW?

sudo ufw status verbose

Periksa tiga hal: port tujuan ada action ALLOW? Default policy tidak menolak secara tak terduga? Logging aktif untuk observasi?

#Langkah 3: Apa Kata Backend?

Kadang frontend UFW dan backend iptables tidak sinkron — misalnya setelah manipulasi manual atau restart layanan yang menulis aturan sendiri (Docker, episode 14):

sudo iptables -L INPUT -n -v --line-numbers
sudo iptables -L ufw-user-input -n -v --line-numbers

#Langkah 4: Apakah Paket Sampai?

Jika UFW mengizinkan dan layanan listening, tapi koneksi tetap gagal — paket mungkin tidak sampai. Tangkap dengan tcpdump:

sudo tcpdump -i eth0 -nn port 443

• Ada paket SYN masuk → masalah di dalam OS (kemungkinan UFW/backend).
• Tidak ada paket sama sekali → masalah di luar OS: firewall provider, routing, atau network.

#Kasus Klasik 1: Terkunci SSH

Ini keadaan darurat paling umum. Gejala: koneksi SSH tidak bisa dibangun.

Kemungkinan penyebab & solusi:

1. Enable tanpa izinkan SSH — UFW menyala, port 22 ditolak default policy.

   • Solusi: console VPS provider → sudo ufw allow 22/tcp atau sudo ufw disable.

2. Deny/limit yang salah arah — aturan deny lebih awal dari allow (episode 17).

   • Solusi: ufw status numbered, perbaiki urutan, atau hapus deny yang salah.

3. Port SSH diubah — server pindah ke 2222 tapi firewall hanya izinkan 22.

   • Solusi: ufw allow 2222/tcp.

4. Subnet sumber salah — allow from 192.168.1.0/24 padahal kalian konek dari 10.0.0.5.

   • Solusi: cek IP asal koneksi kalian (ip addr di mesin lokal), perbaiki subnet.

#Kasus Klasik 2: Port Tidak Kebuka

Web server jalan (ss -tlnp menampilkan 443), tapi curl dari luar gagal.

Alur pemecahan:

sudo ufw status | grep 443
sudo ufw status numbered
sudo iptables -L ufw-user-input -n -v | grep -A1 443
curl -vk https://203.0.113.5 2>&1 | head -20

Skenario yang sering ditemukan:

• Aturan ada di IPv4 tapi client IPv6 → cek apakah (v6) ada; periksa konflik IPv6 (kasus 3).
• Firewall provider memblokir → cek panel VPS; tambahkan port di cloud firewall.
• Aturan ditimpa layanan (Docker) → chain DOCKER-USER (episode 14).
• Routing/asymmetric → balasan tidak kembali; tcpdump di dua arah.

#Kasus Klasik 3: Konflik IPv6

Gejala: ufw status menampilkan aturan IPv6, tapi akses IPv6 gagal atau — sebaliknya — aturan IPv6 tidak ada padahal IPV6=yes.

Pemeriksaan:

cat /etc/default/ufw | grep IPV6
ip -6 addr show eth0
ip -6 route show

Skenario umum:

• IPV6=no → tidak ada aturan IPv6; traffic IPv6 jatuh ke policy default sistem. Ubah ke yes lalu reload.
• Mesin tidak punya alamat IPv6 → tidak masalah, aturan IPv6 hanya "menganggur"; fokus ke IPv4.
• Prefix IPv6 salah → allow from fd00::1/64 padahal alamat mesin di prefix lain. Sesuaikan.

#UFW Show Raw: Jendela ke Ruleset Penuh

Untuk diagnosis backend yang lengkap:

sudo ufw show raw

Outputnya menampilkan aturan sebelum/user/after sekaligus dalam format backend — sumber kebenaran yang dijalankan kernel. Bandingkan dengan ufw status untuk menemukan ketidakcocokan frontend/backend.

#Common Pitfalls

1. Mendiagnosis tanpa urutan: mulai dari aplikasi (ss), lalu firewall (ufw), baru jaringan (tcpdump). Menebak di tengah hanya membuang waktu.
2. Fokus pada satu lapis saja: port tidak kebuka bisa karena layanan mati, UFW deny, firewall provider, atau routing. Periksa semua lapis.
3. Lupa konflik IPv6: aturan IPv4 benar, tapi client memakai IPv6. Selalu cek dua stack.
4. Panik mengubah ruleset: ubah satu hal, verifikasi, lalu lanjut — bukan mengubah lima hal sekaligus.

#Penutup

Pada episode 18 ini, kalian telah berlatih diagnosis sistematis.

Inti yang harus dibawa pulang:

• Diagnosis dari atas ke bawah: ss -tlnp (layanan) → ufw status (firewall) → iptables -L (backend) → tcpdump (paket).
• Lockout SSH: selalu siapkan console provider; periksa allow, deny, port, subnet.
• Port tidak kebuka: cek aturan IPv4 dan IPv6, firewall provider, dan layanan.
• Konflik IPv6: pastikan IPV6=yes, alamat IPv6 ada, dan prefix benar.
• ufw show raw menampilkan ruleset yang benar-benar dieksekusi kernel.

Di episode 19 selanjutnya, kita zoom out membandingkan senjata: UFW vs iptables vs nftables vs firewalld — kelebihan, kekurangan, dan kapan masing-masing dipilih, dari single-host Linux hingga enterprise multi-zone. Sampai jumpa di episode 19!