Linux Networking and Troubleshooting
Configure and diagnose Linux network interfaces, routing, name resolution, and firewalls from the command line.
- Certification
- CompTIA Linux+
- Recommended study time
- 6h 35m
- Status
- Not started
Recommended study time
About 6h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.
- Read the lesson22 min
About 2,863 words at a careful technical reading pace.
- Second pass with notes13 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice3h 20m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 40m
4 short review sessions spread over the following weeks.
Learning objectives
- Inspect interfaces, addresses, routes, and sockets using modern tooling.
- Configure persistent addressing and name resolution correctly.
- Diagnose connectivity faults on a headless server methodically.
Start here
About 8 minutes of reading, in 10 short parts.
Servers usually have no screen and no network icon to click, so every network question has to be answered from the command line. A small set of tools, used in a consistent order, resolves the overwhelming majority of connectivity problems.
Where you meet it: A freshly rebooted server can no longer reach the internet even though nothing was changed, because its network configuration was never made to persist.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Think of a server's network setup like a building's postal address and internal mail routing. The building needs a valid street address (an IP address) to receive anything at all, a sign pointing toward the nearest post office for anything going further afield (a default route), and a phone book to translate a company name into a street address (DNS). If any one of these is missing or wrong, mail either never arrives, or arrives at the wrong building, or nobody can even look up where to send it.
On a server, all of this is normally set once and then expected to survive being switched off and on again, unlike a laptop that reconnects itself to whatever network it finds. If the settings are only applied by hand and never saved properly, the server 'forgets its address' the next time it restarts, which is a surprisingly common and very confusing failure for beginners.
Key ideas
If you remember nothing else from this topic, remember these.
- The ip command family has replaced ifconfig and route on modern distributions, and it is expected knowledge for interface, address, and routing inspection.
- ss reports socket state faster and with richer detail than the older netstat, showing exactly which process is listening on which port.
- DNS problems and connectivity problems produce different symptoms and need different tools; confusing them wastes troubleshooting time.
- A layered troubleshooting order, physical and interface state, then IP configuration, then routing, then DNS, then the application port, resolves most issues faster than guessing.
- Firewall rules can silently block traffic that every other layer reports as healthy, so checking iptables or firewalld rules belongs in the standard sequence, not as an afterthought.
- Traceroute and ping test different things: ping confirms basic reachability, while traceroute shows where along the path a failure or high latency occurs.
Tracing why a new application server cannot reach a database
A worked example, step by step.
A freshly built application server times out connecting to a database on port 5432 despite both machines appearing to be up.
- 01Confirm the interface is upip addr show shows eth0 has state UP and a valid address 10.0.4.15/24, ruling out a link-level problem.
- 02Check basic reachabilityping -c4 10.0.4.20 (the database host) succeeds, confirming network-layer connectivity between the two hosts.
- 03Test the specific portnc -zv 10.0.4.20 5432 reports connection refused rather than timing out, which is a different signal than a routing problem.
- 04Check listening sockets on the database hostss -tulpn on the database server shows postgres bound to 127.0.0.1:5432 only, not the external interface.
- 05Identify the root causeThe database configuration file restricts listen_addresses to localhost, which explains why local connections work but remote ones are refused.
- 06Apply the fixlisten_addresses is changed to include the internal interface address, and the database service is restarted with systemctl restart postgresql.
- 07Re-test the portnc -zv 10.0.4.20 5432 now reports succeeded, confirming the socket is reachable.
- 08OutcomeThe application connects successfully once the database is actually listening on the interface the application server can reach.
Outcome: The layered check isolated the failure to the database's own bind address rather than the network path, avoiding wasted time on firewall or routing changes.
Linux networking and troubleshooting reference
Worth keeping at hand while you work.
- ip addr show
- Lists interfaces and their assigned IP addresses and state.
- ip route show
- Displays the routing table, including the default gateway.
- ss -tulpn
- Shows listening TCP and UDP sockets with process names and PIDs.
- ping -c4 host
- Sends four ICMP echo requests to test basic reachability.
- traceroute host
- Shows each hop along the path to a destination and where delay or failure occurs.
- nc -zv host port
- Tests whether a specific TCP port is open without sending real application data.
- dig / nslookup
- Query DNS records directly to isolate name resolution problems.
- /etc/resolv.conf
- Configures which DNS resolvers a Linux host uses.
- /etc/hosts
- Local static hostname to IP mappings, checked before DNS.
- iptables -L / firewall-cmd --list-all
- Shows current firewall rules on iptables-based and firewalld-based systems.
- curl -v
- Shows the full request and response cycle, useful for isolating HTTP-layer problems from network-layer ones.
- connection refused vs timeout
- Refused means a host actively rejected the connection; timeout usually means nothing answered, often a firewall or routing issue.
Common misunderstandings
What most beginners get wrong here.
If ping succeeds, the application should also be able to connect.
Ping only tests ICMP reachability; the specific TCP port the application needs could still be closed, filtered, or bound to the wrong interface.
Connection refused and connection timeout mean the same underlying problem.
Refused means a host actively responded and rejected the connection, usually because nothing is listening there, while timeout usually means no response at all, often a firewall or routing issue.
ifconfig is still the standard tool for checking interface configuration.
It is deprecated on most modern distributions in favor of ip addr, which is what current exams and tooling expect.
A service bound to 127.0.0.1 is reachable from other machines on the same network.
Binding to localhost only accepts connections originating from the same machine; it must bind to the actual interface address to accept remote connections.
DNS problems and routing problems look and behave the same way.
DNS failures typically show as name resolution errors before any connection attempt, while routing failures occur after a valid IP is already known.
Exam traps
How the question writers try to catch you out.
- Given a scenario where ping works but an application fails to connect, expect the answer to point at the specific port or service binding, not the network layer.
- Modern Linux+ objectives expect ip and ss command syntax rather than the deprecated ifconfig and netstat equivalents.
- A question distinguishing connection refused from connection timeout is testing whether you can map the message to whether a host responded at all.
- Traceroute questions expect you to identify at which hop the delay or failure begins, not just that the destination is unreachable.
- A firewall blocking a specific port is often the trick answer when every lower layer, interface, IP, and routing, tests as healthy.
Check yourself
Answer in your head first, then reveal. This is not scored.
What is the difference between a connection refused and a connection timeout?
Why might a database be unreachable remotely even though it works locally on the same host?
Which command shows listening sockets along with the owning process?
What does traceroute tell you that ping does not?
What is the modern replacement for ifconfig on most Linux distributions?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
The ip command manages interfaces, addresses, and routes. ss lists listening and established sockets. Name resolution uses /etc/resolv.conf or systemd-resolved, with dig for testing. Firewalls are configured through nftables, firewalld, or ufw. Persistent configuration lives in NetworkManager, netplan, or distribution-specific files.
Why It Matters
Cloud instances, containers, and appliances are all Linux underneath. The ability to prove whether a server is listening, reachable, and resolving is fundamental to every operations role.
How It Works
- The kernel routing table selects an interface and next hop for each destination.
- Services bind to specific addresses and ports, which determines who can reach them.
- Packet filters evaluate rules before traffic reaches or leaves the service.
Where You See It
- Cloud instances, container hosts, web and database servers, network appliances, and CI runners.
Key Terms
- ip addr
- Displays interfaces and their assigned addresses.
- ss -tulpn
- Lists listening TCP and UDP sockets with owning processes.
- Default route
- The route used when no more specific entry matches.
- resolv.conf
- The file defining DNS resolvers for the system.
- nftables
- The modern Linux packet filtering framework.
Examples
- ss -tulpn quickly proves whether a service is listening on the expected interface and port.
- A service bound to 127.0.0.1 is unreachable remotely regardless of firewall rules.
Common Problems
- Service bound to localhost only
- Missing default route
- Firewall blocking the port
- Broken DNS configuration
- Configuration lost after reboot
How It Fails
- Configuration applied with ip commands disappears at reboot if not persisted.
- A firewall permitting IPv4 but not IPv6 causes intermittent failures on dual-stack clients.
- A wrong search domain resolves short names to the wrong hosts.
How to Troubleshoot
- Confirm the listener with ss before testing from a remote host.
- Test from the server outward, then from the client inward, comparing results.
- Query DNS explicitly with dig rather than relying on application behaviour.
Practical Knowledge
- Record whether an issue is IPv4 or IPv6; dual-stack differences hide many faults.
- Persist changes in the managing subsystem and verify with a reboot in a maintenance window.
Exam Coverage
- Linux network configuration tools
- Name resolution and sockets
- Firewall basics and troubleshooting
Interview Questions
- How do you prove a Linux service is listening externally?
- Why might a configured IP disappear after reboot?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Run ip a, ip r, and ss -tulpn on a server and interpret each output.
- 02Identify which tool manages persistent network configuration on your distribution.