Check: Networking basics

L7 in the OSI model is the application layer, which for the web means HTTP. A balancer like that parses the HTTP request and decides where to send it based on the path, a header or a cookie. An L4 load balancer only sees TCP/UDP addresses and ports and doesn't read the content. That's option 3, which describes L4.

Every container has its own network stack and its own loopback. A service on 127.0.0.1 only accepts connections from inside that same container. A neighbor arrives at the eth0 interface's address, and nothing is listening on that port there. To accept connections from neighbors and through a port mapping from the host, listen on 0.0.0.0:8080.

See for yourself. Create a network and run a service that listens only on loopback:

docker network create --label izi.lab=net14-quiz quiz-net

docker run -d --name quiz-api --network quiz-net --label izi.lab=net14-quiz --memory 48m --cpus 0.25 python:3.12.7-alpine python -m http.server 8080 --bind 127.0.0.1

From inside the container the port is open:

docker exec quiz-api sh -c 'nc -z -w2 127.0.0.1 8080 && echo "inside: 127.0.0.1:8080 open"'

inside: 127.0.0.1:8080 open

But a neighbor on the network gets refused:

docker run --rm --network quiz-net --label izi.lab=net14-quiz --memory 32m nginx:1.27.3-alpine curl -sS -m 3 http://quiz-api:8080/

curl: (7) Failed to connect to quiz-api port 8080 after 59 ms: Could not connect to server

Restart the service with --bind 0.0.0.0:

docker rm -f quiz-api

docker run -d --name quiz-api --network quiz-net --label izi.lab=net14-quiz --memory 48m --cpus 0.25 python:3.12.7-alpine python -m http.server 8080 --bind 0.0.0.0

docker run --rm --network quiz-net --label izi.lab=net14-quiz --memory 32m nginx:1.27.3-alpine curl -sS -m 3 -o /dev/null -w '%{http_code}\n' http://quiz-api:8080/

200

The quiz-api container and network will come in handy in questions 6 and 9; cleanup is at the end of question 9.

CNAME (canonical name) says "this name is actually that name," and the resolver follows the chain further. A returns an IPv4 address, MX points to the domain's mail server, TXT holds arbitrary text (SPF, DKIM, domain ownership checks). More on record types in the DNS lesson.

401 means the server doesn't know who's asking: credentials are missing or wrong. 403 means the server knows who you are, but this action is forbidden for you. They're often confused; remember it this way: 401 asks "who are you?", 403 answers "I know who you are, but no." Definitions in RFC 9110, 401 and 403.

nginx returns 502 Bad Gateway when it can't get a valid response from the upstream. The most common case: the connection never got established because the backend crashed or isn't listening on that port and address. nginx's log then shows connect() failed (111: Connection refused). 504 Gateway Timeout means the connection exists, but no response arrived within proxy_read_timeout, and the log shows upstream timed out. You'll run into both cases in the mini-project. Definitions in RFC 9110, 502 and 504.

nc -z tries to open a TCP connection and closes it right away without sending anything, -v prints the result. ping uses ICMP and doesn't know about ports, dig asks DNS, traceroute shows the path to the host, not the state of a port.

Check it on quiz-api from question 2 (it listens on 8080, nothing is on 5432). In the nginx:1.27.3-alpine image, nc is busybox's: on an open port it prints open, on a closed one it stays silent and exits with code 1. The nc version on macOS and in Ubuntu prints Connection refused on a closed port.

docker run --rm --network quiz-net --label izi.lab=net14-quiz --memory 32m nginx:1.27.3-alpine sh -c 'nc -zv -w2 quiz-api 8080; nc -zv -w2 quiz-api 5432; echo "nc exit code: $?"'

quiz-api (172.25.0.2:8080) open
nc exit code: 1

The address in parentheses will be your own: Docker assigns it when it creates the network.

ping uses ICMP, which is often blocked by a firewall on the host or in a cloud security group. TCP, meanwhile, is open, and the service works. A silent ping doesn't prove the server is unreachable. Check the service itself: nc -zv on the port or curl -v on the URL. More in the firewall lesson, the section "Why ping doesn't answer even though the service is alive."

The client sends SYN, the server replies with SYN-ACK, the client confirms with ACK. After that the connection is established and data flows. What this looks like in a traffic capture is covered in the TCP lesson.

On a SYN to a closed port, the kernel immediately answers with an RST, which is why the refusal arrives instantly. If instead the firewall silently drops the packets (DROP), there's no response at all, and the client hangs until it times out. This difference is how you tell "nobody's listening" apart from "the firewall is blocking it."

Check it on the same quiz-api: the refusal on port 5432 arrives within tens of milliseconds.

docker run --rm --network quiz-net --label izi.lab=net14-quiz --memory 32m nginx:1.27.3-alpine curl -sS -m 3 http://quiz-api:5432/

curl: (7) Failed to connect to quiz-api port 5432 after 31 ms: Could not connect to server

Clean up:

docker rm -f quiz-api

docker network rm quiz-net

DNAT sends a packet that arrives from outside to a host on the internal network. Rewriting the source on the way out (option 1) is called SNAT. NAT doesn't do filtering, that's the firewall rules' job. Addresses are handed out by DHCP (option 4). docker run -p 127.0.0.1:8080:80 works the same way: Docker sets up a DNAT rule from a host port to a container port. If the right-hand side names a port that nothing inside the container listens on, the mapping will be there, but there'll be no response. That's one of the breaks in the mini-project.

The DORA scheme. The client broadcasts a Discover, the server offers an address in an Offer, the client asks for that exact one via a Request, the server locks in the lease with an Ack. More in the DHCP lesson.