- What order keeps network troubleshooting from turning into random guessing?
- How do you know when the problem is DNS, the service, or the firewall?
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
Before this lesson
What you should learn
- Use a layered troubleshooting sequence to diagnose a broken connection without guessing, skipping layers, or changing settings too early.
Visual model
Concept to practice path
Each lesson is meant to move from an idea, to an example, to a safe practice step.
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.
Resolve-DnsName db-prod.corporate.local
or
nslookup db-prod.corporate.local
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.
ping 10.5.20.99 tracert 10.5.20.99
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.
Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq 5432
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.
wf.msc
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
- resolve the name
- confirm raw reachability
- confirm the service is listening
- confirm the firewall policy
- 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.
Learning loop
Recall it, check it, then practice it.
Do this before moving on. It turns reading into memory and safer action.
- Walk through a layered network-debug sequence without notes.
- Explain why each step came before the next one.
Review again after 1, 3, 7 days.
What to do next
Best next step PracticeUse the matching lab or keep building skill in practice.