Bootcamp Module 5: Networking

Networking failures feel personal. They’re usually listeners, routes, firewalls, or DNS. This module teaches you to separate those layers.

Bootcamp hub · Prev: Module 4

Learning goals

  • Use ss/ip to see listeners and routes
  • Debug DNS with dig/resolvectl
  • Resolve EADDRINUSE calmly

Required posts

Lab

  1. Run a tiny HTTP server; find it with ss -ltnp.
  2. Start a second instance on the same port; fix the conflict.
  3. Break DNS in a lab VM (bad resolv/NM setting) and repair using the checklist.

Next: Module 6 — Automation gateway →

Layers you’ll actually use

  1. Interface up? (ip link, ip a)
  2. Route to destination? (ip r, ping IP)
  3. Listener bound? (ss -ltnp)
  4. Firewall allowing? (nft/iptables/sg)
  5. Name resolving? (dig/resolvectl)
  6. App protocol healthy? (curl, tls, auth)

Skip steps and you’ll mislabel DNS as “the network is down.”

Lab: deliberate conflicts

  1. Bind two processes to the same port; resolve using the port guide.
  2. Point DNS at a bad resolver; repair with DNS checklist.
  3. Optional: from a Windows lab VM, compare the mindset in RDP can’t connect.

Notes on cloud

Security groups are firewalls you forget exist. Always check cloud ACLs in parallel with host firewalls. Serial console remains your friend when you lock yourself out with a bad nft rule.

Exit criteria

You can diagnose “curl: could not resolve host” vs “connection refused” vs “timed out” without mixing the meanings.

Firewall dual vision

Host firewall and cloud security group both exist. Closing only one doesn’t close the story. Draw both boxes in your notes for every lab VM.

curl as a truth serum

curl -vI https://example.com
curl -4 / curl -6

Verbose headers show whether TLS, redirect, or DNS failed. Pair with dig when names misbehave.

Quiz

  1. Connection refused — what does it usually mean?
  2. Timeout — what are top suspects?
  3. Why might [email protected] work while dig without @ fails?

Extended lab: three failure modes

Create or observe: (1) connection refused, (2) timeout via firewall drop, (3) DNS NXDOMAIN. Label each from client symptoms alone before checking the server. Compare with the checklists on ports and DNS.

IP vs name discipline

Always test by IP when names misbehave. Always test by name when certificates and virtual hosts matter. Write that on a sticky note. It prevents circular debugging.

Packet path sketch

Draw: app → local firewall → cloud SG → router → destination SG → destination firewall → listener. Mark where you have logs. Most “network issues” are a box on that diagram you didn’t check.

Listening vs established

ss -ltnp shows listeners. ss -tnp shows established connections. A healthy listener with zero clients might be fine; a pile of connections in weird states can hint at app or network issues. Don’t memorize every state on day one — know where to look.

HTTP debugging basics

curl -v http://127.0.0.1:8080/
curl -k https://127.0.0.1:443/   # lab only for self-signed

Status codes tell stories: 502 often means proxy can’t reach backend; 504 means timeout; connection refused means nothing listening.

Write a personal network runbook

One page: commands for IP check, route check, DNS check, listener check, firewall check. Keep it next to the bootcamp bookmarks. You’ll use it more than any certification PDF.

One more drill: explain three errors

Without looking anything up, define in your notes: connection refused, connection timed out, could not resolve host. Then verify against the port and DNS posts. If your definitions match, Module 5 stuck.

When stuck, force yourself to name the layer before changing configs: interface, route, DNS, listener, firewall, or app.