Quarta sessió de gimnàs: el model TCP/IP del mòdul 4 — el que de debò corre a cada màquina que toques. Aquí s'entrena el més operatiu fins ara: mapar els dos models sense titubejar, llegir taules de rutes i predir per on sortirà un paquet abans d'enviar-lo, diagnosticar a partir d'estats de connexió, i dominar el flux complet d'una petició HTTPS — la coreografia DNS→TCP→TLS→HTTP que executes centenars de vegades al dia sense veure-la. Escenari principal: Grupo Meridiano, amb el seu túnel VPN València–Bilbao treballant a ple rendiment.

• Resol abans de mirar la solució (immediatament a sota de cada enunciat).
• En els de taules de rutes, juga a ser el kernel: recorre les regles amb la disciplina d'una màquina — la intuïció humana és justament el que cal desconnectar.
• En els de diagnòstic, a més de la causa, digues la comprovació següent que faries: així es respon al món real.
• 📌 indica quina lliçó repassar en cas d'error (mòdul 4, de 04-01 a 04-06).

1. Dibuixa (o escriu) la correspondència entre les 7 capes OSI i les 4 capes del model TCP/IP.
2. Quines capes OSI absorbeix la capa d'aplicació de TCP/IP, i per què aquesta fusió resulta tan natural al programari real?
3. I a quines capes OSI correspon la capa d'accés a xarxa?

📌 Repassa si falles: lliçons 04-01 i 04-06.

1. La correspondència:

2. Absorbeix la 5, la 6 i la 7. La fusió és natural perquè al programari real aquestes tres funcions viuen al mateix programa: el navegador (o curl, o la teva aplicació) gestiona la sessió, la representació de les dades i el protocol d'aplicació d'una tirada — ja ho vas veure en classificar el navegador a OSI. TCP/IP descriu el programari tal com s'escriu; OSI, les funcions tal com s'analitzen.
3. A les capes 1 i 2: tot el que cal per moure trames per l'enllaç local, sigui Ethernet, Wi-Fi o el mitjà que toqui.

Errors freqüents: aprendre's un model «bo» i un altre de «dolent». Són eines complementàries, i el lema del mòdul 4 ho resumeix: pensa en 4, comunica en 7 — organitza el teu diagnòstic amb TCP/IP i fes servir la precisió d'OSI per explicar on fa mal.

Col·loca cada element a la seva capa del model TCP/IP (aplicació, transport, internet, accés a xarxa):

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

📌 Repassa si falles: lliçons 04-02 a 04-05.

Dos matisos que valen punts: TLS, que a OSI ballava entre la 5 i la 6, a TCP/IP cau sense drames a aplicació (tot el que va sobre transport ho és); i DHCP i DNS, que encara que siguin «lampisteria d'infraestructura», funcionen com a aplicacions client-servidor normals i corrents.

Al servidor de la intranet (192.168.10.10, Linux):

Prediu quina regla s'aplica i què fa el servidor (lliurament directe o gateway?) per respondre a cada client:

1. El PC de la Marta, 192.168.10.21.
2. El PC d'en Jon, 192.168.20.7.
3. Un rastrejador web extern, 203.0.113.99.

📌 Repassa si falles: lliçó 04-03.

El kernel busca la ruta més específica que contingui la destinació; default (que és 0.0.0.0/0, «tot») només guanya quan cap altra no hi encaixa:

1. 192.168.10.21 encaixa a 192.168.10.0/24 → lliurament directe per ens18: resol la MAC de la Marta per ARP i li parla de tu a tu, sense router.
2. 192.168.20.7 no encaixa a la /24 → ruta per defecte: lliura la trama al gateway 192.168.10.1, que ja sabrà (pel seu túnel) com arribar a Bilbao. Fixa-t'hi: el servidor no necessita saber res de la VPN — en té prou confiant en el seu gateway.
3. 203.0.113.99 → també per defecte, al gateway, que el traurà a Internet (amb NAT pel mig).

Errors freqüents: creure que el servidor necessita una ruta explícita cap a 192.168.20.0/24 perquè Bilbao funcioni. No: la intel·ligència de rutes pot viure només als routers; als equips finals els basta la ruta per defecte. (Una altra cosa és el router, com veuràs ara.)

El router 192.168.10.1 té tres potes: eth1 (LAN), ppp0 (Internet, IP pública 81.40.12.7) i tun0 (túnel VPN amb Bilbao):

1. Per quina interfície surt un paquet adreçat a 192.168.20.7? I un a 142.250.184.4? I a 192.168.10.55? Justifica cadascun amb la regla exacta que guanya.
2. El túnel cau i la ruta de tun0 desapareix de la taula. Un paquet de la Marta cap a 192.168.20.7 arriba al router: quina ruta s'aplica ara i per què això és un problema seriós?
3. En un portàtil amb cable i Wi-Fi alhora apareixen dues rutes per defecte: default via 192.168.10.1 dev eth0 metric 100 i default via 192.168.10.1 dev wlan0 metric 600. Per quina surt el trànsit i quin paper hi juga la mètrica?

📌 Repassa si falles: lliçons 04-02 i 04-03.

1. Guanya sempre el prefix més específic:
   • 192.168.20.7 → encaixa a 192.168.20.0/24 → surt per tun0, el túnel. (La VPN és, a efectes de rutes, una interfície més — aquesta és la seva elegància.)
   • 142.250.184.4 → cap ruta específica no el conté → default per ppp0, a Internet.
   • 192.168.10.55 → 192.168.10.0/24 → lliurament directe per eth1, la LAN.
2. Sense la ruta del túnel, 192.168.20.7 només encaixa a la default: el router el prova d'enviar a Internet per ppp0. I allà mor: 192.168.20.x és un rang privat, que els routers d'Internet no encaminen (i el NAT tampoc no ho salva — no hi ha cap «192.168.20.7 d'Internet» on arribar). Símptoma resultant: «Bilbao no respon, però Internet va bé» — exactament el cas B del mòdul 6. Una ruta que desapareix no dona error: simplement el trànsit comença a caure per la ruta equivocada.
3. Surt per eth0 (cable): a igualtat d'especificitat (totes dues són default), guanya la mètrica més baixa (100 < 600). La mètrica és el desempat per preferència; per això el sistema prefereix el cable encara que el Wi-Fi també estigui connectat, i per això en desendollar el cable el trànsit salta al Wi-Fi sense que facis res.

Al servidor de la intranet:

1. Què significa cadascuna de les dues línies LISTEN? Quina diferència pràctica hi ha entre escoltar a 0.0.0.0 i a 127.0.0.1?
2. Qui està fent servir la intranet ara mateix?
3. Interpreta les línies TIME-WAIT, SYN-SENT i CLOSE-WAIT: quina història explica cadascuna? Quina de les tres apunta a un possible problema i de qui?
4. Un desenvolupador reinicia l'aplicació de la intranet i obté bind: EADDRINUSE. Què ha passat?

📌 Repassa si falles: lliçó 04-04.

1. Hi ha un servei esperant connexions al port 443 de totes les interfícies (0.0.0.0 = accessible des de la xarxa: és la intranet) i un altre al 5432 només a 127.0.0.1 (loopback: la base de dades, accessible únicament des de la mateixa màquina — una decisió de seguretat deliberada: ni la Marta ni ningú no pot connectar a la base de dades des de la xarxa).
2. Les dues ESTAB: en Jon (192.168.20.7, des de Bilbao a través del túnel) i la Marta (192.168.10.21), cadascun des del seu port efímer contra el 443.
3. Històries:
   • TIME-WAIT: una connexió amb .10.33 que ja ha acabat bé i l'extrem de la qual espera un temps prudencial abans d'alliberar del tot el port, per si arriben paquets ressagats. És salut, no malaltia.
   • SYN-SENT: el servidor està intentant connectar com a client cap a 203.0.113.50:443 i encara no ha rebut el SYN-ACK. Si persisteix, aquella destinació no respon (caiguda, inabastable o filtrada). És l'estat «trucant... sense que despengin».
   • CLOSE-WAIT: l'altre extrem (.10.45) ha tancat la connexió i l'aplicació local encara no ha tancat la seva banda. Una o dues, normal; si s'acumulen, el problema és de l'aplicació del servidor (no tanca connexions — fuita de recursos). La que apunta a problema immediat és SYN-SENT persistent (destinació que no contesta); CLOSE-WAIT ho és si es multiplica.
4. Ha intentat fer bind del port 443 quan encara està ocupat — típicament perquè el procés anterior continua viu (o el port continua retingut en TIME-WAIT d'un tancament immediat anterior). Primera comprovació: ss -tlnp per veure quin procés té el port.

Errors freqüents: alarmar-se pels TIME-WAIT («hi ha connexions fantasma!»). En un servidor amb trànsit, dotzenes de TIME-WAIT són la respiració normal de TCP. Els estats s'han de llegir com a tendència i context, no com a paraules soltes.

En Jon, acabat de seure (memòries cau buides, cap connexió oberta), executa des de Bilbao una crida a https://intranet.grupomeridiano.example/api/proyectos. Ordena els passos:

• (a) Handshake TLS: negociació de xifratge i verificació del certificat.
• (b) Consulta DNS (UDP, port 53) per resoldre el nom.
• (c) El servidor respon 200 OK amb el JSON.
• (d) Handshake TCP (SYN, SYN-ACK, ACK) contra el port 443.
• (e) Petició GET /api/proyectos (ja xifrada).
• (f) ARP per obtenir la MAC del gateway 192.168.20.1.

Indica a més quin pas reutilitzaria una segona crida feta deu segons després.

📌 Repassa si falles: lliçó 04-05.

Ordre: f → b → d → a → e → c (amb un matís: l'ARP es dispara amb el primer paquet que necessita sortir — la mateixa consulta DNS —, per això va primer).

1. (f) Sense la MAC del gateway no surt ni la consulta DNS: ARP primer.
2. (b) DNS resol intranet.grupomeridiano.example → 192.168.10.10. Viatja en UDP:53 — ràpid, sense connexió.
3. (d) Amb la IP a la mà, TCP obre connexió al 443: SYN → SYN-ACK → ACK, a través del túnel.
4. (a) Sobre aquesta connexió, TLS negocia claus i en Jon verifica que el certificat és de qui diu ser.
5. (e) Només ara viatja el GET, ja xifrat i il·legible per a qualsevol tafaner del camí.
6. (c) El 200 OK amb el JSON recorre el camí invers.

Una segona crida al cap de deu segons s'ho saltaria gairebé tot: DNS és a la memòria cau, i la connexió TCP+TLS sol reutilitzar-se (keep-alive), així que aniria directa al pas (e). Per això «la primera vegada triga més» és un símptoma amb explicació tècnica, no una mania de les màquines.

Quatre dies, quatre fallades diferents amb la mateixa URL. Per a cada sortida de curl -v (retallada), identifica quines etapes del flux es van completar, quina va fallar, i digues la primera comprovació que faries:

Cas A

Cas B

Cas C

Cas D

📌 Repassa si falles: lliçons 04-05 i 06-01.

La lògica de fons, que és la de l'embut del mòdul 4: curl -v recorre el flux per ordre, i el punt exacte on es talla assenyala la capa culpable. Fixa't en el matís del cas B: timeout (silenci — xarxa trencada, host caigut o tallafoc que descarta) no és el mateix que connection refused (resposta activa: hi ha xarxa, però el port està tancat). Aquest matís decideix si persegueixes la xarxa o el servei.

Respon raonant, com a tancament del bloc de models:

1. A quina capa del model TCP/IP col·locaries ARP? És més o menys incòmode que col·locar-lo a OSI?
2. On cau MPLS, la tecnologia que els operadors fan servir per transportar trànsit amb etiquetes, i per què li diuen «capa 2.5»?
3. La teva cap et demana «un informe del problema d'ahir, en llenguatge que entengui el proveïdor». El problema va ser el cas C de l'exercici anterior. Aplica «pensa en 4, comunica en 7»: com ho vas investigar i com ho comuniques?

📌 Repassa si falles: lliçó 04-06.

1. A accés a xarxa: serveix per lliurar trames a l'enllaç local, així que funcionalment viu a baix. Resulta menys incòmode que a OSI — en fusionar les capes 1-2 (i no separar tan taxativament la 3), TCP/IP no obliga a triar entre «capa 2» i «capa 3»: la costura on habita ARP queda dins d'una sola caixa. Els models amb menys fronteres generen menys casos fronterers.
2. MPLS opera entre l'enllaç i la xarxa: per sota d'IP (transporta els paquets, aliens a ell) però per sobre de l'enllaç físic (les seves etiquetes viatgen sobre trames). D'aquí el sobrenom «capa 2.5» — un recordatori amb humor que el món real no va signar el contracte de les 7 capes.
3. Vas pensar en 4: vas recórrer el flux per capes TCP/IP — DNS va resoldre (aplicació/infraestructura OK), el handshake TCP es va completar (transport i internet OK), i el tall va ser a TLS amb «certificate has expired». Comuniques en 7 (amb la precisió d'OSI i el llenguatge del destinatari): «La connectivitat de xarxa està descartada: la connexió s'estableix correctament. La fallada és el certificat TLS del servidor, caducat el dia X; en necessitem la renovació». Diagnòstic per capes per a tu; una frase accionable per al proveïdor.

Amb aquesta sessió, el model TCP/IP ha passat d'esquema a eina de treball: mapes els dos models sense dubtar, predius la destinació d'un paquet llegint rutes com el kernel (prefix més específic, i mètrica de desempat), llegeixes a ss qui parla amb qui i quines històries expliquen TIME-WAIT, SYN-SENT i CLOSE-WAIT, i —el més rendible de tot— situes una fallada a la seva etapa exacta veient on es talla el flux DNS→TCP→TLS→HTTP. Queda el múscul més matemàtic del curs: la pròxima sessió és la d'adreçament IP — binari, màscares, subnetting, VLSM, NAT i IPv6 — la més llarga i calculística del mòdul. Emporta't paper: es calcula tot a mà.