Part 009 — Networking CLI for Backend Debugging

Fokus part ini: membangun mental model dan workflow debugging jaringan menggunakan CLI untuk backend Java/JAX-RS, microservices, PostgreSQL, Kafka, RabbitMQ, Redis, Docker, Kubernetes, AWS/Azure, dan production operations.

Networking debugging bukan tentang menghafal curl, ping, atau telnet. Untuk senior backend engineer, networking CLI adalah alat untuk menjawab pertanyaan operasional:

• Apakah service bisa di-resolve oleh DNS?
• Apakah port terbuka?
• Apakah koneksi TCP bisa terbentuk?
• Apakah TLS handshake berhasil?
• Apakah HTTP request benar-benar sampai ke service yang dimaksud?
• Apakah masalah berasal dari aplikasi, DNS, TLS, routing, proxy, firewall, service mesh, Kubernetes service, ingress, network policy, atau credential?
• Apakah evidence cukup untuk eskalasi ke platform/SRE/network/security team?

Di sistem enterprise, error seperti Connection refused, Connection timed out, UnknownHostException, SSLHandshakeException, 503 Service Unavailable, atau No route to host tidak boleh langsung diasumsikan sebagai bug aplikasi. Banyak error runtime Java sebenarnya adalah gejala dari lapisan networking.

1. Networking Mental Model untuk Backend Engineer

Sebelum menjalankan command, pecah masalah konektivitas menjadi beberapa layer:

Dalam praktik debugging, pertanyaan yang benar adalah:

1. Apakah hostname benar?
2. Apakah hostname resolve ke IP yang benar?
3. Apakah IP dapat dijangkau dari lokasi client?
4. Apakah port listening?
5. Apakah firewall/security group/network policy mengizinkan koneksi?
6. Apakah TLS certificate valid untuk hostname tersebut?
7. Apakah protocol yang digunakan benar?
8. Apakah application endpoint menerima request?
9. Apakah failure terjadi sebelum atau sesudah request masuk aplikasi?

Urutan ini penting karena mempercepat isolasi masalah. Jangan debug JSON payload kalau TCP handshake saja belum berhasil.

2. Kategori Failure Networking yang Sering Muncul

Mental model penting: error message adalah clue, bukan kesimpulan final.

3. Read-Only First Principle

Untuk production debugging, mulai dari command yang tidak mengubah state:

# Aman: observasi DNS
host api.internal.example

# Aman: observasi TCP port
nc -vz api.internal.example 443

# Aman: observasi TLS handshake
openssl s_client -connect api.internal.example:443 -servername api.internal.example </dev/null

# Relatif aman: HTTP GET health/readiness endpoint
curl -v --connect-timeout 5 --max-time 10 https://api.internal.example/health

Hindari langsung menjalankan command yang:

• mengirim request mutating seperti POST, PUT, PATCH, DELETE;
• memakai credential production tanpa redaction;
• melakukan load test spontan;
• membuka port-forward ke resource sensitif tanpa approval;
• melakukan packet capture panjang yang bisa menangkap data sensitif;
• mengubah DNS, firewall, Kubernetes service, ingress, atau secret.

4. ping: Reachability Dasar, Tapi Jangan Overtrust

ping menggunakan ICMP. Banyak environment enterprise menonaktifkan ICMP, jadi ping gagal tidak selalu berarti service tidak reachable.

ping -c 4 api.internal.example

Gunakan ping untuk:

• indikasi kasar network reachability;
• melihat latency ICMP;
• mendeteksi packet loss sederhana.

Jangan gunakan ping sebagai bukti final bahwa HTTP/TCP service mati. Port 443 bisa terbuka walaupun ICMP diblokir.

Failure mode

ping: cannot resolve api.internal.example: Unknown host

Kemungkinan DNS failure.

Request timeout for icmp_seq

Bisa network block, ICMP disabled, firewall, atau host unreachable.

5. host, dig, nslookup: DNS Debugging

Untuk backend Java, DNS failure sering muncul sebagai:

java.net.UnknownHostException

atau intermittent connection issue jika DNS record berubah, resolver cache bermasalah, atau service discovery tidak stabil.

host

host api.internal.example

Output sederhana:

api.internal.example has address 10.20.30.40

dig

dig api.internal.example

Lebih detail:

dig +short api.internal.example

Cek record tertentu:

dig A api.internal.example

dig AAAA api.internal.example

dig CNAME api.internal.example

dig TXT api.internal.example

Cek resolver tertentu:

dig @8.8.8.8 api.internal.example

dig @10.0.0.2 api.internal.example

nslookup

nslookup api.internal.example

Masih sering tersedia di banyak environment, tapi dig biasanya lebih kaya untuk diagnosis.

6. DNS Debugging Checklist

Gunakan checklist berikut sebelum menyimpulkan aplikasi bermasalah:

• Hostname yang digunakan aplikasi sama dengan hostname yang dites dari CLI?
• Hostname resolve dari mesin developer?
• Hostname resolve dari CI runner?
• Hostname resolve dari container/pod?
• Hostname resolve ke IP yang diharapkan?
• Ada perbedaan record internal vs external DNS?
• Ada split-horizon DNS?
• TTL sangat rendah atau sangat tinggi?
• Java DNS cache ikut memengaruhi behavior?
• Kubernetes service name benar?
• Namespace Kubernetes benar?
• Search domain Kubernetes memengaruhi resolusi nama?

Contoh debugging dari dalam pod:

kubectl exec -n <namespace> deploy/<deployment-name> -- sh -lc 'getent hosts api.internal.example || nslookup api.internal.example'

Jika resolve dari laptop berhasil tapi dari pod gagal, masalahnya kemungkinan bukan di aplikasi, melainkan DNS resolver, namespace, network policy, atau cluster configuration.

7. nc: TCP Port Reachability

nc atau netcat berguna untuk mengecek apakah koneksi TCP ke host:port bisa dibuat.

nc -vz api.internal.example 443

Contoh output berhasil:

Connection to api.internal.example port 443 [tcp/https] succeeded!

Contoh refused:

connect to api.internal.example port 443 (tcp) failed: Connection refused

Contoh timeout:

connect to api.internal.example port 443 (tcp) timed out

Interpretasi:

Untuk PostgreSQL, Kafka, RabbitMQ, Redis

nc -vz postgres.internal 5432
nc -vz kafka-broker.internal 9092
nc -vz rabbitmq.internal 5672
nc -vz redis.internal 6379

Ini hanya mengecek TCP reachability, bukan validasi protocol/auth.

8. Telnet Awareness

telnet sering dipakai lama untuk cek port:

telnet api.internal.example 443

Tetapi untuk modern workflow, lebih baik gunakan nc karena lebih jelas untuk port scanning sederhana dan lebih cocok untuk script.

Telnet awareness tetap penting karena beberapa runbook lama masih memakai telnet sebagai contoh.

9. ss dan netstat: Listening Port dan Socket State

Di Linux modern, ss lebih disarankan daripada netstat.

Cek listening port:

ss -ltnp

Arti flag:

• -l: listening
• -t: TCP
• -n: numeric, jangan resolve nama
• -p: tampilkan process

Cari port tertentu:

ss -ltnp | grep ':8080'

Cek koneksi established:

ss -tnp state established

Cek semua TCP state:

ss -tan

Jika service Java dikira listen di 8080 tapi tidak muncul di ss, kemungkinan:

• aplikasi belum start;
• binding ke port lain;
• binding ke 127.0.0.1 bukan 0.0.0.0;
• container port tidak diekspos;
• process crash;
• profile/config salah.

netstat awareness

netstat -ltnp

Di beberapa image minimal, netstat tidak tersedia karena bagian dari package lama seperti net-tools.

10. lsof: File dan Port Ownership

lsof menunjukkan file/socket yang dibuka oleh process.

Cek process yang memakai port:

lsof -i :8080

Cek listening TCP:

lsof -nP -iTCP -sTCP:LISTEN

Cek file descriptor process:

lsof -p <pid>

Use case backend:

• port conflict saat local development;
• terlalu banyak open files;
• connection leak;
• file log masih terbuka walaupun sudah rotated;
• process memegang file lama.

11. Binding Address: 127.0.0.1 vs 0.0.0.0

Salah satu bug local/container paling umum:

Application listens on 127.0.0.1:8080

Dari dalam container, service terlihat jalan. Tapi dari host atau pod lain tidak bisa connect.

Cek:

ss -ltnp | grep 8080

Kemungkinan output:

LISTEN 0 128 127.0.0.1:8080 0.0.0.0:* users:(('java',pid=123,fd=42))

Artinya hanya bind ke loopback.

Jika output:

LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(('java',pid=123,fd=42))

Artinya listen di semua IPv4 interface.

Untuk containerized service, biasanya aplikasi perlu bind ke 0.0.0.0, bukan localhost.

12. traceroute: Network Path Awareness

traceroute api.internal.example

atau di beberapa environment:

tracepath api.internal.example

Gunakan untuk memahami path jaringan secara kasar. Tetapi di enterprise/cloud, banyak hop tidak merespons ICMP/UDP traceroute, jadi output * * * tidak selalu berarti down.

Untuk debugging cloud/private network, traceroute bisa membantu, tetapi sering perlu dikombinasikan dengan security group, route table, subnet, private endpoint, VPC/VNet, dan Kubernetes network policy.

13. curl: HTTP Reachability dan Header Visibility

curl adalah tool utama untuk HTTP-level debugging.

curl -v https://api.internal.example/health

-v menampilkan:

• DNS resolution;
• TCP connection attempt;
• TLS handshake summary;
• request header;
• response header;
• HTTP status.

Cek hanya status code:

curl -s -o /dev/null -w '%{http_code}\n' https://api.internal.example/health

Cek timing:

curl -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total}\n' \
  https://api.internal.example/health

Timing ini sangat berguna untuk membedakan DNS lambat, TCP lambat, TLS lambat, server processing lambat, atau response transfer lambat.

14. wget: Download dan Basic HTTP Check

wget berguna untuk download file atau artifact:

wget https://repo.internal.example/artifacts/app.jar

Untuk debugging API, curl biasanya lebih fleksibel. Namun wget kadang tersedia di image minimal ketika curl tidak tersedia.

Cek header:

wget --server-response --spider https://api.internal.example/health

15. TLS Debugging dengan openssl s_client

TLS issue sering muncul di Java sebagai:

javax.net.ssl.SSLHandshakeException
PKIX path building failed
certificate_unknown
handshake_failure
No subject alternative DNS name matching ...

Gunakan:

openssl s_client -connect api.internal.example:443 -servername api.internal.example </dev/null

Hal penting:

• -connect host:port menentukan endpoint TCP.
• -servername mengirim SNI; wajib untuk banyak load balancer/ingress modern.
• </dev/null mencegah shell menunggu input interaktif.

Cek certificate chain:

openssl s_client -connect api.internal.example:443 -servername api.internal.example -showcerts </dev/null

Cek expiry:

echo | openssl s_client -connect api.internal.example:443 -servername api.internal.example 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

Contoh output:

notBefore=Jan  1 00:00:00 2026 GMT
notAfter=Mar 31 23:59:59 2026 GMT
subject=CN=api.internal.example
issuer=CN=Internal CA

16. TLS Debugging Checklist

• Hostname yang dipakai client cocok dengan SAN certificate?
• Certificate belum expired?
• Intermediate certificate lengkap?
• CA trusted oleh JVM truststore?
• Ada perbedaan truststore local vs container vs CI?
• Endpoint butuh SNI?
• Endpoint butuh mTLS/client certificate?
• TLS version/cipher suite kompatibel dengan JVM?
• Proxy/ingress melakukan TLS termination?
• Service mesh melakukan mTLS?

Untuk Java/JAX-RS client, TLS problem sering bukan karena kode HTTP client, tetapi karena:

• truststore tidak memuat internal CA;
• container image berbeda dari local JDK;
• cert rotation belum sinkron;
• hostname service berbeda dari SAN;
• mTLS secret tidak mount;
• proxy corporate intercepting TLS.

17. Proxy Debugging

Enterprise environment sering memakai HTTP proxy, corporate proxy, atau egress proxy.

Cek env var:

env | grep -i proxy

Umum:

HTTP_PROXY=http://proxy.internal:8080
HTTPS_PROXY=http://proxy.internal:8080
NO_PROXY=localhost,127.0.0.1,.svc,.cluster.local

Curl dengan proxy:

curl -v -x http://proxy.internal:8080 https://api.external.example

Bypass proxy:

curl -v --noproxy '*' https://api.internal.example

Checklist:

• Apakah Java process membaca proxy env?
• Apakah JVM options mengatur proxy berbeda?
• Apakah NO_PROXY mencakup internal service domain?
• Apakah CI runner memakai proxy?
• Apakah Kubernetes pod memakai proxy env dari base deployment template?

18. Kubernetes Networking Context

Dalam Kubernetes, endpoint access dipengaruhi oleh:

• namespace;
• service name;
• ClusterIP;
• headless service;
• pod IP;
• ingress;
• service mesh;
• network policy;
• DNS search domain;
• readiness endpoint;
• endpoint slice;
• port name dan targetPort.

Cek service:

kubectl get svc -n <namespace>

Detail service:

kubectl describe svc -n <namespace> <service-name>

Cek endpoints:

kubectl get endpoints -n <namespace> <service-name>

atau:

kubectl get endpointslice -n <namespace> -l kubernetes.io/service-name=<service-name>

Cek dari pod:

kubectl exec -n <namespace> deploy/<deployment-name> -- sh -lc 'curl -v http://service-name:8080/health'

Jika service ada tapi endpoint kosong, kemungkinan pod belum ready atau selector salah.

19. Docker Networking Context

Untuk local Docker:

docker ps

docker inspect <container-name>

docker network ls

docker network inspect <network-name>

Cek port mapping:

docker ps --format 'table {{.Names}}\t{{.Ports}}'

Common issue:

• aplikasi bind ke 127.0.0.1 di container;
• port container tidak dipublish ke host;
• container tidak satu network dengan dependency;
• menggunakan localhost dari container untuk mengakses host/dependency yang salah;
• service name Docker Compose tidak sesuai.

Dalam Docker Compose, antar service biasanya akses pakai service name:

postgres:5432
redis:6379
rabbitmq:5672

bukan localhost.

20. Database and Broker Connectivity

PostgreSQL

TCP check:

nc -vz postgres.internal 5432

Protocol-level check jika psql tersedia:

psql 'host=postgres.internal port=5432 dbname=mydb user=myuser sslmode=require' -c 'select 1;'

Redis

TCP check:

nc -vz redis.internal 6379

Protocol-level check:

redis-cli -h redis.internal -p 6379 PING

RabbitMQ

AMQP port:

nc -vz rabbitmq.internal 5672

Management UI jika tersedia:

curl -v http://rabbitmq.internal:15672/api/overview

Kafka

TCP check:

nc -vz kafka-broker.internal 9092

Kafka membutuhkan protocol-level tooling untuk validasi lebih jauh. TCP success belum membuktikan bootstrap broker, advertised listener, auth, TLS, SASL, dan topic access benar.

21. Timeout Semantics

Timeout perlu dibaca dari konteks layer:

Contoh curl dengan timeout eksplisit:

curl -v \
  --connect-timeout 3 \
  --max-time 10 \
  https://api.internal.example/health

Untuk bug report, selalu tulis timeout mana yang terjadi.

22. tcpdump Awareness

tcpdump adalah tool kuat tetapi harus dipakai hati-hati karena bisa menangkap data sensitif.

Contoh capture terbatas:

sudo tcpdump -i any host api.internal.example and port 443 -c 20

Capture ke file:

sudo tcpdump -i any port 443 -w capture.pcap -c 100

Production safety:

• gunakan filter seketat mungkin;
• batasi jumlah packet dengan -c;
• jangan capture payload sensitif tanpa approval;
• simpan file sesuai kebijakan security;
• redaksi atau batasi distribusi file .pcap.

Gunakan tcpdump ketika layer di atas tidak cukup menjelaskan apakah packet keluar/masuk.

23. Java/JAX-RS Impact

Networking issue memengaruhi backend Java/JAX-RS dalam beberapa bentuk:

• inbound request gagal karena ingress/proxy/service mesh;
• outbound REST client gagal karena DNS/TLS/proxy;
• database connection pool tidak bisa connect;
• Kafka/RabbitMQ client gagal bootstrap;
• Redis client timeout;
• health check gagal karena dependency transitif;
• startup lama karena dependency check blocking;
• retry storm karena connect/read timeout terlalu agresif;
• thread pool exhaustion akibat hung network call;
• circuit breaker terbuka karena upstream failure.

Senior engineer perlu mengaitkan CLI evidence dengan application behavior:

curl from pod fails DNS
=> kemungkinan aplikasi juga gagal DNS
=> cek resolver/namespace/service name
=> jangan langsung ubah kode client

24. Observability Correlation

Networking CLI harus dikombinasikan dengan observability:

• application logs;
• access logs;
• ingress logs;
• service mesh telemetry;
• metrics latency/error rate;
• trace spans;
• deployment events;
• DNS/service discovery events;
• cloud load balancer metrics.

Contoh evidence yang kuat:

10:01:12 deployment v1.42 started
10:03:05 readiness failed for quote-order-service
10:03:10 curl from pod to catalog-service: DNS resolves
10:03:12 nc to catalog-service:443 succeeds
10:03:13 openssl handshake fails: certificate verify error
10:03:20 app log shows SSLHandshakeException

Ini jauh lebih kuat daripada hanya berkata “API down”.

25. Failure Mode: DNS Works Locally, Fails in Pod

Kemungkinan:

• internal DNS hanya tersedia di VPN/laptop, bukan cluster;
• Kubernetes CoreDNS issue;
• namespace search domain salah;
• service name tidak fully qualified;
• network policy memblokir DNS;
• pod image tidak punya resolver config benar;
• sidecar/service mesh mengubah behavior.

Debug:

kubectl exec -n <ns> deploy/<app> -- sh -lc 'cat /etc/resolv.conf'

kubectl exec -n <ns> deploy/<app> -- sh -lc 'getent hosts <host> || nslookup <host>'

26. Failure Mode: TCP Refused

Artinya target aktif menolak koneksi atau tidak ada listener.

Debug:

nc -vz host 8080

ss -ltnp | grep 8080

kubectl describe svc -n <ns> <svc>

kubectl get endpoints -n <ns> <svc>

Kemungkinan:

• service belum start;
• port salah;
• targetPort salah;
• container port mismatch;
• listener bind ke localhost;
• pod readiness false sehingga endpoint kosong;
• wrong service selector.

27. Failure Mode: TCP Timeout

Timeout biasanya lebih sulit karena packet bisa drop di banyak tempat.

Debug:

nc -vz -w 3 host 443

curl -v --connect-timeout 3 --max-time 10 https://host/health

Kemungkinan:

• firewall/security group;
• Kubernetes network policy;
• route table salah;
• private endpoint tidak reachable;
• proxy/egress policy;
• wrong subnet/VPC/VNet;
• load balancer tidak reachable;
• service mesh policy.

Evidence penting: dari mana command dijalankan. Laptop, CI runner, pod, node, bastion, dan production subnet bisa punya network path berbeda.

28. Failure Mode: TLS Certificate Error

Debug:

openssl s_client -connect host:443 -servername host </dev/null

curl -v https://host/health

Kemungkinan:

• certificate expired;
• SAN mismatch;
• missing intermediate CA;
• JVM truststore tidak punya CA;
• cert rotation belum selesai;
• mTLS client cert salah;
• proxy terminating TLS;
• hostname yang dipakai aplikasi berbeda dari hostname cert.

Jangan langsung memakai curl -k sebagai solusi. -k hanya membuktikan bahwa bypass certificate validation membuat request lanjut. Untuk production, itu hampir selalu bukan fix yang acceptable.

29. Production-Safe Networking Debugging Workflow

Checklist:

1. Tuliskan source dan target.
2. Jalankan DNS check dari source environment yang benar.
3. Jalankan TCP check.
4. Jalankan TLS check jika HTTPS/TLS.
5. Jalankan protocol check dengan request minimal.
6. Catat timestamp, command, output, environment.
7. Redact secret/token/header sensitif.
8. Bandingkan local vs CI vs pod vs production jika perlu.
9. Jangan lakukan mutating request kecuali jelas aman dan diizinkan.

30. Command Pattern untuk Evidence Bundle

Gunakan format yang bisa direproduksi:

set -o pipefail

TARGET_HOST="api.internal.example"
TARGET_PORT="443"
TARGET_URL="https://${TARGET_HOST}/health"

printf 'timestamp=%s\n' "$(date -Iseconds)"
printf 'host=%s\n' "$(hostname)"
printf 'target=%s:%s\n' "$TARGET_HOST" "$TARGET_PORT"

printf '\n## DNS\n'
(getent hosts "$TARGET_HOST" || nslookup "$TARGET_HOST" || true) 2>&1

printf '\n## TCP\n'
(nc -vz -w 3 "$TARGET_HOST" "$TARGET_PORT" || true) 2>&1

printf '\n## TLS\n'
(echo | openssl s_client -connect "${TARGET_HOST}:${TARGET_PORT}" -servername "$TARGET_HOST" 2>&1 | head -80 || true)

printf '\n## HTTP\n'
(curl -v --connect-timeout 3 --max-time 10 "$TARGET_URL" || true) 2>&1

Catatan: jangan simpan token atau payload sensitif dalam evidence bundle.

31. PR Review Checklist untuk Networking Tooling

Saat mereview script, workflow, atau config yang menyentuh network:

• Apakah hostname/port configurable?
• Apakah timeout eksplisit?
• Apakah retry punya backoff dan batas maksimum?
• Apakah command aman dijalankan di production?
• Apakah secret tidak tercetak di log?
• Apakah DNS/TLS/proxy behavior terdokumentasi?
• Apakah command bisa dijalankan dari local dan CI?
• Apakah destructive action dipisah dari diagnostic action?
• Apakah error message actionable?
• Apakah script membedakan connection refused vs timeout vs TLS failure?
• Apakah Kubernetes namespace/context divalidasi?
• Apakah cloud account/subscription/profile divalidasi sebelum command?

32. Internal Verification Checklist

Verifikasi ke internal CSG/team, jangan diasumsikan:

• Hostname convention untuk service internal.
• DNS pattern untuk Kubernetes service, ingress, API gateway, dan cloud private endpoint.
• Apakah ada service mesh/mTLS.
• Apakah ada corporate proxy/egress proxy.
• Apakah pod boleh melakukan curl, nc, dig, openssl, atau tcpdump.
• Apakah debug image tersedia.
• Apakah production pod boleh di-exec.
• Network policy antar namespace/service.
• Security group/firewall ownership.
• TLS certificate issuance dan rotation process.
• Internal CA dan JVM truststore process.
• Runbook untuk PostgreSQL, Kafka, RabbitMQ, Redis connectivity.
• Escalation path ke platform/SRE/network/security.
• Standard evidence bundle untuk incident.

33. Practical Exercises

Exercise 1 — DNS vs TCP

Ambil satu endpoint internal non-production. Dari local dan dari pod, bandingkan:

dig +short <host>

nc -vz <host> <port>

Tuliskan apakah failure terjadi di DNS atau TCP.

Exercise 2 — TLS Certificate Inspection

openssl s_client -connect <host>:443 -servername <host> </dev/null \
  | openssl x509 -noout -subject -issuer -dates

Catat subject, issuer, expiry, dan apakah hostname sesuai.

Exercise 3 — HTTP Timing

curl -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://<host>/health

Interpretasikan bottleneck utama.

Exercise 4 — Kubernetes Service Endpoint

kubectl get svc -n <ns> <svc>
kubectl describe svc -n <ns> <svc>
kubectl get endpoints -n <ns> <svc>

Jelaskan hubungan service selector, pod readiness, dan endpoint availability.

34. Key Takeaways

• Networking debugging harus mengikuti layer: DNS → route/network → TCP → TLS → protocol → application.
• ping bukan bukti final service reachable.
• nc baik untuk TCP reachability, tetapi bukan protocol validation.
• openssl s_client sangat penting untuk TLS/mTLS diagnosis.
• curl -v memberi evidence HTTP, TLS, dan connection flow.
• Kubernetes networking perlu dicek dari dalam pod/namespace yang relevan.
• Timeout, refused, dan DNS failure punya makna berbeda.
• Production debugging harus read-only first, bounded, timestamped, dan redacted.
• Senior engineer harus bisa membedakan bug aplikasi dari failure network environment.