Cuarta sesión de gimnasio: el modelo TCP/IP del módulo 4 — el que de verdad corre en cada máquina que tocas. Aquí se entrena lo más operativo hasta ahora: mapear los dos modelos sin titubear, leer tablas de rutas y predecir por dónde saldrá un paquete antes de enviarlo, diagnosticar a partir de estados de conexión, y dominar el flujo completo de una petición HTTPS — la coreografía DNS→TCP→TLS→HTTP que ejecutas cientos de veces al día sin verla. Escenario principal: Grupo Meridiano, con su túnel VPN Valencia–Bilbao trabajando a pleno rendimiento.

• Resuelve antes de mirar la solución (inmediatamente debajo de cada enunciado).
• En los de tablas de rutas, juega a ser el kernel: recorre las reglas con la disciplina de una máquina — la intuición humana es justo lo que hay que desconectar.
• En los de diagnóstico, además de la causa, di la siguiente comprobación que harías: así se responde en el mundo real.
• 📌 indica qué lección repasar en caso de fallo (módulo 4, de 04-01 a 04-06).

1. Dibuja (o escribe) la correspondencia entre las 7 capas OSI y las 4 capas del modelo TCP/IP.
2. ¿Qué capas OSI absorbe la capa de aplicación de TCP/IP, y por qué esa fusión resulta tan natural en el software real?
3. ¿Y a qué capas OSI corresponde la capa de acceso a red?

📌 Repasa si fallas: lecciones 04-01 y 04-06.

1. La correspondencia:

2. Absorbe 5, 6 y 7. La fusión es natural porque en el software real esas tres funciones viven en el mismo programa: el navegador (o curl, o tu aplicación) gestiona la sesión, la representación de los datos y el protocolo de aplicación de una vez — ya lo viste al clasificar el navegador en OSI. TCP/IP describe el software tal cual se escribe; OSI, las funciones tal cual se analizan.
3. A las capas 1 y 2: todo lo necesario para mover tramas por el enlace local, sea Ethernet, Wi-Fi o el medio que toque.

Errores frecuentes: aprenderse un modelo "bueno" y otro "malo". Son herramientas complementarias, y el lema del módulo 4 lo resume: piensa en 4, comunica en 7 — organiza tu diagnóstico con TCP/IP y usa la precisión de OSI para explicar dónde duele.

Coloca cada elemento en su capa del modelo TCP/IP (aplicación, transporte, internet, acceso a red):

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

📌 Repasa si fallas: lecciones 04-02 a 04-05.

Dos matices que valen puntos: TLS, que en OSI bailaba entre 5 y 6, en TCP/IP cae sin drama en aplicación (todo lo que va sobre transporte lo es); y DHCP y DNS, que aunque sean "fontanería de infraestructura", funcionan como aplicaciones cliente-servidor normales y corrientes.

En el servidor de la intranet (192.168.10.10, Linux):

Predice qué regla se aplica y qué hace el servidor (¿entrega directa o gateway?) para responder a cada cliente:

1. El PC de Marta, 192.168.10.21.
2. El PC de Jon, 192.168.20.7.
3. Un rastreador web externo, 203.0.113.99.

📌 Repasa si fallas: lección 04-03.

El kernel busca la ruta más específica que contenga al destino; default (que es 0.0.0.0/0, "todo") solo gana cuando ninguna otra encaja:

1. 192.168.10.21 encaja en 192.168.10.0/24 → entrega directa por ens18: resuelve la MAC de Marta por ARP y le habla de tú a tú, sin router.
2. 192.168.20.7 no encaja en la /24 → ruta por defecto: entrega la trama al gateway 192.168.10.1, que ya sabrá (por su túnel) cómo llegar a Bilbao. Fíjate: el servidor no necesita saber nada de la VPN — le basta confiar en su gateway.
3. 203.0.113.99 → también por defecto, al gateway, que lo sacará a Internet (con NAT mediante).

Errores frecuentes: creer que el servidor necesita una ruta explícita hacia 192.168.20.0/24 para que Bilbao funcione. No: la inteligencia de rutas puede vivir solo en los routers; a los equipos finales les basta la ruta por defecto. (Otra cosa es el router, como verás ahora.)

El router 192.168.10.1 tiene tres patas: eth1 (LAN), ppp0 (Internet, IP pública 81.40.12.7) y tun0 (túnel VPN con Bilbao):

1. ¿Por qué interfaz sale un paquete dirigido a 192.168.20.7? ¿Y uno a 142.250.184.4? ¿Y a 192.168.10.55? Justifica cada uno con la regla exacta que gana.
2. El túnel se cae y la ruta de tun0 desaparece de la tabla. Un paquete de Marta hacia 192.168.20.7 llega al router: ¿qué ruta se aplica ahora y por qué eso es un problema serio?
3. En un portátil con cable y Wi-Fi a la vez aparecen dos rutas por defecto: default via 192.168.10.1 dev eth0 metric 100 y default via 192.168.10.1 dev wlan0 metric 600. ¿Por cuál sale el tráfico y qué papel juega la métrica?

📌 Repasa si fallas: lecciones 04-02 y 04-03.

1. Gana siempre el prefijo más específico:
   • 192.168.20.7 → encaja en 192.168.20.0/24 → sale por tun0, el túnel. (La VPN es, a efectos de rutas, una interfaz más — esa es su elegancia.)
   • 142.250.184.4 → ninguna ruta específica lo contiene → default por ppp0, a Internet.
   • 192.168.10.55 → 192.168.10.0/24 → entrega directa por eth1, la LAN.
2. Sin la ruta del túnel, 192.168.20.7 solo encaja en la default: el router lo intenta mandar a Internet por ppp0. Y ahí muere: 192.168.20.x es un rango privado, que los routers de Internet no encaminan (y el NAT tampoco lo salva — no hay ningún "192.168.20.7 de Internet" al que llegar). Síntoma resultante: "Bilbao no responde, pero Internet va bien" — exactamente el caso B del módulo 6. Una ruta que desaparece no da error: simplemente el tráfico empieza a caer por la ruta equivocada.
3. Sale por eth0 (cable): a igualdad de especificidad (ambas son default), gana la métrica más baja (100 < 600). La métrica es el desempate por preferencia; por eso el sistema prefiere el cable aunque el Wi-Fi también esté conectado, y por eso al desenchufar el cable el tráfico salta al Wi-Fi sin que hagas nada.

En el servidor de la intranet:

1. ¿Qué significa cada una de las dos líneas LISTEN? ¿Qué diferencia práctica hay entre escuchar en 0.0.0.0 y en 127.0.0.1?
2. ¿Quiénes están usando la intranet ahora mismo?
3. Interpreta las líneas TIME-WAIT, SYN-SENT y CLOSE-WAIT: ¿qué historia cuenta cada una? ¿Cuál de las tres apunta a un posible problema y de quién?
4. Un desarrollador reinicia la aplicación de la intranet y obtiene bind: EADDRINUSE. ¿Qué ha pasado?

📌 Repasa si fallas: lección 04-04.

1. Hay un servicio esperando conexiones en el puerto 443 de todas las interfaces (0.0.0.0 = accesible desde la red: es la intranet) y otro en el 5432 solo en 127.0.0.1 (loopback: la base de datos, accesible únicamente desde la propia máquina — una decisión de seguridad deliberada: ni Marta ni nadie puede conectar a la base de datos desde la red).
2. Las dos ESTAB: Jon (192.168.20.7, desde Bilbao a través del túnel) y Marta (192.168.10.21), cada uno desde su puerto efímero contra el 443.
3. Historias:
   • TIME-WAIT: una conexión con .10.33 que ya terminó bien y cuyo extremo espera un tiempo prudencial antes de liberar del todo el puerto, por si llegan paquetes rezagados. Es salud, no enfermedad.
   • SYN-SENT: el servidor está intentando conectar como cliente hacia 203.0.113.50:443 y aún no ha recibido el SYN-ACK. Si persiste, ese destino no responde (caído, inalcanzable o filtrado). Es el estado "llamando... sin que descuelguen".
   • CLOSE-WAIT: el otro extremo (.10.45) cerró la conexión y la aplicación local todavía no ha cerrado su lado. Una o dos, normal; si se acumulan, el problema es de la aplicación del servidor (no cierra conexiones — fuga de recursos). La que apunta a problema inmediato es SYN-SENT persistente (destino que no contesta); CLOSE-WAIT lo es si se multiplica.
4. Ha intentado hacer bind del puerto 443 cuando todavía está ocupado — típicamente porque el proceso anterior sigue vivo (o el puerto sigue retenido en TIME-WAIT de un cierre inmediato anterior). Primera comprobación: ss -tlnp para ver qué proceso tiene el puerto.

Errores frecuentes: alarmarse por los TIME-WAIT ("¡hay conexiones fantasma!"). En un servidor con tráfico, docenas de TIME-WAIT son la respiración normal de TCP. Los estados hay que leerlos como tendencia y contexto, no como palabras sueltas.

Jon, recién sentado (cachés vacías, ninguna conexión abierta), ejecuta desde Bilbao una llamada a https://intranet.grupomeridiano.example/api/proyectos. Ordena los pasos:

• (a) Handshake TLS: negociación de cifrado y verificación del certificado.
• (b) Consulta DNS (UDP, puerto 53) para resolver el nombre.
• (c) El servidor responde 200 OK con el JSON.
• (d) Handshake TCP (SYN, SYN-ACK, ACK) contra el puerto 443.
• (e) Petición GET /api/proyectos (ya cifrada).
• (f) ARP para obtener la MAC del gateway 192.168.20.1.

Indica además qué paso reutilizaría una segunda llamada hecha diez segundos después.

📌 Repasa si fallas: lección 04-05.

Orden: f → b → d → a → e → c (con un matiz: el ARP se dispara con el primer paquete que necesita salir — la propia consulta DNS —, por eso va primero).

1. (f) Sin la MAC del gateway no sale ni la consulta DNS: ARP primero.
2. (b) DNS resuelve intranet.grupomeridiano.example → 192.168.10.10. Viaja en UDP:53 — rápido, sin conexión.
3. (d) Con la IP en la mano, TCP abre conexión al 443: SYN → SYN-ACK → ACK, a través del túnel.
4. (a) Sobre esa conexión, TLS negocia claves y Jon verifica que el certificado es de quien dice ser.
5. (e) Solo ahora viaja el GET, ya cifrado e ilegible para cualquier fisgón del camino.
6. (c) El 200 OK con el JSON recorre el camino inverso.

Una segunda llamada a los diez segundos se saltaría casi todo: DNS está en caché, y la conexión TCP+TLS suele reutilizarse (keep-alive), así que iría directa al paso (e). Por eso "la primera vez tarda más" es un síntoma con explicación técnica, no una manía de las máquinas.

Cuatro días, cuatro fallos distintos con la misma URL. Para cada salida de curl -v (recortada), identifica qué etapas del flujo se completaron, cuál falló, y di la primera comprobación que harías:

Caso A

Caso B

Caso C

Caso D

📌 Repasa si fallas: lecciones 04-05 y 06-01.

La lógica de fondo, que es la del embudo del módulo 4: curl -v recorre el flujo por orden, y el punto exacto donde se corta señala la capa culpable. Nota el matiz del caso B: timeout (silencio — red rota, host caído o firewall que descarta) no es lo mismo que connection refused (respuesta activa: hay red, pero el puerto está cerrado). Ese matiz decide si persigues la red o el servicio.

Responde razonando, como cierre del bloque de modelos:

1. ¿En qué capa del modelo TCP/IP colocarías ARP? ¿Es más o menos incómodo que colocarlo en OSI?
2. ¿Dónde cae MPLS, la tecnología que los operadores usan para transportar tráfico con etiquetas, y por qué se le apoda "capa 2.5"?
3. Tu jefa te pide "un informe del problema de ayer, en lenguaje que entienda el proveedor". El problema fue el caso C del ejercicio anterior. Aplica "piensa en 4, comunica en 7": ¿cómo lo investigaste y cómo lo comunicas?

📌 Repasa si fallas: lección 04-06.

1. En acceso a red: sirve para entregar tramas en el enlace local, así que funcionalmente vive abajo. Resulta menos incómodo que en OSI — al fusionar las capas 1-2 (y no separar tan tajantemente la 3), TCP/IP no obliga a elegir entre "capa 2" y "capa 3": la costura donde ARP habita queda dentro de una sola caja. Los modelos con menos fronteras generan menos casos fronterizos.
2. MPLS opera entre el enlace y la red: por debajo de IP (transporta los paquetes ajenos a él) pero por encima del enlace físico (sus etiquetas viajan sobre tramas). De ahí el apodo "capa 2.5" — un recordatorio con humor de que el mundo real no firmó el contrato de las 7 capas.
3. Pensaste en 4: recorriste el flujo por capas TCP/IP — DNS resolvió (aplicación/infraestructura OK), el handshake TCP completó (transporte e internet OK), y el corte fue en TLS con "certificate has expired". Comunicas en 7 (con la precisión de OSI y el lenguaje del destinatario): "La conectividad de red está descartada: la conexión se establece correctamente. El fallo es el certificado TLS del servidor, caducado el día X; necesitamos su renovación". Diagnóstico por capas para ti; una frase accionable para el proveedor.

Con esta sesión, el modelo TCP/IP ha pasado de esquema a herramienta de trabajo: mapeas los dos modelos sin dudar, predices el destino de un paquete leyendo rutas como el kernel (prefijo más específico, y métrica de desempate), lees en ss quién habla con quién y qué historias cuentan TIME-WAIT, SYN-SENT y CLOSE-WAIT, y —lo más rentable de todo— sitúas un fallo en su etapa exacta viendo dónde se corta el flujo DNS→TCP→TLS→HTTP. Queda el músculo más matemático del curso: la próxima sesión es la de direccionamiento IP — binario, máscaras, subnetting, VLSM, NAT e IPv6 — la más larga y calculística del módulo. Llévate papel: se calcula todo a mano.