Learn Understand first, then practice while the concept is still fresh.

M34 - Network Lab: Full Connectivity Debug

Use a layered troubleshooting sequence to diagnose a broken connection without guessing, skipping layers, or changing settings too early.

Networking

Network Lab: Full Connectivity Debug

Use a layered troubleshooting sequence to diagnose a broken connection without guessing, skipping layers, or changing settings too early.

35 min INTERMEDIATE BOTH Curriculum-reviewed
Prerequisites
Module M28 - Network Model: How Networks Work Module M30 - Network Config: CLI Module M31 - DNS Deep Dive Module M32 - Network Diagnostics Module M33 - Firewall: GUI and CLI
What you should be able to do after this
  • Follow a consistent connectivity troubleshooting order.
  • Separate naming, routing, service, and firewall problems.
  • Explain which evidence pointed to each conclusion.

The Goal

This capstone is not about memorizing one perfect command. It is about keeping the troubleshooting order clean.

A developer says a service is unreachable. Your job is to test the chain one layer at a time until the real break becomes obvious.

Core Rule

Do not change firewall rules, service configs, or routing until the earlier checks have told you which layer is actually failing.

Scenario

A developer reports that they cannot connect to db-prod.corporate.local.

Sometimes they see a name-resolution error. Sometimes they say the host is unreachable. Sometimes they say the connection is refused.

Those are not all the same failure.

Your task is to work through the problem in a better order.

Step 1: Check Name Resolution

If the hostname itself does not resolve, there is no point skipping ahead to service ports yet.

Check Name Resolution on Windows

Resolve-DnsName db-prod.corporate.local

or

nslookup db-prod.corporate.local

Check Name Resolution on Linux

dig db-prod.corporate.local

If this fails but raw IP access later works, the first real problem is DNS, not the whole network.

Step 2: Check Raw Reachability

Once you have a usable IP address, test whether the path exists at all.

Check Reachability on Windows

ping 10.5.20.99 tracert 10.5.20.99

Check Reachability on Linux

ping -c 2 10.5.20.99 traceroute 10.5.20.99

If the path is reachable, the problem may have moved up from basic network path to service or policy.

Step 3: Check Whether the Service Is Listening

On the target server, inspect whether the database is actually listening on the expected port and whether it is bound to an address reachable from the network.

Inspect Listening State on Windows

Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq 5432

Inspect Listening State on Linux

sudo ss -tulpn | grep 5432

A service bound only to loopback is a different problem from a service not running at all.

Step 4: Check the Firewall Layer

If the service is listening correctly but clients still cannot reach it, then firewall policy becomes the next suspect.

Think About Windows Firewall

wf.msc

Think About Linux Firewall

sudo ufw status verbose

This is where you decide whether a port is being blocked after the earlier checks have already narrowed the problem.

A Better Troubleshooting Narrative

  1. resolve the name
  2. confirm raw reachability
  3. confirm the service is listening
  4. confirm the firewall policy
  5. only then change what needs changing

That order is the real skill from this section.

Move On When

You are ready for the software section when you can explain why DNS, reachability, service binding, and firewall state are distinct checks rather than one giant vague networking problem.