Linux Networking Tools
The problem
Configuring and debugging a Linux machine's network connectivity — what's listening, what's reachable, what's blocked — requires command-line tools that expose the OS's networking state directly, rather than relying on a GUI that may not exist on a server.
Why now
Network troubleshooting and tools already introduced the general-purpose diagnostic tools (ping, traceroute, curl); this topic is where those get applied specifically at the Linux OS layer, alongside the permission model that governs who's allowed to open privileged ports or change firewall rules.
Mental model
Every Linux networking tool answers one question about the machine's current network state: ss/netstat asks 'what's listening on which port,' ip asks 'what are my interfaces and addresses,' and firewall tools (ufw, iptables) ask 'what traffic is allowed through at all.' Debugging connectivity is picking the tool that answers the specific question the symptom raises.
Requires
- Network Troubleshooting & ToolsNetworking
This topic applies the general diagnostic method (isolate which layer is failing) to Linux-specific tools; you need that general framework before the specific commands have a purpose to serve.
- Permissions & UsersLinux
Binding to privileged ports and modifying firewall rules require root privileges; understanding the permission model is a prerequisite for understanding why some networking commands need sudo and others don't.
Used in
- Server setup — verifying a service is actually listening on the expected port
- Firewall configuration (ufw, iptables) restricting inbound and outbound traffic
- Diagnosing 'connection refused' versus 'connection timed out' on a real server
- Verifying DNS and routing configuration on a freshly provisioned machine
Projects
- Use ss -tulpn to list every process listening on a network port on your machine and identify what each one is
- Configure a basic firewall rule (ufw or iptables) to block a specific port, then verify the block using curl or nc from another machine
Examples
- ss -tulpn shows that nothing is listening on port 5432, immediately explaining a 'connection refused' error to a database
- A firewall silently dropping packets (rather than rejecting them) produces a timeout, not an immediate refusal — a diagnostic clue in itself
Resources
Mastery checklist
- I can list which processes are listening on which ports using ss or netstat
- I can inspect a machine's network interfaces and IP configuration using ip
- I can configure a basic firewall rule and verify it takes effect
- I can distinguish a connection-refused from a connection-timeout scenario and explain the likely cause of each