Before you begin
Start with the networking foundations. Use your own lab hosts and expected service ports. These checks observe configuration and make ordinary connections; use only endpoints you are permitted to test.
Working toward: Diagnose a failed service without confusing a DNS error, a closed port, and an application error.
Read each explanation, run the example in your own lab, and attempt the exercise before opening its answer. Published lessons are ready to study; unfinished roadmap topics remain planned.
Validation: Based on upstream documentation. Platform-specific labs require the learner’s matching environment and are not execution-tested here.
1. Name resolution is a separate step
A hostname must resolve to the intended address before a name-based connection can reach the right server. A successful lookup proves only that a resolver returned a result. It does not prove routing or application health.
# Windows PowerShell:
Resolve-DnsName localhost
# Linux:
getent hosts localhostWhat to expect
Loopback results from the local resolver configuration; exact IPv4/IPv6 output varies.
Your turn
A public hostname resolves but the service is unreachable. Is DNS necessarily broken?
Show answer and reasoning
No. Check whether the returned address is correct, then inspect routing, transport, TLS and application behavior separately.Watch for: Hosts files, caches, split DNS and proxies can make two clients resolve or reach different targets.
Link to this lesson2. A TCP connection has a target port
A route gets packets toward a host; a listener accepts connections on an address and port. A firewall may permit or block that flow. Windows Test-NetConnection can report TCP success, but it does not validate a web page or database query.
# Replace LAB_HOST and 443 with your own lab target:
Test-NetConnection -ComputerName LAB_HOST -Port 443
# On the Linux server, inspect listeners:
ss -lntWhat to expect
A client TCP result and server-side listening sockets. The test fails if the chosen lab service is not configured.
Your turn
The process listens only on 127.0.0.1. Will opening the firewall make it reachable from another machine?
Show answer and reasoning
No. Loopback is local to the server. Review the intended bind address and permitted clients, then change the lab configuration deliberately.Watch for: A failed ping does not prove TCP is blocked; ICMP and TCP policy can differ.
Link to this lesson3. Inspect the application boundary
TLS verifies the peer and protects transport; HTTP then carries the request and response. curl can show these stages. Use a lab HTTPS endpoint with a valid trusted certificate; do not bypass certificate checks just to get a green result.
curl --verbose --connect-timeout 5 --max-time 15 https://YOUR_LAB_HOST/What to expect
Resolution and connection information, TLS negotiation and an HTTP response, or a stage-specific error. Replace the placeholder before running.
Your turn
TCP succeeds but certificate validation fails. What should you inspect?
Show answer and reasoning
Check hostname coverage, expiry, trust chain and client time. Opening another firewall port does not fix an invalid certificate chain.Watch for: Verbose output may include headers. Do not share credentials, cookies or tokens from a real session.
Link to this lessonPath to advanced
In-progress stages identify the lessons already published. All other listed topics remain planned. Each addition needs teaching, a reproducible lab, failure cases, and a checkpoint before the capstone.
Layer 2 and 3
VLANs, switching, ARP/neighbor discovery, routing and packet captures.
PLANNEDServices
DNS, DHCP, time, TLS, firewalls, proxies and dependency diagrams.
PLANNEDCapstone
Build a small lab, introduce one failure at a time and document the evidence and correction.
PLANNED
References
Original AUWEN lessons, with upstream documentation for further study and version checks.
All learning paths and update notes →