SRJahirTech

DevOps Roadmap — Part 4: Linux Networking for DevOps

By Suraj Ahir October 27, 2025 6 min read

DevOps engineers spend a surprising amount of time dealing with networking problems. Services that cannot reach each other, firewalls blocking traffic, DNS resolution failures, ports that should be open but are not — these are daily occurrences. If you do not understand Linux networking, you will not be able to troubleshoot them efficiently. This part gives you the essential networking knowledge every DevOps engineer needs.

Understanding IP Addresses

Every machine connected to a network has an IP address — a unique identifier. There are two types you need to understand: private IP addresses (used inside your network — like 192.168.x.x or 10.x.x.x) and public IP addresses (visible on the internet). On a cloud server, you typically have both. Your instance has a private IP for internal communication and a public IP for internet access.

# Show all network interfaces and their IPs
ip a
ip addr show

# Show just the primary IP
hostname -I

# Show routing table
ip route show

# Check if you have internet access
ping -c 4 8.8.8.8

Ports — Every Service Has an Address

An IP address identifies a machine. A port identifies a specific service on that machine. Think of the IP as a building's street address and the port as a specific apartment number. When you access a website, your browser connects to port 80 (HTTP) or 443 (HTTPS) at the server's IP address. Common port numbers every DevOps engineer must know:

• 22 — SSH (remote server access)
• 80 — HTTP (unencrypted web)
• 443 — HTTPS (encrypted web)
• 3306 — MySQL database
• 5432 — PostgreSQL database
• 6379 — Redis cache
• 27017 — MongoDB database
• 8080, 8443 — Common alternate web ports

# List all listening ports
ss -tuln

# With process names (requires root)
ss -tulnp

# Alternative: netstat
netstat -tuln

# Check if a specific port is open
ss -tuln | grep :80

# Check what process owns a port
sudo lsof -i :80

DNS — Translating Names to IPs

Humans remember names. Machines understand IP addresses. DNS (Domain Name System) is the translator between the two. When you type google.com, your computer queries a DNS server which returns Google's IP address. DNS failures cause complete application outages even when the actual server is perfectly fine — the client simply cannot find it.

# Look up a domain's IP
nslookup google.com
dig google.com

# Check DNS resolution time
dig google.com | grep "Query time"

# See which DNS server is being used
cat /etc/resolv.conf

# Test DNS with a specific server
dig @8.8.8.8 google.com

# Reverse lookup (IP to hostname)
dig -x 8.8.8.8

Firewall — UFW and iptables

A firewall controls which network traffic is allowed in and out of your server. On Ubuntu servers, UFW (Uncomplicated Firewall) is the recommended tool. On other distributions, iptables is the underlying system.

# Check firewall status
sudo ufw status verbose

# Enable firewall
sudo ufw enable

# Allow specific ports
sudo ufw allow 22/tcp    # SSH - ALWAYS allow this before enabling
sudo ufw allow 80/tcp    # HTTP
sudo ufw allow 443/tcp   # HTTPS

# Allow from specific IP only
sudo ufw allow from 192.168.1.100 to any port 22

# Deny a port
sudo ufw deny 3306

# Delete a rule
sudo ufw delete allow 80/tcp

# Reset all rules
sudo ufw reset

SSH — Secure Remote Access

SSH (Secure Shell) is how DevOps engineers connect to remote servers. Understanding SSH configuration and troubleshooting is essential.

# Basic SSH connection
ssh username@server-ip

# SSH with private key file
ssh -i ~/.ssh/mykey.pem ubuntu@server-ip

# SSH with custom port
ssh -p 2222 username@server-ip

# Copy files over SSH
scp localfile.txt username@server-ip:/remote/path/

# SSH tunnel (port forwarding)
ssh -L 5432:localhost:5432 username@server-ip

# Test SSH connection without logging in
ssh -T git@github.com

Network Troubleshooting Workflow

When a network problem occurs, follow this systematic approach:

1. Can you ping the server? (ping server-ip) — If no, it is a network routing or firewall issue
2. Is the port open on the server? (ss -tuln | grep :PORT) — If no, the service is not running
3. Is the firewall blocking it? (sudo ufw status) — If yes, add the allow rule
4. Is DNS resolving correctly? (nslookup domain.com) — If no, check /etc/resolv.conf
5. Can you telnet to the port? (telnet server-ip port) — Tests end-to-end connectivity

# Test if a port is reachable
telnet server-ip 80
nc -zv server-ip 80    # netcat - cleaner output

# Trace network path
traceroute google.com

# Check network interface statistics
ifconfig -a
ip -s link show

In Part 5, we will cover Git and version control — the foundation of all modern DevOps workflows and the starting point of every CI/CD pipeline.

The Continuous Improvement Mindset

DevOps is not a destination but a continuous journey of improvement. The practices covered here — automation, monitoring, infrastructure as code, CI/CD pipelines — are tools in service of a deeper goal: enabling teams to deliver software changes to production quickly, safely, and reliably. The measurement that matters is not which tools you use but how long it takes to go from a committed code change to running in production, and how confident you are in that process. The best DevOps teams measure their deployment frequency, lead time for changes, change failure rate, and mean time to recovery (the DORA metrics), and treat these as engineering objectives to improve over time.

Putting It All Together

Every topic in technology and finance rewards the learner who goes beyond surface understanding to build genuine fluency. Fluency comes from repeated exposure, application in varied contexts, and reflection on what worked and what did not. The concepts discussed here are starting points — each one opens into a deeper field of study that could occupy years of focused learning. The most effective approach is not to try to master everything at once, but to pick the areas most relevant to your current goals, go deep there, and then expand. Depth in a few areas is more valuable than shallow familiarity with many. Build on what you know, stay curious about what you do not, and keep the practice of learning as a consistent daily habit rather than an occasional burst of effort.

The questions that make learning stick: How does this connect to what I already know? Where would I actually use this? What would happen if I tried to explain this to someone who knows nothing about it? What are the edge cases and exceptions? What is still unclear? Asking these questions transforms passive reading into active learning, and active learning is what builds the kind of understanding that is still accessible years later when you need it under real conditions.