Fourth gym session: the TCP/IP model from module 4 — the one that really runs on every machine you touch. This one trains the most operational skills so far: mapping the two models without hesitating, reading routing tables and predicting which way a packet will leave before sending it, diagnosing from connection states, and mastering the complete flow of an HTTPS request — the DNS→TCP→TLS→HTTP choreography you perform hundreds of times a day without seeing it. Main scenario: Grupo Meridiano, with its Valencia–Bilbao VPN tunnel working at full tilt.

• Solve before you look at the solution (immediately below each statement).
• In the routing table ones, play at being the kernel: walk the rules with a machine's discipline — human intuition is precisely what you need to switch off.
• In the diagnosis ones, besides the cause, state the next check you would run: that is how you answer in the real world.
• 📌 marks which lesson to review if you slip (module 4, 04-01 to 04-06).

1. Draw (or write out) the correspondence between the 7 OSI layers and the 4 layers of the TCP/IP model.
2. Which OSI layers does TCP/IP's application layer absorb, and why does that merger feel so natural in real software?
3. And which OSI layers does the network access layer correspond to?

📌 Review if you struggled: lessons 04-01 and 04-06.

1. The correspondence:

2. It absorbs 5, 6 and 7. The merger is natural because in real software those three functions live in the same program: the browser (or curl, or your application) manages the session, the data representation and the application protocol all at once — you already saw this when classifying the browser under OSI. TCP/IP describes software as it is written; OSI, functions as they are analyzed.
3. Layers 1 and 2: everything needed to move frames across the local link, be it Ethernet, Wi-Fi or whatever medium applies.

Frequent mistakes: learning one model as "good" and the other as "bad". They are complementary tools, and module 4's motto sums it up: think in 4, communicate in 7 — organize your diagnosis with TCP/IP and use OSI's precision to explain where it hurts.

Place each item in its TCP/IP model layer (application, transport, internet, network access):

HTTP · TCP · Ethernet · ICMP · DNS · Wi-Fi · IP · UDP · TLS · DHCP

📌 Review if you struggled: lessons 04-02 to 04-05.

Two nuances worth points: TLS, which in OSI danced between 5 and 6, drops into application in TCP/IP without any drama (everything that rides on transport is application); and DHCP and DNS, which despite being "infrastructure plumbing", work as perfectly ordinary client-server applications.

On the intranet server (192.168.10.10, Linux):

Predict which rule applies and what the server does (direct delivery or gateway?) to reply to each client:

1. Marta's PC, 192.168.10.21.
2. Jon's PC, 192.168.20.7.
3. An external web crawler, 203.0.113.99.

📌 Review if you struggled: lesson 04-03.

The kernel looks for the most specific route containing the destination; default (which is 0.0.0.0/0, "everything") only wins when nothing else matches:

1. 192.168.10.21 matches 192.168.10.0/24 → direct delivery via ens18: it resolves Marta's MAC via ARP and talks to her directly, no router involved.
2. 192.168.20.7 doesn't fit the /24 → default route: it hands the frame to the gateway 192.168.10.1, which will know (through its tunnel) how to reach Bilbao. Note: the server needs to know nothing about the VPN — trusting its gateway is enough.
3. 203.0.113.99 → also via default, to the gateway, which will push it out to the Internet (with NAT along the way).

Frequent mistakes: believing the server needs an explicit route to 192.168.20.0/24 for Bilbao to work. No: routing intelligence can live in the routers alone; end machines get by with the default route. (The router is another story, as you're about to see.)

The router 192.168.10.1 has three legs: eth1 (LAN), ppp0 (Internet, public IP 81.40.12.7) and tun0 (VPN tunnel with Bilbao):

1. Which interface does a packet addressed to 192.168.20.7 leave through? And one to 142.250.184.4? And to 192.168.10.55? Justify each with the exact rule that wins.
2. The tunnel goes down and the tun0 route vanishes from the table. A packet from Marta to 192.168.20.7 reaches the router: which route applies now, and why is that a serious problem?
3. On a laptop with cable and Wi-Fi at the same time, two default routes appear: default via 192.168.10.1 dev eth0 metric 100 and default via 192.168.10.1 dev wlan0 metric 600. Which one does traffic leave through, and what role does the metric play?

📌 Review if you struggled: lessons 04-02 and 04-03.

1. The most specific prefix always wins:
   • 192.168.20.7 → matches 192.168.20.0/24 → leaves via tun0, the tunnel. (For routing purposes, the VPN is just another interface — that is its elegance.)
   • 142.250.184.4 → no specific route contains it → default via ppp0, to the Internet.
   • 192.168.10.55 → 192.168.10.0/24 → direct delivery via eth1, the LAN.
2. Without the tunnel route, 192.168.20.7 only matches the default: the router tries to send it to the Internet via ppp0. And there it dies: 192.168.20.x is a private range, which Internet routers do not forward (and NAT doesn't save it either — there is no "192.168.20.7 of the Internet" to reach). Resulting symptom: "Bilbao doesn't answer, but the Internet is fine" — exactly case B from module 6. A route that disappears throws no error: traffic simply starts falling through the wrong route.
3. It leaves via eth0 (cable): at equal specificity (both are default), the lowest metric wins (100 < 600). The metric is the preference tiebreaker; that is why the system prefers the cable even with Wi-Fi connected, and why when you unplug the cable the traffic jumps to Wi-Fi without you doing anything.

On the intranet server:

1. What does each of the two LISTEN lines mean? What practical difference is there between listening on 0.0.0.0 and on 127.0.0.1?
2. Who is using the intranet right now?
3. Interpret the TIME-WAIT, SYN-SENT and CLOSE-WAIT lines: what story does each tell? Which of the three points to a possible problem, and whose?
4. A developer restarts the intranet application and gets bind: EADDRINUSE. What happened?

📌 Review if you struggled: lesson 04-04.

1. There is a service waiting for connections on port 443 of all interfaces (0.0.0.0 = reachable from the network: that's the intranet) and another on 5432 only on 127.0.0.1 (loopback: the database, reachable only from the machine itself — a deliberate security decision: neither Marta nor anyone else can connect to the database over the network).
2. The two ESTAB lines: Jon (192.168.20.7, from Bilbao through the tunnel) and Marta (192.168.10.21), each from their ephemeral port against 443.
3. The stories:
   • TIME-WAIT: a connection with .10.33 that already ended cleanly and whose endpoint waits a prudent while before fully releasing the port, in case straggler packets arrive. It is health, not sickness.
   • SYN-SENT: the server is trying to connect as a client to 203.0.113.50:443 and hasn't received the SYN-ACK yet. If it persists, that destination isn't answering (down, unreachable or filtered). It is the "ringing... nobody picking up" state.
   • CLOSE-WAIT: the other end (.10.45) closed the connection and the local application still hasn't closed its side. One or two, normal; if they pile up, the problem is in the server's application (it isn't closing connections — a resource leak). The one pointing to an immediate problem is a persistent SYN-SENT (a destination that won't answer); CLOSE-WAIT is one if it multiplies.
4. It tried to bind port 443 while it is still occupied — typically because the previous process is still alive (or the port is still held in TIME-WAIT from an immediately preceding shutdown). First check: ss -tlnp to see which process holds the port.

Frequent mistakes: panicking over TIME-WAITs ("there are ghost connections!"). On a busy server, dozens of TIME-WAITs are TCP's normal breathing. States must be read as trend and context, not as isolated words.

Jon, freshly sat down (empty caches, no connections open), runs a call from Bilbao to https://intranet.grupomeridiano.example/api/proyectos. Put the steps in order:

• (a) TLS handshake: cipher negotiation and certificate verification.
• (b) DNS query (UDP, port 53) to resolve the name.
• (c) The server replies 200 OK with the JSON.
• (d) TCP handshake (SYN, SYN-ACK, ACK) against port 443.
• (e) The GET /api/proyectos request (already encrypted).
• (f) ARP to obtain the MAC of the gateway 192.168.20.1.

Also state which step a second call made ten seconds later would reuse.

📌 Review if you struggled: lesson 04-05.

Order: f → b → d → a → e → c (with a nuance: the ARP is triggered by the first packet that needs to leave — the DNS query itself — which is why it comes first).

1. (f) Without the gateway's MAC not even the DNS query gets out: ARP first.
2. (b) DNS resolves intranet.grupomeridiano.example → 192.168.10.10. It travels over UDP:53 — fast, connectionless.
3. (d) IP in hand, TCP opens a connection to 443: SYN → SYN-ACK → ACK, through the tunnel.
4. (a) Over that connection, TLS negotiates keys and Jon verifies the certificate belongs to who it claims to.
5. (e) Only now does the GET travel, encrypted and unreadable to any snoop along the way.
6. (c) The 200 OK with the JSON retraces the path in reverse.

A second call ten seconds later would skip almost everything: DNS is cached, and the TCP+TLS connection is usually reused (keep-alive), so it would go straight to step (e). That is why "the first time is slower" is a symptom with a technical explanation, not a quirk of the machines.

Four days, four different failures with the same URL. For each (trimmed) curl -v output, identify which stages of the flow completed, which one failed, and state the first check you would run:

Case A

Case B

Case C

Case D

📌 Review if you struggled: lessons 04-05 and 06-01.

The underlying logic is module 4's funnel: curl -v walks the flow in order, and the exact point where it breaks names the guilty layer. Note the nuance in case B: a timeout (silence — broken network, dead host, or a firewall that drops) is not the same as connection refused (an active reply: the network is there, but the port is closed). That nuance decides whether you chase the network or the service.

Answer with reasoning, as the closer for the models block:

1. Which TCP/IP layer would you place ARP in? Is that more or less awkward than placing it in OSI?
2. Where does MPLS fall — the technology carriers use to move traffic with labels — and why is it nicknamed "layer 2.5"?
3. Your boss asks you for "a report on yesterday's problem, in language the provider will understand". The problem was case C from the previous exercise. Apply "think in 4, communicate in 7": how did you investigate it, and how do you communicate it?

📌 Review if you struggled: lesson 04-06.

1. In network access: it exists to deliver frames on the local link, so functionally it lives at the bottom. It turns out less awkward than in OSI — by merging layers 1-2 (and not walling off layer 3 so sharply), TCP/IP doesn't force a choice between "layer 2" and "layer 3": the seam ARP inhabits falls inside a single box. Models with fewer boundaries produce fewer borderline cases.
2. MPLS operates between link and network: below IP (it carries IP packets without their knowledge) but above the physical link (its labels ride on frames). Hence the nickname "layer 2.5" — a tongue-in-cheek reminder that the real world never signed the 7-layer contract.
3. You thought in 4: you walked the flow through the TCP/IP layers — DNS resolved (application/infrastructure OK), the TCP handshake completed (transport and internet OK), and the break came at TLS with "certificate has expired". You communicate in 7 (with OSI's precision and the recipient's language): "Network connectivity is ruled out: the connection establishes correctly. The failure is the server's TLS certificate, which expired on day X; we need it renewed". Layer-by-layer diagnosis for you; one actionable sentence for the provider.

With this session, the TCP/IP model has gone from diagram to working tool: you map the two models without hesitation, predict a packet's fate by reading routes the way the kernel does (most specific prefix, metric as tiebreaker), read in ss who is talking to whom and what stories TIME-WAIT, SYN-SENT and CLOSE-WAIT tell, and — most profitable of all — place a failure at its exact stage by seeing where the DNS→TCP→TLS→HTTP flow breaks. The most mathematical muscle of the course remains: the next session is IP addressing — binary, masks, subnetting, VLSM, NAT and IPv6 — the longest and most calculation-heavy of the module. Bring paper: everything is worked out by hand.