Networking for DevOps: What You Actually Need

Why networking comes after Linux

A broken system often looks the same from the outside: the page does not load. The cause could be a wrong DNS record, a closed port, or a crashed app. Networking is how you tell these apart.

You need Linux first because the tools for this step run in a terminal. You need networking before running an app, because a web server setup is mostly ports, DNS and proxied traffic. Later, Docker, cloud networks and Kubernetes all add layers on top of these same ideas.

What to learn, in order

1. IP addresses and ports. An IP address finds the machine. A port finds the program on that machine. Almost every connection problem involves one of these two numbers.
2. Private and public ranges. Learn the three private ranges in RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Addresses in these ranges cannot be reached directly from the internet, which is why databases usually live there.
3. Subnets and CIDR. CIDR is the /24 notation that gives the size of an address block. Learn to read it, because cloud networks and firewall rules use it everywhere.
4. DNS. DNS turns a name like example.com into an IP address. Learn A and CNAME records, and what TTL means (how long an answer may be cached). Use dig to look them up. On Ubuntu it may need sudo apt install bind9-dnsutils.
5. TCP and HTTP. TCP makes the connection. HTTP is the request and response sent over it. Learn the basic HTTP flow and the status code groups: 2xx worked, 4xx is a client problem, 5xx is a server problem. Then read a full exchange with curl -v.
6. TLS at a high level. TLS encrypts traffic and proves a server is who it claims to be. For now, know that it is what makes HTTP into HTTPS. You will set it up at step 5.
7. Listening sockets. A socket is one end of a network connection. ss -tln shows which ports are open and on which address. A service on 127.0.0.1 only accepts connections from its own machine, even if the firewall is open.
8. Firewalls. A firewall decides which traffic may reach a port. Learn ufw, the simple firewall tool on Ubuntu. The same idea returns later as AWS security groups.
9. The path between machines. traceroute shows each network hop on the way to a host. Use it last, since most failures you meet will show up in the earlier checks.

What common connection errors mean

Each error tells you how far the request got, so read it before you change anything. These are the usual meanings, not guarantees.

• Could not resolve host: the name never became an IP address. Check DNS with dig.
• Connection refused: the machine answered, but nothing accepted the connection on that port. The app may be down or using another port. Check with ss -tln on the server.
• Connection timed out: no answer came back at all. A firewall may be dropping the traffic, or the address may be wrong or unreachable.
• HTTP 502: you reached the proxy, but the proxy got no valid response from the app behind it. The app may be down or using another port. Look at the app first.

What to skip for now

• The CCNA and other network certifications.
• Routing protocols such as BGP and OSPF.
• Speed drills for subnet math. Being able to work it out slowly, or use a calculator, is fine.
• Reading raw packets in Wireshark.
• Kubernetes network plugins. You are many steps away from needing them.

Common mistakes

• Treating a timeout and a refused connection as the same thing. They point to different causes. Opening the firewall will not help if the app is down.
• Testing from the wrong machine. curl localhost on the server only proves the app works locally. Test from a second machine too.
• Opening a port to the whole internet to fix a connection problem. Bots scan the internet for open database ports. Allow only the address that needs access.
• Blaming DNS caching too late, or too early. A local cache can hide a change you just made. Use dig @1.1.1.1 example.com to ask a public DNS server directly, then compare the answers.

Your project

Create two virtual machines on the same network. Serve a web page from the first one with python3 -m http.server 8080. Then use ufw so that only the second machine can reach port 8080.

Warning: run sudo ufw allow OpenSSH before sudo ufw enable, or you can lock yourself out of a remote machine.

Now break it on purpose, one fault at a time, and fix each one:

1. Stop the web server, then request the page from the second machine. Note the error.
2. Change the firewall rule so it blocks the second machine. Note how the error differs.
3. Add a wrong entry for the server name to /etc/hosts on the second machine, then remove it. This file overrides DNS on that machine.

Write down each fault, the error it caused, and the command that proved the cause. Add these notes to your runbook, which goes into Git at the next step.