Subimos un peldaño en la pila: por debajo quedan las interfaces y sus enlaces (04-02); ahora entramos en la capa que da nombre a todo el invento — la capa de Internet, cuyo trabajo es que un paquete cruce de una red a otra hasta llegar a su destino, esté donde esté. Sus protagonistas ya son viejos conocidos: IP (02-03) e ICMP, junto con la función de encaminamiento (03-04). Lo que aporta esta lección es la parte que aún no has tocado: la capa vista desde dentro de un sistema real — leer tablas de rutas línea a línea con ip route y route print, entender la ruta por defecto y las métricas, y ver qué ocurre en la práctica cuando un paquete choca con la MTU del túnel VPN de Meridiano. Es importante porque la tabla de rutas es la primera parada de casi cualquier diagnóstico de conectividad: si la ruta está mal, todo lo demás da igual.

1. Qué vive en la capa de Internet
2. El enrutamiento como función de la capa
3. La tabla de rutas en la práctica: ip route en Linux
4. La misma tabla en Windows: route print
5. Ruta por defecto y métrica
6. Fragmentación y MTU en la práctica: el caso de la VPN
7. Lo que dejamos para el módulo 5: el direccionamiento a fondo

La capa de Internet de TCP/IP corresponde a la capa de red de OSI, y su inquilino central es el Protocolo de Internet (IP), que ya diseccionaste en 02-03: paquetes con direcciones lógicas de origen y destino, TTL, entrega best effort sin conexión. No lo repetiremos; recordemos solo su contrato: "dame un paquete y una dirección de destino, e intentaré que llegue, red a red, sin garantías".

Pero IP no vive solo en esta capa. La acompañan:

• ICMP (Internet Control Message Protocol): el mensajero de servicio de IP (02-03). Como IP no garantiza nada, alguien tiene que poder avisar cuando algo va mal: "destino inalcanzable", "TTL agotado", "fragmentación necesaria". ICMP viaja dentro de paquetes IP, pero conceptualmente es parte de la capa de Internet, no un usuario de ella: existe para que la propia capa funcione y se pueda diagnosticar (ping y traceroute viven de él; los explotaremos en el módulo 6).
• La función de encaminamiento (routing): decidir, paquete a paquete, por dónde continuar el viaje. No es un protocolo sino un proceso que ejecuta todo dispositivo con IP — no solo los routers — usando su tabla de rutas.
• Protocolos auxiliares que solo mencionamos: los de enrutamiento dinámico (OSPF, BGP — presentados conceptualmente en 03-04) que rellenan tablas de rutas automáticamente, e IPv6 con su propio ICMPv6, cuya existencia ya conoces y cuyo detalle pertenece al módulo 5.

En 03-04 aprendiste la idea: encaminamiento salto a salto, cada dispositivo decide solo el siguiente paso. Ahora la clave práctica: esa decisión la toma el kernel consultando su tabla de rutas para cada paquete que envía. Y esto vale tanto para el router de Valencia como para el PC de Marta: cuando Marta abre la intranet, su propio PC ejecuta el algoritmo:

1. Miro la IP de destino del paquete.
2. Busco en mi tabla la ruta más específica que la contenga (longest prefix match: gana el prefijo más largo).
3. Esa ruta me dice por qué interfaz sale el paquete y, si el destino no está en mi propia red, a qué siguiente salto (gateway) entregárselo.
4. Si ninguna ruta encaja ni hay ruta por defecto: error "red inalcanzable" (y, en un router, un ICMP de vuelta al origen).

Fíjate en el enlace con la lección anterior: toda ruta termina nombrando una interfaz. La tabla de rutas es el puente entre la capa de Internet ("¿hacia dónde?") y la capa de acceso a la red ("¿por qué puerta?").

Veamos la tabla real del servidor de la intranet (192.168.10.10, Linux):

Solo dos líneas — es un servidor, no un router — pero cada palabra importa. Línea a línea:

Línea 2 (la leemos primero porque es la más específica):

• 192.168.10.0/24 — el destino: cualquier IP de la red local de Valencia (el /24 que planificaste en 02-03).
• dev enp3s0 — interfaz de salida: la tarjeta Ethernet del servidor (04-02).
• proto kernel — quién creó la ruta: el propio kernel, automáticamente, al configurarse la IP 192.168.10.10/24 en la interfaz. Por eso nunca "configuras" esta ruta: nace con la dirección.
• scope link — la pieza conceptual: el destino es directamente alcanzable en el enlace, sin gateway. Para llegar a la impresora o al PC de Marta, el servidor no pasa por el router: resuelve la MAC por ARP y entrega la trama directamente (02-02).
• src 192.168.10.10 — qué IP de origen usar en los paquetes que salgan por esta ruta (relevante cuando una máquina tiene varias direcciones).

Línea 1:

• default — sinónimo de 0.0.0.0/0: cualquier destino no cubierto por otra ruta. Es el prefijo más corto posible, así que solo gana cuando nada más encaja.
• via 192.168.10.1 — el siguiente salto: el router de Valencia. Es, literalmente, la "puerta de enlace predeterminada" que viste en 02-03, ahora en su forma nativa: una entrada más de la tabla.
• proto static — la puso una configuración explícita (o el cliente DHCP), no el kernel.

Y una tercera herramienta preciosa para el diagnóstico — preguntar al kernel qué decidiría, sin enviar nada:

La presencia o ausencia de via es la diferencia entre "es de mi red" y "necesito el router" — la decisión fundamental que toma esta capa millones de veces al día.

En contraste, la tabla del router de Valencia tiene una línea más, y esa línea es la VPN:

Esa tercera ruta es todo el secreto de la comunicación entre sedes: "para la red de Bilbao, sal por la interfaz virtual del túnel". El resto lo hace la encapsulación cifrada que ya conoces.

En el PC de Marta (192.168.10.21, Windows), la información es la misma con otro traje:

Claves de traducción respecto a Linux:

Windows además muestra rutas "de fontanería" que Linux guarda aparte: la loopback (127.0.0.0/8), la dirección de difusión de la red (192.168.10.255) y la difusión general (255.255.255.255). Son normales; no las toques ni te alarmes al verlas.

Dos conceptos de la tabla merecen zoom propio.

La ruta por defecto (default / 0.0.0.0 0.0.0.0) es la red de seguridad de la tabla: "todo lo que no sepa dónde va, se lo doy a este gateway, que sabrá más que yo". Es la que convierte una LAN aislada en una red conectada al mundo:

• En los PCs de Meridiano apunta al router de su sede (.10.1 o .20.1).
• En los routers de Meridiano apunta al router del operador.
• En los routers del operador apunta hacia el núcleo de Internet... donde los routers troncales ya no tienen ruta por defecto: tienen la tabla completa de Internet (aprendida por BGP, como mencionamos en 03-04). En algún punto, alguien tiene que saberlo todo.

Síntoma clásico de su ausencia o error: "llego a los equipos de mi oficina pero no a Internet ni a Bilbao". Red local intacta (ruta scope link presente), mundo exterior perdido — apunta directamente a la ruta por defecto.

La métrica resuelve empates: si dos rutas igual de específicas llevan al mismo destino, gana la de métrica más baja (menor coste). El caso cotidiano es un portátil con cable y Wi-Fi conectados a la vez: dos rutas por defecto, una por cada interfaz. Windows asigna automáticamente una métrica menor al cable (más rápido y estable), y por eso el tráfico prefiere el cable aunque el Wi-Fi siga activo. Orden completo de decisión de la capa:

1. Especificidad primero: gana el prefijo más largo (una ruta /24 a 192.168.20.0 siempre gana a default para el tráfico hacia Bilbao, sea cual sea la métrica).
2. Métrica después: solo desempata entre rutas igual de específicas.

En 04-02 dejamos planteado el límite: cada interfaz declara su MTU. Ahora la reacción, que es competencia de esta capa. Recuerda de 03-04 las dos opciones cuando un paquete no cabe en el enlace de salida:

• Fragmentarlo (partirlo en trozos que el destino final reensambla), si el paquete lo permite; o
• Descartarlo y avisar con un ICMP "fragmentación necesaria" si el paquete lleva activada la marca DF (Don't Fragment), que es lo habitual hoy: los emisores modernos prefieren enterarse y ajustar (técnica llamada Path MTU Discovery) antes que pagar el coste y la fragilidad de la fragmentación.

El túnel de Meridiano es el escenario perfecto para verlo morder. La MTU de tun0 es 1436, menor que los 1500 de las LANs. Imagina que el servidor .10 envía a Jon paquetes de 1500 bytes con DF activado:

Ese es el funcionamiento sano: el ICMP llega, el emisor ajusta, nadie se entera. El fallo clásico aparece cuando un cortafuegos demasiado celoso bloquea esos mensajes ICMP: el servidor nunca recibe el aviso, sigue enviando a 1500, y el síntoma es desconcertante — el ping funciona (paquetes pequeños) y las transferencias grandes se cuelgan (paquetes grandes descartados en silencio). Es el famoso "agujero negro de MTU", una de las averías de VPN más comunes del mundo real.

Para no depender solo de ICMP existe un ajuste preventivo que conviene conocer de nombre: el MSS clamping. El MSS (Maximum Segment Size) es el tamaño máximo de segmento que TCP anuncia a su interlocutor durante el handshake (02-04); el router del túnel puede reescribir ese anuncio a la baja al pasar los segmentos de establecimiento, de modo que ambos extremos acuerden desde el principio segmentos que, ya empaquetados en IP, quepan en la MTU del túnel. Es un parche pragmático — la capa de Internet retocando una negociación de transporte — y precisamente por pragmático, omnipresente en routers VPN como los de Meridiano.

Habrás notado que en toda la lección hemos manejado prefijos (/24), máscaras (255.255.255.0) y redes "privadas" (192.168.x.x) con la comprensión intuitiva del módulo 2. Es suficiente para leer tablas de rutas, pero detrás hay un mundo con reglas propias: cómo se estructura exactamente una dirección IPv4, cómo se calculan y dividen subredes a medida (¿y si Meridiano abre una tercera sede y quiere trocear su espacio de direcciones con precisión?), por qué esas direcciones privadas necesitan NAT para salir a Internet, y cómo IPv6 replantea el juego entero. Todo eso es exactamente el módulo 5, y no lo adelantamos: quédate con que el direccionamiento es la otra mitad de esta capa, tan grande que merece módulo propio.

• Creer que solo los routers tienen tabla de rutas. Todo dispositivo con IP la tiene y la consulta en cada envío. Muchos problemas "de red" son en realidad una tabla de rutas incorrecta en el propio equipo.
• Olvidar el longest prefix match. La tabla no se lee de arriba abajo: gana la ruta más específica. Una ruta /24 errónea "secuestra" tráfico aunque la ruta por defecto sea correcta — clásico tras instalar un cliente VPN que inyecta rutas.
• Confundir "En vínculo"/ausencia de via con un error. Significa entrega directa en la red local, sin gateway. Es lo correcto para tu propio /24.
• Diagnosticar "no hay Internet" sin mirar la ruta por defecto. "Veo la impresora pero no la web" casi siempre es ruta por defecto ausente/errónea o su gateway caído. ip route / route print antes que reiniciar nada.
• Bloquear todo ICMP "por seguridad". ICMP no es solo ping: transporta los avisos que necesita Path MTU Discovery. Filtrarlo entero crea agujeros negros de MTU — el fallo de "la VPN va, pero los ficheros grandes no".
• Consejo: aprende a usar ip route get <destino>: pregunta al kernel su decisión exacta para un destino concreto, sin generar tráfico. Es la manera más rápida de verificar "¿por dónde saldría este paquete?".

Con la tabla del router de Valencia mostrada en la lección (tres rutas: default via operador dev wan0; 192.168.10.0/24 dev lan0; 192.168.20.0/24 dev tun0), indica interfaz de salida y siguiente salto (si lo hay) para paquetes destinados a: (a) 192.168.10.21 (PC de Marta), (b) 192.168.20.5 (PC de Jon), (c) 93.184.216.34 (un servidor web de Internet), (d) 192.168.30.7 (una red que no existe en Meridiano).

El portátil de Ana muestra en route print dos rutas por defecto: una por Ethernet (gateway 192.168.10.1, métrica 25) y otra por Wi-Fi (gateway 192.168.10.1, métrica 50). (a) ¿Por qué interfaz sale su tráfico hacia Internet y por qué? (b) Ana desconecta el cable: ¿qué ocurre con su navegación? (c) ¿Por qué para llegar al servidor .10 la métrica de estas dos rutas es irrelevante como criterio primero?

Desde Bilbao, Jon puede hacer ping al servidor .10 y abrir páginas ligeras de la intranet, pero la descarga de un PDF de 8 MB se queda colgada siempre. El administrador descubre que el cortafuegos perimetral de Valencia descarta todo el tráfico ICMP entrante y saliente. Explica la cadena completa del fallo (qué paquetes mueren, qué aviso no llega, por qué el ping sí funciona) y propone dos soluciones distintas.

Ejercicio 1: (a) Ruta 192.168.10.0/24 dev lan0: sale por lan0, sin siguiente salto (entrega directa por ARP). (b) Ruta 192.168.20.0/24 dev tun0: sale por el túnel VPN hacia el router de Bilbao. (c) Ninguna ruta específica encaja → default: sale por wan0 hacia el router del operador. (d) También cae en default y sale por wan0: el router de Valencia no sabe que esa red "no existe"; la entregará al operador y algún router del camino acabará devolviendo un ICMP de destino inalcanzable. Moraleja: la ruta por defecto atrapa todo lo desconocido, exista o no.

Ejercicio 2: (a) Por Ethernet: ambas rutas son igual de específicas (0.0.0.0/0), así que desempata la métrica y 25 < 50. (b) La ruta por Ethernet desaparece (la interfaz pierde la portadora, 04-02) y el tráfico pasa a la ruta por defecto del Wi-Fi; la navegación continúa, quizá algo más lenta — las conexiones establecidas pueden cortarse al cambiar el camino, pero las nuevas fluyen. (c) Porque para 192.168.10.10 existe una ruta más específica (192.168.10.0/24, "En vínculo") que gana por longest prefix match antes de que la métrica entre en juego; la métrica solo desempata entre rutas igual de específicas (aquí, entre las dos rutas locales si ambas interfaces están en el mismo /24).

Ejercicio 3: Cadena del fallo: (1) el servidor .10 responde a la descarga con paquetes grandes (1500 bytes, DF activado); (2) el router de Valencia no puede meterlos en tun0 (MTU 1436) y los descarta, generando el ICMP "fragmentación necesaria"; (3) el cortafuegos mata ese ICMP, así que el servidor nunca se entera y retransmite una y otra vez paquetes igual de grandes → conexión colgada (agujero negro de MTU). El ping funciona porque sus paquetes son pequeños (decenas de bytes) y caben de sobra en el túnel; las páginas ligeras, parecido. Soluciones: (1) afinar el cortafuegos para permitir al menos los ICMP de "fragmentación necesaria" (no hace falta abrir todo ICMP), restaurando Path MTU Discovery; (2) activar MSS clamping en los routers del túnel, para que ambos extremos negocien desde el handshake segmentos que quepan en la MTU de tun0. (Una tercera vía, menos elegante: bajar la MTU en los equipos finales.)

La capa de Internet es el corazón de TCP/IP: IP entrega sin garantías, ICMP avisa cuando algo se tuerce, y la función de encaminamiento — ejecutada por todos los dispositivos, no solo los routers — decide cada salto consultando la tabla de rutas por prefijo más específico y métrica. Ya sabes leer esa tabla en sus dos dialectos (ip route, route print), reconocer la ruta por defecto como frontera entre "mi red" y "el mundo", y anticipar el choque entre paquetes grandes y la MTU del túnel VPN, con ICMP y el MSS como amortiguadores. También sabes qué hemos aplazado a propósito: la anatomía fina de las direcciones y las subredes, que llenará el módulo 5. Antes, seguimos subiendo la pila: la siguiente parada es la capa de transporte, donde dejaremos de mover paquetes entre máquinas para conectar procesos entre sí — con sockets, estados de conexión y las decisiones TCP/UDP vistas desde el teclado de un desarrollador.