Hands-on Lab·CompTIA Linux+
Network faults, from the client outwards
Six rungs, each with one command and one unambiguous signal: the interface, the routing decision, the neighbour, the name, the port and the protocol. The centre of the page blocks ICMP on the far host and shows ping failing completely while SSH answers and the ARP entry stays reachable - three layers measured in the same second.
Troubleshooting Guide 26 of 28 Intermediate
- PlatformsUbuntu 26.04 LTS + AlmaLinux 10.2
- Mandatory access controlAppArmor on Ubuntu, SELinux enforcing on Alma
- Firewallufw / nftables 1.1.6
- TimeAbout 27 min
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| LPLUS-A01 | 192.168.0.73 | Ubuntu 26.04 LTS | Debian-family host - apt, ufw, netplan, AppArmor | 2 Core | 4 GB | 50 GB |
| LPLUS-B01 | 192.168.0.74 | AlmaLinux 10.2 | RPM-family host - dnf, firewalld, NetworkManager, SELinux | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when a connection fails and you do not yet know which layer is at fault. This matters because the instinct is to start at DNS or the firewall, and because the ping that everyone runs first cannot distinguish a host that is down from one that simply does not answer ICMP.
- asking
ip route getwhich way a specific packet will actually go - reading an
INCOMPLETEneighbour entry as "nothing on this subnet answered" - telling NXDOMAIN (exit 2) from an unreachable resolver (exit 9)
- proving a host is up and reachable when ping says it is not
- testing a port with
nc -zand reading its exit code - distinguishing an open port from the right service behind it
Before you start
- network-configuration-on-both-families
- publishing-a-service-and-the-three-ways-a-client-fails
-
The bottom of the ladder, on a path that works
-
The rung most people skip: is it even there
-
Names, and two failures that are not the same
-
Ping is not a test
-
The port, and the thing behind the port
-
Putting both machines back