Day 14f –Mini Task: Port Probe & Interpretation

This is Part 6 of the Networking for DevOps series.

https://90-days-devops-with-shubham.hashnode.dev/day-14e-how-to-debug-network-issues-like-a-devops-engineer

Step 1: Identify Listening Ports

From your ss -tulpn output, you have:

• 22 → SSH

• 53 → DNS (local resolver)

• 4330 → custom service

• 44321, 44322, 44323 → custom/local apps

ss -tulpn

Step 2: Test One Port

Let’s take port 22 (SSH) as example.

nc -zv localhost 22

Expected output:

Connection to localhost 22 port [tcp/ssh] succeeded!

Alternative Test (HTTP-type ports)

For something like 4330:

curl -I http://localhost:4330

• If it’s a web service → you’ll get HTTP response

• If not → connection may fail or hang

Observation

• Ports 22, 53, 4330, 44321–44323 are in LISTEN state.

• Testing with nc -zv localhost 22 shows connection successful.

• This confirms the service is reachable locally.

Step 3: Interpretation

• Reachable → service running

• If Not Reachable

If command shows:

Connection refused

Write:

👉 The port is not reachable.

Next Checks

If NOT reachable, check:

1. Service status

sudo systemctl status ssh

1. Is service running on that port

ss -tulpn | grep <port>

1. Firewall rules

sudo ufw status

Result:

inactive

👉 Meaning:

✔ No firewall blocking anything

4. Correct port / protocol

• Maybe service is not HTTP → curl won’t work

Simple Understanding

• ss → shows “door is open”

• nc → checks “can I enter that door?”

• curl → checks “is it a web door?”

Debugging Mindset

Always troubleshoot layer by layer:

Step 1: DNS

dig domain.com

Step 2: Network

ping domain.com

Step 3: Port

nc -zv domain.com 80

Step 4: Application

curl -I http://domain.com 

Reflection

Fastest signal when something breaks:

HTTP issue → curl / curl -I
Host reachable → ping
DNS issue → dig / nslookup

Layer-Based Debugging:

If DNS fails:

• Check Application layer → DNS config

• Check:

  cat /etc/resolv.conf
  DNS server
  dig domain.com
  

If HTTP 500 appears:

• Application issue → check logs

• Means:

  • Network OK

  • TCP works

  • Server reached

  • Backend failed

👉 Check:

• Logs

• Backend services

Real Incident Follow-ups

1. Service Check

systemctl status <service>
journalctl -u <service> -n 50

1. Network / Firewall

ufw status
iptables -L

1. Advanced Checks

dig google.com @8.8.8.8
cat /etc/resolv.conf

Now connect the above WhatsApp Example → Linux Tools Mapping

 nc -zv localhost 22

👉 Checks:

“Is this door open?”

✔ SSH works → port is reachable

Like:

“Can I reach WhatsApp server port?”

 curl -I http://...

👉 Talks to server and asks:

“What do you reply?”

✔ You see headers (response)

Like:

“Can server respond properly?”

dig / nslookup

👉 Asks:

“Where is server located?”

✔ returns IP address

Like WhatsApp finding server location

 ss -tulpn

👉 Shows:

“Which apps are listening on this machine?”

✔ SSH, custom ports, etc.

Like:

“Which doors are open on house?”

Ports (22, 80, 443)

Think:

• 22 → SSH (remote login door)

• 80 → HTTP (normal web door)

• 443 → HTTPS (secure web door)

Meaning:

“Different doors for different services”

Important concepts we saw in lab

Binding (VERY IMPORTANT)

• 0.0.0.0 → open to everyone

• 127.0.0.1 → only local machine

Meaning:

“Who is allowed to enter this door?”

Firewall (ufw / iptables / AWS SG)

• ufw status → local firewall check

• iptables -L → detailed rules

• AWS Security Group → cloud firewall

Meaning:

“Security guard deciding who enters”

Result:

• nc succeeded → port open + service alive

• connection refused → port closed OR no service

• DNS works but port fails → service issue, not network issue

Key Learnings

• Troubleshooting = layer-by-layer approach

• Always go in order:

  • Reachability

  • DNS

  • Port

  • Application

• Commands like:

  • ping

  • traceroute

  • ss

  • dig

  • curl

👉 Provide fast, actionable signals

Key Insights

• curl -I → fastest HTTP validation

• traceroute → reveals real network path

• ss -tulpn → maps services to ports

• DNS can resolve to multiple IPs (load balancing)

• Some ports (like 53) behave differently on TCP vs UDP

This is how I would debug a real production issue at 2 AM — starting from DNS down to application.

#90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham