As a DevOps engineer you will spend a lot of time making things talk to each other: a browser to a website, Nginx to a backend, a backend to a database, a container to another container, a Kubernetes pod to an external API, a server in one cloud subnet to a server in another. When one of those conversations fails, someone has to work out why. Usually that someone is you.

You do not need to become a network engineer who configures Cisco routers. You do need enough networking to deploy, secure and troubleshoot applications on your own. That is exactly what these notes teach.

What you will be able to do

How these notes are organised

Each module follows the same pattern: concept → analogy → diagram → real-world example → hands-on lab → troubleshooting → quiz. The coloured boxes mean:

Command blocks look like this. The green $ is the prompt (don't type it), and grey text is sample output. On screen, the Copy button copies only the commands.

$ echo "Hello, network!"
Hello, network!

Contents

Option A: a local virtual machine (free, safest)

1. Install VirtualBox (or VMware Workstation Player / Hyper-V / UTM on Mac).
2. Download the Ubuntu Server 24.04 LTS ISO (22.04 also works).
3. Create a VM: 2 CPU, 2–4 GB RAM, 20 GB disk. Choose the Bridged Adapter network so the VM gets an IP on your home network.
4. During installation, tick Install OpenSSH server.

Option B: a cheap cloud VPS (most realistic)

Any provider works (Hetzner, DigitalOcean, Vultr, Linode, Contabo, AWS Lightsail, an Oracle Cloud free-tier VM and so on). Pick Ubuntu 24.04. A VPS gives you a real public IP, which makes the DNS, HTTPS and firewall labs feel exactly like production.

Install the tools used in these notes

$ sudo apt update
$ sudo apt install -y iproute2 iputils-ping traceroute mtr-tiny dnsutils \
    netcat-openbsd curl wget tcpdump nmap ufw nginx python3 jq
# Docker (official convenience script – fine for a lab machine)
$ curl -fsSL https://get.docker.com | sudo sh
$ sudo usermod -aG docker $USER   # log out and back in afterwards

ShopNow is an imaginary online store at shop.example.com. It has three parts, just like most real web applications:

By the end of these notes you will be able to explain every arrow in this picture, build it on a VPS, move it into Docker and then Kubernetes, place it in a cloud VPC, secure it, and troubleshoot it when it breaks.

1.1 What is a network?

A network is two or more devices (called nodes or hosts) connected so they can exchange data. The connection can be a cable (Ethernet), radio waves (Wi-Fi, 4G/5G) or fibre-optic light. The devices can be laptops, phones, servers, printers, routers, containers, or even virtual machines inside a single physical server.

Types of networks

1.2 Client-server architecture

Almost everything in DevOps follows the client-server model:

• A server is a program that runs continuously and listens on a network address and port, waiting for requests. Examples are Nginx, PostgreSQL and an SSH daemon.
• A client is a program that starts the conversation by sending a request. Examples are a browser, curl, psql and your SSH app.

1.3 IP addresses: IPv4 and IPv6

An IP address (Internet Protocol address) is a number that identifies a device's network interface so that packets can be delivered to it. Every packet carries a source IP (who sent it) and a destination IP (where it's going).

IPv4

IPv4 addresses are 32 bits long, written as four decimal numbers (called octets) separated by dots. Each octet is 8 bits, so it can only be 0 to 255.

4.3 billion addresses sounds like a lot, but the world ran out of fresh IPv4 blocks years ago. That's why we have private addresses + NAT (section 1.4) and IPv6.

IPv6

IPv6 addresses are 128 bits, written as eight groups of four hexadecimal digits separated by colons:

# Full form
2001:0db8:0000:0000:0000:ff00:0042:8329
# Rule 1: drop leading zeros in each group
2001:db8:0:0:0:ff00:42:8329
# Rule 2: replace ONE run of all-zero groups with ::
2001:db8::ff00:42:8329

Special IPv4 addresses every DevOps engineer must know

1.4 Public vs private IP addresses

Public IPs are globally unique and routable on the Internet. They're assigned by ISPs and cloud providers. Private IPs are reserved ranges (defined in RFC 1918) that anyone can reuse inside their own network. Internet routers will not carry them.

So how does a laptop with a private IP open Google? Through NAT (Network Address Translation). Your router swaps your private source IP for its single public IP on the way out, remembers the mapping, and swaps it back when the reply arrives.

1.5 MAC addresses and ARP

A MAC address (Media Access Control) is a 48-bit hardware address burned into each network interface (it can be changed in software). It's written as six hex pairs, e.g. 08:00:27:4e:66:a1. The first three pairs identify the manufacturer.

Before your laptop can send anything to its router, it needs the router's MAC address. It finds it with ARP (Address Resolution Protocol):

1.6 Subnet masks, CIDR and subnetting

Every IP address has two parts: a network part (which "street") and a host part (which "house" on that street). The subnet mask says where the split happens.

CIDR (Classless Inter-Domain Routing) notation is just the short way of writing this: 192.168.1.0/24 means "the network whose first 24 bits are 192.168.1". It's what you'll type in cloud consoles, Docker, Kubernetes and firewall rules.

Subnetting: splitting one network into smaller ones

Why split? So that web servers, application servers and databases can live in separate subnets with different security rules, and so that addresses aren't wasted. Here's 192.168.10.0/24 split into four /26 subnets:

Worked example: the "block size" trick

Question: Which subnet does 192.168.1.130/26 belong to, and what is its usable range?

Check your answer on Linux with ipcalc (installed in the lab below).

1.7 Default gateway and routing basics

When your computer sends a packet, it first asks: "Is the destination in my own subnet?"

• Yes: deliver it directly (using ARP to find the MAC).
• No: send it to the default gateway, the router that is the "door" out of the local network. The router then forwards it hop by hop towards the destination.

A routing table is a list of "destination → next hop" rules. When several rules match, the most specific one (the longest prefix) wins. A route for 10.0.5.0/24 beats 10.0.0.0/16, which beats 0.0.0.0/0 (the default route).

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 ...
    inet 127.0.0.1/8 scope host lo
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... state UP
    link/ether 08:00:27:4e:66:a1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.50/24 brd 192.168.1.255 scope global dynamic enp0s3
    inet6 fe80::a00:27ff:fe4e:66a1/64 scope link

$ ip route
default via 192.168.1.1 dev enp0s3 proto dhcp src 192.168.1.50 metric 100
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.50

$ hostname -I          # all local IPs
192.168.1.50
$ curl -s ifconfig.me ; echo   # the IP the Internet sees
203.0.113.25

$ ping -c 2 192.168.1.1 > /dev/null ; ip neigh
192.168.1.1 dev enp0s3 lladdr aa:bb:cc:dd:ee:01 REACHABLE

$ sudo apt install -y ipcalc
$ ipcalc 192.168.1.130/26
Address:   192.168.1.130
Netmask:   255.255.255.192 = 26
Network:   192.168.1.128/26
HostMin:   192.168.1.129
HostMax:   192.168.1.190
Broadcast: 192.168.1.191
Hosts/Net: 62                    Class C, Private Internet   # (output trimmed)

$ python3 -m http.server 8000 --bind 127.0.0.1   # terminal 1
$ curl -I http://127.0.0.1:8000                   # terminal 2 → works
# From your laptop's browser: http://VM-IP:8000 → fails. Stop it (Ctrl+C) and run:
$ python3 -m http.server 8000 --bind 0.0.0.0
# Now http://VM-IP:8000 works from your laptop

1.8 Troubleshooting scenarios

2.1 Why do we need layers?

Sending data across the world involves many separate problems: turning bits into electrical signals, finding the next device, routing across continents, making delivery reliable, and making sure both apps speak the same language. Instead of one giant program solving all of that, networking splits the work into layers. Each layer does one job and only talks to the layer directly above and below it.

2.2 The OSI model and the TCP/IP model

The OSI model (7 layers) is a teaching and troubleshooting reference. The TCP/IP model (4 layers) is what the Internet actually runs on. You need both: interviews and documentation say "Layer 4 load balancer" or "Layer 7 firewall" using OSI numbers.

2.3 Encapsulation: how data is wrapped for travel

As your data moves down the layers on the sender, each layer adds its own header (an envelope with that layer's information). The receiver unwraps them in reverse order, going up. This is called encapsulation and decapsulation.

2.4 TCP vs UDP

At the Transport layer there are two main protocols. Both use ports, but they behave very differently.

2.5 The TCP three-way handshake

Before any TCP data flows, client and server agree to talk using three messages: SYN → SYN-ACK → ACK.

"Connection refused" vs "connection timed out": the most useful clue in networking

2.6 Ports and sockets

An IP address gets traffic to the right machine. A port (a number from 0 to 65535) gets it to the right program on that machine. A socket is the combination IP:port, for example 203.0.113.10:443.

Ports you should know by heart

2.7 HTTP and HTTPS

HTTP (HyperText Transfer Protocol) is the language of the web and of almost every API. It is plain text: a client sends a request, and the server returns a response. HTTPS is the same HTTP sent inside an encrypted TLS tunnel. Module 5 covers TLS in detail.

GET /api/products?page=2 HTTP/1.1     ← method, path, version
Host: shop.example.com              ← which website
User-Agent: Mozilla/5.0 ...
Accept: application/json
Authorization: Bearer eyJhbGc...
Cookie: session=abc123
                                    ← blank line
(body: empty for GET; JSON for POST)

HTTP/1.1 200 OK                     ← status
Content-Type: application/json
Content-Length: 512
Cache-Control: max-age=60
Server: nginx
                                    ← blank line
{"products":[{"id":7,"name":"Shoes"}]}

2.8 SSH, FTP/SFTP and ICMP

SSH: secure remote access (TCP 22)

SSH (Secure Shell) gives you an encrypted terminal on a remote server. It's the DevOps engineer's front door to every Linux machine. It also carries file transfers (SCP/SFTP) and can create tunnels.

$ ssh ubuntu@203.0.113.10                     # log in
$ ssh -i ~/.ssh/shop_key -p 2222 deploy@203.0.113.10   # custom key and port
$ scp app.tar.gz deploy@203.0.113.10:/opt/shop/        # copy a file up
$ sftp deploy@203.0.113.10                    # interactive file transfer over SSH

$ ssh -N -L 5432:127.0.0.1:5432 deploy@203.0.113.10
# -L localPort:destinationHost:destinationPort  (destination as seen FROM the server)
# -N  don't open a shell, just keep the tunnel
# Now connect pgAdmin/psql on your laptop to localhost:5432

FTP vs SFTP vs SCP

ICMP: the network's messenger (ping and traceroute)

ICMP (Internet Control Message Protocol) is a Layer 3 helper protocol with no ports. It carries error and diagnostic messages such as "echo request/reply" (ping), "destination unreachable" and "time exceeded" (used by traceroute).

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms
$ traceroute -n google.com      # each line = one router hop
$ mtr -rwc 20 google.com        # traceroute + ping combined, with loss % per hop

$ sudo ss -tulnp
Netid State  Local Address:Port  Process
udp   UNCONN 127.0.0.53%lo:53     users:(("systemd-resolve",pid=612))
tcp   LISTEN 0.0.0.0:22           users:(("sshd",pid=901))
tcp   LISTEN 0.0.0.0:80           users:(("nginx",pid=1201))

$ sudo tcpdump -i lo -n tcp port 9000        # terminal 1
$ nc -l 9000                                 # terminal 2 (server)

$ nc 127.0.0.1 9000
hello server!

IP 127.0.0.1.45678 > 127.0.0.1.9000: Flags [S], seq 1234...
IP 127.0.0.1.9000 > 127.0.0.1.45678: Flags [S.], seq 9876..., ack 1235
IP 127.0.0.1.45678 > 127.0.0.1.9000: Flags [.], ack 1
IP 127.0.0.1.45678 > 127.0.0.1.9000: Flags [P.], length 14

$ nc -vz 127.0.0.1 9999          # nothing listening
nc: connect to 127.0.0.1 port 9999 (tcp) failed: Connection refused
$ nc -vz -w 5 10.255.255.1 22    # an IP that doesn't answer
nc: connect to 10.255.255.1 port 22 (tcp) timed out: Operation now in progress

$ nc -u -l 9001                  # UDP server
$ echo "hi" | nc -u -w1 127.0.0.1 9001   # UDP client

$ curl -v https://example.com -o /dev/null
*   Trying 93.184.215.14:443...
* Connected to example.com (93.184.215.14) port 443
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
> GET / HTTP/2
> Host: example.com
< HTTP/2 200
< content-type: text/html
$ curl -I http://example.com     # headers only

2.9 Troubleshooting scenarios

3.1 What is DNS and why does it exist?

Computers connect using IP addresses, but humans remember names. The Domain Name System (DNS) is a huge, distributed database that answers the question "What is the IP address of this name?" (and a few other questions, such as "Which server handles this domain's email?").

Anatomy of a URL and a domain name

Domains form a tree, read from right to left. There is an invisible root . at the very end, so shop.example.com. is the "fully qualified" form.

3.2 How DNS resolution works, step by step

1. Your computer checks its own caches and /etc/hosts. If there's no answer, it asks its configured recursive resolver: "What is shop.example.com?"
2. The resolver (if it has nothing cached) asks a root server.
3. The root replies: "I don't know, but here are the .com TLD servers."
4. The resolver asks a .com TLD server.
5. The TLD server replies: "example.com's authoritative nameservers are ns1.dns-host.net and ns2.dns-host.net."
6. The resolver asks the authoritative nameserver.
7. The authoritative server answers: "shop.example.com A 203.0.113.10, TTL 300."
8. The resolver caches this for 300 seconds and returns it to your computer, which caches it too. Now the browser can open a TCP connection to 203.0.113.10.

3.3 DNS record types

Here is what ShopNow's zone might look like in a DNS provider's dashboard (shown in standard "zone file" format):

; name            TTL    class type   value
example.com.        3600   IN    A      203.0.113.10
www                 3600   IN    CNAME  example.com.
shop                300    IN    A      203.0.113.10
api                 300    IN    A      203.0.113.11
example.com.        3600   IN    MX     10 mail.example.com.
mail                3600   IN    A      203.0.113.20
example.com.        3600   IN    TXT    "v=spf1 ip4:203.0.113.20 include:_spf.google.com ~all"
_dmarc              3600   IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
example.com.        3600   IN    CAA    0 issue "letsencrypt.org"

3.4 TTL, caching and "DNS propagation"

Every record has a TTL (Time To Live) in seconds, which says how long resolvers may cache the answer. Caching makes DNS fast and resilient, but it also means changes aren't instant. Resolvers that cached the old value keep using it until their copy expires. People call this delay "DNS propagation", though really it's just caches expiring.

3.5 Registrar vs nameservers vs DNS hosting

This confuses almost every beginner. Buying a domain and hosting its DNS records can happen at two different companies.

3.6 Reverse DNS (PTR)

Normal ("forward") DNS maps a name to an IP. Reverse DNS maps an IP to a name using PTR records in the special in-addr.arpa zone. The owner of the IP (your VPS or cloud provider) controls it, not your domain's DNS host. You usually set it in the provider's control panel.

3.7 DNS on a Linux server

$ dig github.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4512
;; QUESTION SECTION:
;github.com.                    IN      A
;; ANSWER SECTION:
github.com.             60      IN      A       140.82.121.4
;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

$ dig +short github.com A
$ dig +short google.com AAAA
$ dig +short www.github.com CNAME
$ dig +short gmail.com MX
$ dig +short google.com TXT
$ dig +short github.com NS

$ dig +trace github.com
.                 IN NS  a.root-servers.net.     ← root
com.              IN NS  a.gtld-servers.net.      ← TLD
github.com.       IN NS  dns1.p08.nsone.net.      ← authoritative
github.com.    60 IN A   140.82.121.4             ← final answer   # (output trimmed)

$ dig @1.1.1.1 +short github.com
$ dig @8.8.8.8 +short github.com
$ dig @$(dig +short github.com NS | head -1) +short github.com   # ask the authoritative server directly

$ dig -x 8.8.8.8 +short
dns.google.
$ nslookup github.com 1.1.1.1

$ echo "127.0.0.1 shop.test" | sudo tee -a /etc/hosts
$ getent hosts shop.test        # uses the same order as applications
127.0.0.1       shop.test
$ dig +short shop.test          # empty! dig only asks DNS, it ignores /etc/hosts
$ sudo sed -i '/shop.test/d' /etc/hosts

3.8 Troubleshooting DNS failures

4.1 Network interfaces

An interface is anything that can send and receive packets. Some are physical (a network card) and many are virtual (created by Docker, Kubernetes or VPNs). Each interface can hold one or more IP addresses.

$ ip -br link          # brief: name, state, MAC
lo       UNKNOWN  00:00:00:00:00:00
ens3     UP       52:54:00:ab:cd:ef
docker0  DOWN     02:42:7a:11:22:33
$ ip -br addr          # brief: name, state, IPs
lo       UNKNOWN  127.0.0.1/8 ::1/128
ens3     UP       203.0.113.10/24 2001:db8::10/64
$ ip -s link show ens3 # traffic counters, including errors and drops

4.2 Permanent configuration with Netplan

Ubuntu stores network configuration as YAML in /etc/netplan/*.yaml. Here's a static IP for a lab VM:

network:
  version: 2
  ethernets:
    enp0s3:
      dhcp4: false
      addresses: [192.168.1.50/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

$ sudo chmod 600 /etc/netplan/01-static.yaml
$ sudo netplan try      # applies it, and auto-reverts after 120 s unless you press Enter
$ sudo netplan apply    # apply permanently

Important network files

4.3 Routing tables

$ ip route
default via 203.0.113.1 dev ens3 proto static            ← everything else → ISP gateway
10.0.1.0/24 dev ens4 proto kernel scope link src 10.0.1.10  ← private subnet, directly attached
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
203.0.113.0/24 dev ens3 proto kernel scope link src 203.0.113.10
$ ip route get 10.0.2.15      # "which route would be used to reach this IP?"
10.0.2.15 via 203.0.113.1 dev ens3 src 203.0.113.10   # ← oops: going out the public NIC!

In the output above, traffic to 10.0.2.15 (another private subnet) would leave through the public interface, which is wrong. You'd fix it by adding a route through the private network's router:

$ sudo ip route add 10.0.2.0/24 via 10.0.1.1 dev ens4    # temporary
# permanent: add under ens4 in netplan →  routes: [{to: 10.0.2.0/24, via: 10.0.1.1}]

4.4 Listening ports and running services

$ sudo ss -tulnp
Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=1201,fd=6))
tcp   LISTEN 0      4096         0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=901,fd=3))
tcp   LISTEN 0      511        127.0.0.1:5000       0.0.0.0:*     users:(("node",pid=2210,fd=19))
tcp   LISTEN 0      244        127.0.0.1:5432       0.0.0.0:*     users:(("postgres",pid=845,fd=7))
tcp   LISTEN 0      511             [::]:80            [::]:*     users:(("nginx",pid=1201,fd=7))

$ sudo ss -tnp state established        # current live connections
$ sudo ss -tn state time-wait | wc -l   # how many connections are closing
$ sudo lsof -i :443                     # who uses port 443
$ systemctl status nginx                # is the service running?
$ journalctl -u nginx --since "10 min ago"   # its recent logs
$ curl -sI http://127.0.0.1:5000/health # does it answer locally?

4.5 Firewalls: UFW, nftables and iptables

The Linux kernel's built-in packet filter is called netfilter. You configure it with a tool: nftables (nft, the modern one), iptables (legacy syntax, which on Ubuntu 22.04+ runs on top of nftables), or UFW ("Uncomplicated Firewall"), a friendly front-end that writes the rules for you.

UFW: the everyday choice on Ubuntu

$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing
$ sudo ufw allow OpenSSH                 # ① ALWAYS FIRST on a remote server!
$ sudo ufw allow 80,443/tcp              # web
$ sudo ufw allow from 10.0.1.0/24 to any port 5432 proto tcp   # DB only from app subnet
$ sudo ufw limit OpenSSH                 # rate-limit brute-force attempts
$ sudo ufw enable
$ sudo ufw status numbered
     To                         Action      From
     --                         ------      ----
[ 1] OpenSSH                    LIMIT IN    Anywhere
[ 2] 80,443/tcp                 ALLOW IN    Anywhere
[ 3] 5432/tcp                   ALLOW IN    10.0.1.0/24
$ sudo ufw delete 3                      # remove a rule by number

nftables and iptables (good to recognise)

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport { 22, 80, 443 } accept
    ip saddr 10.0.1.0/24 tcp dport 5432 accept
    icmp type echo-request accept
  }
}

# list rules with packet counters
sudo iptables -L -n -v --line-numbers
# allow established + SSH + web, drop rest
sudo iptables -A INPUT -m conntrack \
  --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -m multiport \
  --dports 80,443 -j ACCEPT
sudo iptables -P INPUT DROP

4.6 Troubleshooting connectivity, latency and packet loss

Work bottom-up: there's no point debugging Nginx if the server has no route to the Internet. Each step only makes sense once the step below it passes.

$ ping -c 20 203.0.113.10        # look at "% packet loss" and avg/mdev (jitter)
$ mtr -rwbzc 50 shop.example.com
HOST                          Loss%  Snt  Last   Avg  Best  Wrst StDev
  1. 192.168.1.1               0.0%   50   1.1   1.3   0.9   3.2   0.4
  2. 10.20.0.1                 0.0%   50   8.2   8.9   7.6  15.1   1.4
  3. ae-1.isp-core.net        40.0%   50  12.1  12.4  11.8  14.0   0.5   ← loss only here?
  4. 203.0.113.1               0.0%   50  21.3  21.8  20.9  25.2   0.8
  5. 203.0.113.10              0.0%   50  22.0  22.4  21.5  26.0   0.9   ← final hop: 0% → fine

4.7 The Linux networking command toolkit

$ sudo systemctl start nginx                                  # "web" on 80
$ nohup python3 -m http.server 8080 --bind 0.0.0.0 &          # "admin panel" on 8080
$ nohup python3 -m http.server 9000 --bind 127.0.0.1 &        # "internal API" on 9000
$ sudo ss -tlnp | grep -E ':(22|80|8080|9000)\b'

$ nc -vz SERVER-IP 80      # succeeded
$ nc -vz SERVER-IP 8080    # succeeded  ← an admin panel open to the world!
$ nc -vz SERVER-IP 9000    # refused    ← bound to 127.0.0.1, good

$ sudo ufw default deny incoming && sudo ufw default allow outgoing
$ sudo ufw allow OpenSSH
$ sudo ufw allow 80/tcp
$ sudo ufw allow from YOUR-LAPTOP-IP to any port 8080 proto tcp
$ sudo ufw enable && sudo ufw status numbered

$ nc -vz -w 5 SERVER-IP 8080    # laptop: succeeds · other network: times out

$ sudo ufw logging on ; sudo tail -f /var/log/ufw.log    # look for [UFW BLOCK]
$ pkill -f http.server

4.8 Troubleshooting scenarios

5.1 What is a reverse proxy?

A reverse proxy is a server that sits in front of your applications and receives every client request on their behalf. It then forwards each request to the right backend ("upstream") and passes the answer back. Clients only ever see the proxy.

5.2 An Nginx reverse proxy for ShopNow

upstream shop_api {
    server 127.0.0.1:5000;
    keepalive 32;                          # reuse connections to the backend
}

server {                                   # ① plain HTTP: only redirect
    listen 80;
    listen [::]:80;
    server_name shop.example.com;
    return 301 https://$host$request_uri;
}

server {                                   # ② HTTPS
    listen 443 ssl http2;                  # on nginx ≥ 1.25: "listen 443 ssl;" + "http2 on;"
    listen [::]:443 ssl http2;
    server_name shop.example.com;

    ssl_certificate     /etc/letsencrypt/live/shop.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/shop.example.com/privkey.pem;

    root  /var/www/shop;                   # React build output
    index index.html;

    location / {
        try_files $uri /index.html;        # single-page-app routing
    }

    location /api/ {
        proxy_pass http://shop_api;        # no trailing slash → backend receives /api/...
        proxy_http_version 1.1;
        proxy_set_header Connection        "";
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;          # can't connect in 5 s → 502/504
        proxy_read_timeout    60s;         # backend silent for 60 s → 504
        client_max_body_size  10m;         # bigger uploads → 413
    }
}

$ sudo ln -s /etc/nginx/sites-available/shopnow /etc/nginx/sites-enabled/
$ sudo nginx -t                 # ALWAYS test the syntax first
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl reload nginx   # reload = no dropped connections (restart drops them)

5.3 HTTP headers and request forwarding

When Nginx forwards a request, the backend sees a TCP connection from Nginx (127.0.0.1), not from the user. Without extra headers, your app logs every visitor as 127.0.0.1, rate limiting breaks, and the app thinks every request was plain HTTP.

5.4 Load balancing

When one backend isn't enough, or you need no downtime when a server fails, run several copies and let the proxy spread requests across them.

upstream shop_api {
    least_conn;
    server 10.0.11.21:5000 max_fails=3 fail_timeout=30s;   # 3 failures → skip it for 30 s
    server 10.0.11.22:5000 max_fails=3 fail_timeout=30s;
    server 10.0.11.23:5000 backup;                          # only used if the others are down
    keepalive 32;
}

5.5 Upstream services and health checks

• Passive checks (open-source Nginx): mark a backend "down" after real requests to it fail (max_fails/fail_timeout).
• Active checks (HAProxy, NGINX Plus, cloud LBs, Kubernetes probes): the balancer calls GET /health every few seconds, even with no user traffic.

frontend web
    bind *:80
    default_backend shop_api

backend shop_api
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    server api1 10.0.11.21:5000 check inter 5s fall 3 rise 2
    server api2 10.0.11.22:5000 check inter 5s fall 3 rise 2

5.6 TLS/SSL certificates and HTTPS

TLS (Transport Layer Security; "SSL" is its outdated name) gives three guarantees:

Free certificates with Let's Encrypt + Certbot

$ sudo apt install -y certbot python3-certbot-nginx
$ sudo certbot --nginx -d shop.example.com -d www.shop.example.com
# Certbot proves you control the domain (HTTP-01 challenge on port 80),
# installs the cert in your nginx config and adds the HTTP→HTTPS redirect.
$ sudo certbot renew --dry-run          # test auto-renewal
$ systemctl list-timers | grep certbot  # the renewal timer runs twice a day

$ echo | openssl s_client -connect shop.example.com:443 -servername shop.example.com 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates
subject=CN = shop.example.com
issuer=C = US, O = Let's Encrypt, CN = R11
notBefore=Oct  1 10:00:00 2026 GMT
notAfter=Dec 30 10:00:00 2026 GMT

5.7 Ports 80 and 443

Add HSTS (add_header Strict-Transport-Security "max-age=31536000" always;) once HTTPS works well. It tells browsers to always use HTTPS for your domain.

5.8 WebSockets and persistent connections

Normal HTTP is request → response → done. Chat, live dashboards, notifications and multiplayer games need the server to push data at any time. WebSockets start as an HTTP request with Upgrade: websocket, then turn the TCP connection into a long-lived, two-way channel.

location /ws/ {
    proxy_pass http://127.0.0.1:6000;
    proxy_http_version 1.1;                    # required: WebSocket upgrade needs HTTP/1.1
    proxy_set_header Upgrade    $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host       $host;
    proxy_read_timeout 1h;                     # default 60 s would cut idle sockets
}

$ mkdir -p ~/b1 ~/b2 && echo "backend 1" > ~/b1/index.html && echo "backend 2" > ~/b2/index.html
$ (cd ~/b1 && nohup python3 -m http.server 5001 --bind 127.0.0.1 >/dev/null 2>&1 &)
$ (cd ~/b2 && nohup python3 -m http.server 5002 --bind 127.0.0.1 >/dev/null 2>&1 &)
$ curl 127.0.0.1:5001 ; curl 127.0.0.1:5002

$ sudo tee /etc/nginx/sites-available/lab >/dev/null <<'EOF'
upstream lab_backends {
    server 127.0.0.1:5001 max_fails=1 fail_timeout=10s;
    server 127.0.0.1:5002 max_fails=1 fail_timeout=10s;
}
server {
    listen 80 default_server;
    server_name _;
    location / {
        proxy_pass http://lab_backends;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 5s;
    }
    location /slow/ {
        proxy_pass http://127.0.0.1:5003;
        proxy_read_timeout 5s;
    }
}
EOF
$ sudo rm -f /etc/nginx/sites-enabled/default
$ sudo ln -sf /etc/nginx/sites-available/lab /etc/nginx/sites-enabled/lab
$ sudo nginx -t && sudo systemctl reload nginx

$ for i in 1 2 3 4; do curl -s localhost; done
backend 1
backend 2
backend 1
backend 2

$ pkill -f "http.server 5001" ; for i in 1 2 3; do curl -s localhost; done   # all "backend 2"
$ pkill -f "http.server 5002" ; curl -sI localhost | head -1
HTTP/1.1 502 Bad Gateway
$ sudo tail -n 2 /var/log/nginx/error.log
... connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://127.0.0.1:5002/"

$ nohup nc -lk 127.0.0.1 5003 >/dev/null 2>&1 &
$ time curl -sI localhost/slow/ | head -1
HTTP/1.1 504 Gateway Time-out
real    0m5.0s
$ sudo tail -n 1 /var/log/nginx/error.log      # "upstream timed out (110: Connection timed out)"
$ pkill -f "nc -lk"

$ sudo ufw allow 80,443/tcp
$ sudo sed -i 's/server_name _;/server_name lab.yourdomain.com;/' /etc/nginx/sites-available/lab
$ sudo nginx -t && sudo systemctl reload nginx
$ sudo certbot --nginx -d lab.yourdomain.com
$ curl -I https://lab.yourdomain.com

$ sudo openssl req -x509 -nodes -days 30 -newkey rsa:2048 \
    -keyout /etc/ssl/private/lab.key -out /etc/ssl/certs/lab.crt -subj "/CN=lab.local"
# add to the server block:  listen 443 ssl;  ssl_certificate /etc/ssl/certs/lab.crt;
#                           ssl_certificate_key /etc/ssl/private/lab.key;
$ sudo nginx -t && sudo systemctl reload nginx
$ curl -kI https://localhost       # -k = accept the untrusted self-signed cert

5.9 Troubleshooting scenarios

6.1 How container networking works

Every container gets its own network namespace: its own interfaces, IP address, routing table and port numbers. Two containers can both listen on port 80 without clashing. By default Docker connects containers to a virtual switch on the host called a bridge (docker0), using a virtual cable (veth pair) for each one.

6.2 Network drivers: bridge, host, none, overlay

6.3 Container IP addresses

$ docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' web
172.18.0.2
$ docker network inspect shopnet | jq '.[0].IPAM.Config, .[0].Containers'

6.4 Port publishing and port mapping

Containers on a bridge are private to the host. To let the outside world in, publish a port with -p HOST_PORT:CONTAINER_PORT.

6.5 Container-to-container communication and Docker DNS

On a user-defined network, Docker runs an embedded DNS server at 127.0.0.11 inside each container. Every container can reach every other container on the same network by its container name, its Compose service name or a network alias.

$ docker network create shopnet
$ docker run -d --name db  --network shopnet -e POSTGRES_PASSWORD=secret postgres:16-alpine
$ docker run -d --name api --network shopnet -e DATABASE_HOST=db myshop/api:1.0
# inside "api", the hostname "db" resolves to the db container's current IP
$ docker exec api getent hosts db
172.18.0.2      db

6.6 Isolated networks

Containers can only talk to containers that share a network with them. Use that to build zones, just like subnets in Module 1. A network created with --internal has no route to the outside world at all, which is perfect for databases.

$ docker network create frontend
$ docker network create --internal backend      # no Internet in or out
$ docker network connect backend api            # a container can join several networks

6.7 Docker Compose networking: ShopNow in containers

Compose creates a network for each project automatically (named <project>_default), and every service can reach the others by service name. For production you'll usually define networks explicitly:

services:
  nginx:
    image: nginx:1.27-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro   # proxy_pass http://api:5000;
    depends_on: [api]
    networks: [frontend]

  api:
    build: ./api
    environment:
      DATABASE_URL: postgres://shop:${DB_PASSWORD}@db:5432/shop   # service name, not localhost!
    expose: ["5000"]                  # documentation; NOT published to the host
    networks: [frontend, backend]

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: shop
      POSTGRES_PASSWORD: ${DB_PASSWORD}     # from .env, never committed
      POSTGRES_DB: shop
    volumes: [dbdata:/var/lib/postgresql/data]
    networks: [backend]                # no "ports:" → unreachable from outside

networks:
  frontend: {}
  backend:
    internal: true

volumes:
  dbdata: {}

{
  "bip": "10.199.0.1/24",
  "default-address-pools": [ { "base": "10.200.0.0/16", "size": 24 } ]
}

6.8 Overlay networks (multi-host)

When containers run on several hosts, a bridge isn't enough because it only exists on one machine. Overlay networks tunnel container traffic between hosts (using VXLAN over UDP 4789), so containers on different servers share one virtual network. Docker Swarm uses overlays; Kubernetes solves the same problem with CNI plugins (next module).

$ docker network ls
$ docker run -d --name a1 nginx:alpine
$ docker run --rm alpine ping -c1 a1
ping: bad address 'a1'

$ docker network create labnet
$ docker run -d --name web --network labnet nginx:alpine
$ docker run --rm --network labnet alpine sh -c "cat /etc/resolv.conf; ping -c1 web; wget -qO- http://web | head -4"
nameserver 127.0.0.11
64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.09 ms
<!DOCTYPE html>
<html>

$ docker run -d --name pub  -p 8080:80 nginx:alpine
$ docker run -d --name priv -p 127.0.0.1:8081:80 nginx:alpine
$ docker port pub ; sudo ss -tlnp | grep -E '808[01]'
80/tcp -> 0.0.0.0:8080
LISTEN 0.0.0.0:8080 ...  docker-proxy
LISTEN 127.0.0.1:8081 ... docker-proxy
$ sudo iptables -t nat -L DOCKER -n | grep -E '808[01]'
DNAT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.3:80
DNAT  tcp  --  0.0.0.0/0  127.0.0.1  tcp dpt:8081 to:172.17.0.4:80

$ docker network create --internal vault
$ docker run --rm --network vault alpine ping -c1 -W2 1.1.1.1
ping: sendto: Network unreachable

$ mkdir -p ~/lab6 && cd ~/lab6
$ cat > default.conf <<'EOF'
server {
  listen 80;
  location / {
    proxy_pass http://api:80;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}
EOF
$ cat > compose.yaml <<'EOF'
services:
  proxy:
    image: nginx:alpine
    ports: ["8088:80"]
    volumes: ["./default.conf:/etc/nginx/conf.d/default.conf:ro"]
    networks: [frontend]
  api:
    image: traefik/whoami          # tiny app that echoes request + its IPs
    networks: [frontend, backend]
  db:
    image: postgres:16-alpine
    environment: { POSTGRES_PASSWORD: labpass }
    networks: [backend]
networks:
  frontend: {}
  backend: { internal: true }
EOF
$ docker compose up -d && docker compose ps

$ curl -s localhost:8088 | grep -E 'Hostname|IP|X-Forwarded'
Hostname: 3f2a9c1d7b20
IP: 172.20.0.3
IP: 172.21.0.2                 ← the api has one IP per network
X-Forwarded-For: 172.20.0.1
$ docker compose exec proxy ping -c1 -W2 db     # fails: proxy is not on "backend"
ping: bad address 'db'
$ docker run --rm --network lab6_backend postgres:16-alpine pg_isready -h db
db:5432 - accepting connections
$ docker compose down ; docker rm -f a1 web pub priv ; docker network rm labnet vault

6.9 Troubleshooting scenarios

7.1 The Kubernetes networking model

Kubernetes sets three simple rules, and a CNI plugin makes them true:

7.2 Services: stable addresses for moving pods

Pods are temporary. A new deployment, a crash or a node failure replaces them, and they come back with new IPs. So you never connect to pod IPs. Instead you create a Service: a stable virtual IP and DNS name that load-balances across all pods matching a label selector.

apiVersion: apps/v1
kind: Deployment
metadata: { name: api, namespace: shop }
spec:
  replicas: 3
  selector: { matchLabels: { app: api } }
  template:
    metadata: { labels: { app: api } }          # ← label on the pods
    spec:
      containers:
        - name: api
          image: myshop/api:1.4
          ports: [{ containerPort: 5000 }]
          readinessProbe:                       # only "ready" pods receive traffic
            httpGet: { path: /health, port: 5000 }
---
apiVersion: v1
kind: Service
metadata: { name: api, namespace: shop }
spec:
  type: ClusterIP                               # the default
  selector: { app: api }                       # ← must match the pod labels!
  ports:
    - port: 80            # the Service's port (what clients call)
      targetPort: 5000    # the container's port

Now any pod can call http://api.shop (port 80), and Kubernetes forwards it to one of the three ready pods on port 5000. The component that programs this forwarding on every node is kube-proxy (using iptables or IPVS rules), or the CNI itself with eBPF (Cilium).

Service types

7.3 Ingress and the Gateway API

One LoadBalancer per app gets expensive and messy. For HTTP(S), use a single entry point that routes by hostname and path, exactly like the Nginx reverse proxy in Module 5, but configured with Kubernetes objects.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop
  namespace: shop
spec:
  ingressClassName: traefik
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service: { name: api, port: { number: 80 } }
          - path: /
            pathType: Prefix
            backend:
              service: { name: frontend, port: { number: 80 } }

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
    - name: public-gateway     # owned by the platform team
      namespace: infra
  hostnames: [shop.example.com]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /api }
      backendRefs:
        - name: api
          port: 80
    - backendRefs:
        - name: frontend
          port: 80

7.4 Cluster DNS (CoreDNS)

Every cluster runs CoreDNS, and every pod's /etc/resolv.conf points at it. Services automatically get DNS names:

$ cat /etc/resolv.conf
search shop.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.43.0.10          ← the CoreDNS Service (k3s default)
options ndots:5

7.5 Network policies

By default, every pod can talk to every other pod in the cluster, across all namespaces. A NetworkPolicy is a firewall for pods: once a pod is selected by any policy, only the traffic you explicitly allow gets through.

# 1) Deny all incoming traffic to every pod in the namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: shop }
spec:
  podSelector: {}               # {} = all pods
  policyTypes: [Ingress]
---
# 2) Allow only api pods to reach db pods on 5432
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: db-allow-api, namespace: shop }
spec:
  podSelector: { matchLabels: { app: db } }
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: { matchLabels: { app: api } }
      ports:
        - { protocol: TCP, port: 5432 }

7.6 CNI plugins

The Container Network Interface (CNI) is the plug-in standard that gives pods their network. Kubernetes itself doesn't implement pod networking; the CNI does.

7.7 Communication between pods and external services

• Pod → Internet (egress): the node SNATs pod traffic to its own IP (or a NAT gateway in the cloud does). External firewalls see the node/NAT IP, so allowlist that IP with partners.
• Pod → managed database (e.g. RDS): connect by its DNS name. Optionally wrap it in an ExternalName Service so apps use db.shop everywhere.
• Internet → pod: only through a LoadBalancer Service or an Ingress/Gateway. Never expose pods directly.
• Your laptop → a pod (debugging): kubectl port-forward svc/api 8080:80, which is the Kubernetes version of an SSH tunnel.

$ curl -sfL https://get.k3s.io | sh -
$ sudo k3s kubectl get nodes -o wide
$ mkdir -p ~/.kube && sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config && sudo chown $USER ~/.kube/config
$ kubectl get pods -A          # coredns, traefik, local-path, metrics-server…

$ kubectl create namespace shop
$ kubectl -n shop create deployment web --image=traefik/whoami --replicas=3
$ kubectl -n shop expose deployment web --port=80 --target-port=80
$ kubectl -n shop get pods -o wide ; kubectl -n shop get svc,endpointslices

$ kubectl -n shop run tmp --rm -it --image=nicolaka/netshoot -- bash
# inside the pod:
tmp# cat /etc/resolv.conf
tmp# dig +short web.shop.svc.cluster.local
tmp# for i in 1 2 3 4 5 6; do curl -s web | grep Hostname; done   # different pods answer
tmp# exit

$ kubectl -n shop expose deployment web --name=web-np --type=NodePort --port=80
$ kubectl -n shop get svc web-np          # e.g. 80:31234/TCP
$ curl -s http://NODE-IP:31234 | head -3
$ kubectl -n shop create ingress web --class=traefik --rule="shop.local/*=web:80"
$ curl -s -H "Host: shop.local" http://NODE-IP/ | head -3

$ cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: shop }
spec: { podSelector: {}, policyTypes: [Ingress] }
EOF
$ kubectl -n shop run tmp --rm -it --image=nicolaka/netshoot -- curl -s -m 3 web || echo BLOCKED
BLOCKED

$ cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: web-allow-clients, namespace: shop }
spec:
  podSelector: { matchLabels: { app: web } }
  ingress:
    - from: [ { podSelector: { matchLabels: { role: client } } } ]
      ports: [ { protocol: TCP, port: 80 } ]
EOF
$ kubectl -n shop run ok --rm -it --labels=role=client --image=nicolaka/netshoot -- curl -s -m 3 web | head -2
$ kubectl delete namespace shop          # clean up

7.8 Troubleshooting scenarios

8.1 Virtual Private Cloud (VPC) and subnets

A VPC is your own isolated, private network inside a cloud provider. Think of it as a virtual data centre network. You choose its CIDR (e.g. 10.0.0.0/16) and carve it into subnets, each living in one Availability Zone (AZ), which is a physically separate data centre within a region.

8.2 Route tables and internet gateways

Every subnet is associated with a route table, exactly like ip route on Linux. What makes a subnet "public" is one thing only: its route table sends 0.0.0.0/0 to an Internet Gateway (IGW). Instances there also need a public IP to be reachable.

A data subnet often has only the local route, so it has no path to the Internet at all. The local route is automatic and means every subnet in the VPC can route to every other subnet. Firewalls (next section) decide what's actually allowed.

8.3 NAT and NAT gateways

Private servers still need outbound Internet access for OS updates, Docker image pulls and calls to payment APIs, but nothing on the Internet should be able to start a connection to them. A NAT Gateway sits in a public subnet, swaps the private source IP for its own public IP (just like your home router in Module 1) and lets only the replies back in.

8.4 Security groups and network ACLs

Security groups that reference each other

Instead of IPs, an SG rule can say "allow from members of another SG". IPs change as instances scale; group membership doesn't.

8.5 VPNs and private connectivity

8.6 High availability and load balancers

• Spread across at least 2 AZs: load balancer nodes, app instances (an auto-scaling group), NAT gateways and a database standby.
• The load balancer health-checks targets (like Module 5) and only sends traffic to healthy ones. If an entire AZ fails, it keeps serving from the other.
• L7 (ALB / Application Gateway / HTTP LB): HTTPS termination with managed certificates, path/host routing, WAF integration. L4 (NLB): TCP/UDP, static IPs, extreme throughput, client IP preserved.
• DNS points at the LB's hostname (an ALIAS record at the apex, as in Module 3), never at an individual server.

8.7 Private database access and network segmentation

$ aws ssm start-session --target i-0abc123def4567890 \
    --document-name AWS-StartPortForwardingSessionToRemoteHost \
    --parameters '{"host":["shop-db.xxxx.eu-central-1.rds.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["15432"]}'
# then: psql -h localhost -p 15432 -U shop shop

8.8 Doing it without a hyperscaler

The same design works on a simple VPS provider. Most offer private networks (Hetzner vSwitch/Networks, DigitalOcean VPC, Linode VLAN), cloud firewalls (filtered before traffic reaches the VPS, so they also cover the Docker/UFW gap) and load balancers. A typical small production setup: 1 load balancer + 2 app VPSs + 1 DB VPS on a private network, with only the LB public.

8.9 Concept mapping: AWS · Azure · GCP

$ aws ec2 describe-vpcs --query 'Vpcs[].{id:VpcId,cidr:CidrBlock}' --output table
$ aws ec2 describe-subnets --filters Name=vpc-id,Values=vpc-XXXX \
    --query 'Subnets[].{az:AvailabilityZone,cidr:CidrBlock,publicIp:MapPublicIpOnLaunch}' --output table
$ aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-XXXX \
    --query 'RouteTables[].Routes[].{dest:DestinationCidrBlock,gw:GatewayId,nat:NatGatewayId}' --output table

8.10 Troubleshooting scenarios

9.1 Firewall rules and least-privilege access

Least privilege means every user, server and service gets only the access it needs, and nothing more. For networks that means: deny by default, then open the fewest ports, to the fewest sources, for the shortest time.

$ sudo ss -tulnp | grep -v '127.0.0.1\|::1'     # what listens on non-loopback addresses
$ sudo ufw status verbose
$ docker ps --format '{{.Names}}\t{{.Ports}}'      # remember: published ports bypass UFW
$ nmap -Pn -p- --min-rate 1000 YOUR-SERVER-IP     # run from OUTSIDE, only on servers you own

9.2 TLS certificates and encryption

• Public traffic: HTTPS only, TLS 1.2 and 1.3 (disable 1.0/1.1), HTTP→HTTPS redirect, HSTS. Test with SSL Labs or testssl.sh.
• Internal traffic: "it's on a private network" is not encryption. Use TLS to databases (sslmode=require / verify-full for PostgreSQL), to Redis and to internal APIs, especially across VPCs or data centres.
• Service-to-service: mTLS (mutual TLS: both sides present certificates) proves identity in both directions. Service meshes (Istio, Linkerd, Cilium) automate it in Kubernetes.
• Certificate lifecycle: automate issuance and renewal (certbot, cert-manager), and alert 14+ days before expiry.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

9.3 SSH keys and secure remote access

$ ssh-keygen -t ed25519 -C "you@laptop"          # creates id_ed25519 + id_ed25519.pub
$ ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10
$ ssh deploy@203.0.113.10                        # should log in without a password

Host shop-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
Host shop-db
    HostName 10.0.21.15
    User deploy
    ProxyJump shop-prod          # reach the private host through the public one
# now just:  ssh shop-prod   /   ssh shop-db   /   scp file shop-prod:/tmp/

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no                 # or prohibit-password if root must use keys
PubkeyAuthentication yes
AllowUsers deploy                   # only these users may log in
MaxAuthTries 3

$ sudo sshd -t && sudo systemctl reload ssh     # test the config, then reload
# KEEP your current session open and test a NEW login in another terminal before logging out!
$ sudo apt install -y fail2ban                   # bans IPs with repeated failed logins
$ sudo fail2ban-client status sshd

9.4 Network segmentation

Segmentation splits a network into zones with controlled crossings, so a compromised web server can't directly reach the database, the CI server or the office laptops. You've already seen it at every level:

9.5 VPNs and zero-trust principles

Zero trust principles: never trust, always verify; least-privilege access per application; assume breach (segment and log everything); strong identity (SSO + MFA) and device checks. Tools include Cloudflare Access, Tailscale ACLs, Teleport, Google BeyondCorp/IAP, and service-mesh mTLS inside clusters. A VPN is still useful, but as one layer, not the whole strategy.

A minimal WireGuard VPN

[Interface]
Address    = 10.8.0.1/24
ListenPort = 51820              # UDP!
PrivateKey = <server-private-key>

[Peer]                          # your laptop
PublicKey  = <laptop-public-key>
AllowedIPs = 10.8.0.2/32

[Interface]
Address    = 10.8.0.2/24
PrivateKey = <laptop-private-key>

[Peer]                          # the server
PublicKey  = <server-public-key>
Endpoint   = 203.0.113.10:51820
AllowedIPs = 10.8.0.0/24        # only VPN traffic goes through the tunnel
PersistentKeepalive = 25

$ sudo apt install -y wireguard
$ wg genkey | tee server.key | wg pubkey > server.pub      # keep *.key files secret, chmod 600
$ sudo ufw allow 51820/udp
$ sudo systemctl enable --now wg-quick@wg0 ; sudo wg show
# Now restrict admin ports to the VPN:  sudo ufw allow from 10.8.0.0/24 to any port 22 proto tcp

9.6 Packet capture with tcpdump and Wireshark

When logs aren't enough, look at the actual packets. tcpdump captures on servers (CLI); Wireshark analyses captures with a GUI on your laptop. Together they answer "did the packet even arrive?", which is the ultimate ground truth.

$ scp shop-prod:/tmp/cap.pcap .
# Wireshark display filters: tcp.flags.reset==1 · dns · http.response.code >= 500 · tcp.analysis.retransmission

9.7 Monitoring latency, traffic and connection errors

Watch the four golden signals for every service: Latency (how long requests take; track p95/p99, not just the average), Traffic (requests/s, bandwidth), Errors (5xx rate, connection failures, timeouts) and Saturation (CPU, connections, bandwidth limits).

Where does the time go? Break down one request

$ curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total} code:%{http_code}\n' https://shop.example.com/api/products
dns:0.020 connect:0.055 tls:0.115 ttfb:0.295 total:0.310 code:200

Monitoring stack and alerts

$ ss -s                                     # summary: established, time-wait, orphaned…
$ nstat -az | grep -Ei 'retrans|resets|listendrops'   # TCP retransmissions = packet loss/congestion
$ ip -s link show ens3                      # RX/TX errors and drops on the NIC
$ awk '$9 ~ /^5/' /var/log/nginx/access.log | tail     # recent 5xx responses
$ awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn   # status code counts

laptop$ ssh-keygen -t ed25519 ; ssh-copy-id user@VM-IP ; ssh user@VM-IP
vm$ echo -e "PasswordAuthentication no\nKbdInteractiveAuthentication no\nPermitRootLogin no" | sudo tee /etc/ssh/sshd_config.d/99-hardening.conf
vm$ sudo sshd -t && sudo systemctl reload ssh
laptop$ ssh -o PubkeyAuthentication=no user@VM-IP
user@VM-IP: Permission denied (publickey).        ← passwords are now refused ✔

$ sudo journalctl -u ssh --since today | grep -Ei 'invalid user|failed' | tail
$ sudo apt install -y fail2ban && sudo systemctl enable --now fail2ban
$ sudo fail2ban-client status sshd

$ sudo tcpdump -i any -n port 53 -c 4 &
$ dig +short example.org @1.1.1.1
IP 192.168.1.50.41234 > 1.1.1.1.53: 12345+ [1au] A? example.org. (40)
IP 1.1.1.1.53 > 192.168.1.50.41234: 12345 1/0/1 A 93.184.215.14 (56)
$ sudo tcpdump -i any -nn -A -c 20 port 80 &
$ curl -s http://example.org > /dev/null     # you'll see "GET / HTTP/1.1" and "Host: example.org" in clear text

$ sudo tcpdump -i any -w /tmp/lab9.pcap -c 200 'port 443 or port 53' &
$ curl -s https://example.org > /dev/null
laptop$ scp user@VM-IP:/tmp/lab9.pcap .     # open it, filter "tls.handshake" and find the SNI

$ for u in https://example.org https://github.com https://www.google.com; do
    curl -o /dev/null -s -w "$u dns:%{time_namelookup} conn:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" $u; done

$ docker run -d --name kuma -p 127.0.0.1:3001:3001 -v kuma:/app/data louislam/uptime-kuma:1
laptop$ ssh -N -L 3001:127.0.0.1:3001 user@VM-IP     # then browse http://localhost:3001

9.8 Troubleshooting scenarios

A customer opens https://shop.example.com and the product list loads. In about 300 milliseconds, more than a dozen systems cooperated. If you can explain this page from memory, you understand DevOps networking.

The questions every DevOps engineer must be able to answer

The method

Ten real incidents

Post-incident note template

## Incident: API 502 errors – 2026-10-24 19:05–19:20 (15 min)
**Impact:** 100% of /api requests failed; checkout unavailable.
**Detection:** Uptime alert at 19:07 (2 min after deploy).
**Root cause:** New release listened on :8000; nginx proxy_pass still :5000.
**Fix:** Aligned PORT env + proxy_pass, reloaded nginx at 19:20.
**Prevention:** Post-deploy smoke test hits /api/health through nginx; port defined in one place.

Your practical learning order

Portfolio projects that prove these skills

Glossary

ACL / NACL

Access control list. In the cloud, a stateless subnet-level firewall with ordered allow/deny rules.

ALB / NLB

AWS Application (L7, HTTP) and Network (L4, TCP/UDP) Load Balancers.

ARP

Address Resolution Protocol: finds the MAC address for an IP on the local network.

Availability Zone (AZ)

A physically separate data centre within a cloud region.

Bastion / jump host

A hardened server used as the only SSH entry point into a private network.

Bridge

A virtual switch connecting interfaces, e.g. Docker's docker0.

CA (Certificate Authority)

A trusted organisation that signs TLS certificates (e.g. Let's Encrypt).

CDN

Content Delivery Network: servers worldwide that cache content close to users.

CIDR

The address/prefix notation for IP ranges, e.g. 10.0.0.0/16.

Client / server

The client starts a connection; the server listens and responds.

CNAME

A DNS alias from one name to another name.

CNI

Container Network Interface: the plugin system that gives Kubernetes pods networking (Flannel, Calico, Cilium).

Conntrack

The kernel's connection-tracking table that makes Linux firewalls stateful.

CoreDNS

The DNS server inside Kubernetes clusters.

DHCP

Automatically assigns IP, mask, gateway and DNS to devices (Discover-Offer-Request-Ack).

DNAT / SNAT

Destination/Source NAT: rewriting the destination (port publishing) or the source (outbound) address.

DNS

Domain Name System: translates names into IP addresses and other records.

Egress / ingress

Outbound / inbound traffic (also the name of the Kubernetes Ingress resource).

Encapsulation

Each layer wrapping data in its own header on the way down the stack.

Ephemeral port

A temporary, random source port used by a client for one connection.

Firewall

Filters traffic by rules (IP, port, protocol, state).

Gateway (default)

The router a host sends traffic to when the destination isn't in its subnet.

Gateway API

The successor to Kubernetes Ingress: GatewayClass, Gateway and HTTPRoute objects.

Handshake (TCP / TLS)

The setup exchange before data: SYN, SYN-ACK, ACK for TCP; hello and key exchange for TLS.

Health check

A periodic probe a load balancer uses to decide whether a backend gets traffic.

HSTS

A header telling browsers to always use HTTPS for a domain.

HTTP / HTTPS

The web's request/response protocol; HTTPS is HTTP inside TLS.

ICMP

A control/diagnostic protocol with no ports, used by ping and traceroute.

Internet Gateway (IGW)

The cloud component that connects a VPC to the Internet.

IP address

The logical address of a network interface (IPv4: 32-bit, IPv6: 128-bit).

Keep-alive

Reusing one TCP/TLS connection for multiple HTTP requests.

kube-proxy

Programs Service forwarding rules (iptables/IPVS) on every Kubernetes node.

LAN / WAN

Local network in one site / a network spanning large distances.

Latency

The time for data to travel; RTT is the round-trip time.

Load balancer

Spreads traffic across multiple backends and removes unhealthy ones.

Loopback

127.0.0.1 / ::1, the machine talking to itself.

MAC address

The 48-bit hardware address used for delivery within a LAN.

MTU

Maximum Transmission Unit: the largest frame payload (usually 1500 bytes).

mTLS

Mutual TLS: both client and server present certificates.

NAT / NAT gateway

Translating private addresses to public ones; the managed cloud service that does it for private subnets.

Netfilter

The Linux kernel packet-filtering framework behind iptables, nftables and UFW.

NetworkPolicy

A Kubernetes firewall rule set for pods.

NodePort

A Kubernetes Service type exposing a port (30000–32767) on every node.

OSI model

The 7-layer reference model: Physical, Data link, Network, Transport, Session, Presentation, Application.

Overlay network

A virtual network tunnelled over another (e.g. VXLAN between hosts).

Packet / frame / segment

The data units at L3 / L2 / L4.

Peering

A private, non-transitive connection between two VPCs/VNets.

Port

A 16-bit number (0–65535) identifying a program/service on a host.

PTR record

A reverse DNS record (IP → name).

Recursive resolver

The DNS server that looks up answers on your behalf and caches them (1.1.1.1, 8.8.8.8).

Reverse proxy

A server in front of backends that receives client requests for them (Nginx, HAProxy).

Route table

The list of destination → next-hop rules; the most specific match wins.

Security group

A stateful, allow-only cloud firewall attached to instances/interfaces.

Service (Kubernetes)

A stable virtual IP and DNS name that load-balances to pods selected by labels.

SNI

Server Name Indication: the hostname sent in the TLS hello so one IP can serve many certificates.

Socket

An IP:port endpoint; a connection is identified by its 5-tuple.

Subnet / subnet mask

A sub-range of a network; the mask marks the network vs host bits.

TCP / UDP

Reliable, connection-oriented transport / fast, connectionless transport.

TLS

Transport Layer Security: encryption, integrity and server authentication.

TTL

DNS: how long an answer may be cached. IP: the hop limit before a packet is dropped.

VPC / VNet

A private, isolated virtual network in the cloud.

VPN

An encrypted tunnel connecting networks or a device to a network (WireGuard, IPsec).

WebSocket

A long-lived, two-way connection upgraded from HTTP.

Zero trust

A security model that verifies every request by identity, device and policy, not network location.