RedTeam Nexus Labs
Module 08 · Lesson 05 // Networking in Linux

common diagnostic commands

Networking in Linux · Linux

Freereading · 10 min
On this page
  1. Overview
  2. Learning objectives
  3. Core concept
  4. How it works
  5. Practical example
  6. Cybersecurity relevance
  7. Common mistakes
  8. Key takeaways
  9. Check your understanding
LESSON

Overview

This lesson pulls the Linux networking tools together into a practical diagnostic toolkit — the commands you reach for to answer "what's my config, can I reach it, and where does it break?" It mirrors the networking path's troubleshooting routine, in Linux terms.

Learning objectives

  • Match each diagnostic question to the right Linux command.
  • Apply a stepwise troubleshooting routine.
  • Combine tools to localize a network fault.

Core concept

A core set of Linux networking commands, each answering a specific question:

  • ip addr — what are my interfaces and addresses?
  • ip route — what is my routing / default gateway?
  • ping <host> — is the target reachable (basic connectivity/RTT)?
  • traceroute/tracepath <host> — where along the path does it break?
  • dig/getent hosts <name> — does the name resolve (DNS)?
  • ss -tulpn — what is listening / connected locally?
  • curl -I <url> — does an HTTP service respond (and how)?

How it works

The tools compose into the same layered routine from the networking path, using Linux commands:

  1. Check config: ip addr (address valid?) and ip route (gateway present?).
  2. ping the gateway — is the local network working?
  3. ping an external IP — is routing to the internet working?
  4. Resolve a name (dig/getent) — if IP works but name fails, it is DNS.
  5. traceroute to see where the path breaks; ss/curl to test the specific service.

Each step confirms a layer and narrows the fault.

Practical example

A user cannot load a website. You check: ip addr and ip route look valid; ping 192.168.1.1 (gateway) succeeds; ping 8.8.8.8 (external IP) succeeds; but dig example.com fails to resolve. Conclusion: the network path works and the problem is DNS — so you inspect /etc/resolv.conf and DNS settings rather than cables or routing. The tools localized the fault to name resolution.

Cybersecurity relevance

This toolkit is used constantly in both defense and authorized testing: confirming reachability of a target, mapping paths, checking what a host exposes (ss), and probing services (curl). Correctly interpreting results — distinguishing a blocked port from an unreachable host, or DNS failure from routing failure — is a foundational analytical skill. The same commands that troubleshoot connectivity also underpin enumeration and investigation, making fluency here broadly valuable.

Common mistakes

  • Not working stepwise (config → gateway → external IP → name), leading to scattershot guessing.
  • Skipping the IP-vs-name test, missing that the issue is DNS.
  • Assuming "no ping reply" means down — a host may simply block ICMP (as noted in the networking path).

Key takeaways

  • Match tool to question: ip addr (addresses), ip route (gateway), ping (reachability), traceroute/tracepath (path), dig/getent (DNS), ss (local ports/connections), curl -I (HTTP service).
  • Troubleshoot stepwise — config → gateway → external IP → name → path/service — to localize the failing layer.
  • The same diagnostic toolkit supports defense, enumeration, and investigation; correct interpretation of results is the key skill.

Check your understanding

  • Which command answers "does this name resolve?" versus "is this host reachable?" versus "where does the path break?"
  • Following the stepwise routine, if ping to an external IP works but name resolution fails, what is the fault and where do you look?
FINISH THIS LESSON

Sign in to save your progress.

Previoussockets