La lección anterior terminó con una frontera: cuando el PC de Marta envía datos a Bilbao, su trama Ethernet muere en el router de Valencia, porque las direcciones MAC y los protocolos de enlace no salen del segmento local. A partir de ahí toma el relevo la familia que estudiamos hoy: los protocolos de red, cuya misión es llevar paquetes entre redes distintas, elegir el camino y avisar cuando algo va mal. El protagonista absoluto es IP (Internet Protocol), el protocolo que da nombre a Internet y sin el cual no existiría; le acompaña ICMP, su servicio de mensajería de errores y diagnóstico (el que hay detrás del ping que ya usamos en el módulo 1). En esta lección abriremos el paquete IP para ver su sintaxis, entenderemos por fin con rigor qué es una dirección IP (su parte de red y su parte de host), descubriremos cómo decide un router el camino con su tabla de rutas, y seguiremos un paquete de Meridiano en su viaje completo de Valencia a Bilbao por la VPN.

1. La misión de los protocolos de red: unir redes
2. IP: el protocolo que mueve Internet
3. El paquete IP por dentro
4. Direcciones IP con rigor: parte de red y parte de host
5. Enrutamiento: cómo decide el camino un router
6. La puerta de enlace predeterminada
7. ICMP: los mensajes de servicio de la red
8. Caso guiado: un paquete de Valencia a Bilbao por la VPN

Internet no es "una red": es una red de redes — millones de redes locales como las de Valencia y Bilbao, interconectadas. Los protocolos de red existen para que un paquete pueda nacer en cualquiera de ellas y morir en cualquier otra, cruzando por el camino redes intermedias que no conocen ni al emisor ni al receptor.

Para eso resuelven tres problemas que el enlace de datos no puede resolver:

• Direccionamiento universal: hace falta una dirección lógica y jerárquica (la dirección IP) que diga en qué red está un equipo, no solo quién es. La MAC identifica la tarjeta, pero no dice nada de dónde está: es como el DNI de una persona frente a su dirección postal.
• Encaminamiento (routing): en cada cruce del camino, alguien (un router) debe decidir por dónde reenviar el paquete para acercarlo a su destino.
• Notificación de problemas: si un paquete no puede entregarse, la red debe poder avisar al emisor (trabajo de ICMP).

Retomando el símil postal: el enlace de datos era el reparto dentro del barrio; los protocolos de red son el sistema postal entre ciudades: clasifican por código postal (la parte de red de la IP), encaminan de oficina en oficina (de router en router) y devuelven la carta con un sello de "destinatario desconocido" cuando procede (ICMP).

IP (Internet Protocol) es el protocolo de red universal: todo lo que viaja por Internet —y por las LAN de Meridiano— viaja dentro de paquetes IP. Su versión dominante sigue siendo IPv4 (direcciones de 32 bits, las 192.168.x.x que venimos usando); su sucesora, IPv6, la presentaremos en la lección 05-04. Aquí trabajaremos con IPv4.

Dos decisiones de diseño definen el carácter de IP, y conviene entenderlas porque explican el resto de la pila:

• IP es no orientado a conexión: cada paquete viaja por su cuenta, con sus direcciones completas, sin que exista una "llamada establecida" previa. Dos paquetes del mismo fichero pueden incluso seguir caminos distintos y llegar desordenados.
• IP es de "mejor esfuerzo" (best effort): hace todo lo posible por entregar cada paquete, pero no garantiza nada: ni la entrega, ni el orden, ni que no haya duplicados. Si un router se congestiona, descarta paquetes sin pedir perdón.

¿Un protocolo que puede perder datos, en la base de todo Internet? Sí, y es una genialidad: mantener garantías en cada cruce de la red sería carísimo y lento. IP se mantiene simple y veloz, y las garantías se añaden solo donde hacen falta y solo en los extremos, que es exactamente el trabajo de TCP (lección 02-04). Cada familia, a lo suyo.

Como hicimos con la trama Ethernet, diseccionemos la sintaxis del paquete IP (simplificada a sus campos esenciales):

Tres campos merecen comentario detallado:

• IP origen e IP destino viajan de extremo a extremo sin cambiar (dejamos a un lado NAT, que veremos en la lección 05-03). Compáralo con las MAC de la trama, que cambian en cada salto: es la diferencia clave entre ambas familias.
• Protocolo es el equivalente al campo "Tipo" de Ethernet, un nivel más arriba: le dice al receptor a quién entregar los datos al desencapsular (TCP, UDP, ICMP...). La encapsulación de la lección 02-01 va encajando pieza a pieza.
• TTL (Time To Live) es un seguro contra paquetes zombis: sale del emisor con un valor (típicamente 64 o 128) y cada router que lo reenvía lo reduce en 1. Si llega a 0, el router de turno lo descarta y avisa al emisor con un mensaje ICMP. Sin TTL, un error de configuración que creara un bucle entre routers llenaría la red de paquetes girando para siempre.

En el módulo 1 presentamos la dirección IP como "el número que identifica a un equipo en la red". Es hora de afinar: una dirección IPv4 son 32 bits que se escriben como cuatro números de 0 a 255 separados por puntos (192.168.10.21), y que internamente se dividen en dos partes:

• La parte de red: los bits de la izquierda, comunes a todos los equipos de la misma red. Es el "código postal".
• La parte de host: los bits de la derecha, que distinguen a cada equipo dentro de esa red. Es el "número de portal".

¿Dónde termina una parte y empieza la otra? Lo indica la máscara de subred que acompaña a toda IP. De momento nos basta con su forma más común en pymes, 255.255.255.0 (también escrita /24): significa que los tres primeros números son la red y el cuarto es el host. El estudio en profundidad de las máscaras y el subnetting llegará en la lección 05-02; con el /24 tenemos de sobra para todo este módulo.

Así queda el direccionamiento de Grupo Meridiano:

La consecuencia operativa es inmediata, y es la decisión que todo host toma antes de enviar cualquier paquete:

Esta simple comparación es la bisagra entre las lecciones 02-02 y 02-03: dentro de la red manda el enlace de datos; fuera, empieza el enrutamiento.

Un router es un equipo con al menos dos interfaces de red, cada una en una red distinta, cuyo trabajo es reenviar paquetes de una a otra acercándolos a su destino. Para decidir por dónde, consulta su tabla de rutas: una lista de reglas "para llegar a tal red, sal por aquí".

Esta es la tabla de rutas (simplificada) del router de Valencia, que tiene tres interfaces: la LAN de la oficina, la conexión a Internet y el túnel VPN con Bilbao:

Cómo se lee, fila a fila:

• 192.168.10.0/24 → conectada: "la red de Valencia la tengo enchufada directamente; a esos equipos les entrego yo mismo la trama" (usando ARP, como cualquier host).
• 192.168.20.0/24 → túnel VPN: "todo lo que vaya a Bilbao, por el túnel". Esta ruta es la materialización del enlace lógico punto a punto que dibujamos en la topología del módulo 1: para la tabla de rutas, la VPN es simplemente una interfaz más por la que se alcanza la red 192.168.20.
• 0.0.0.0/0.0.0.0 → router del ISP: la ruta por defecto, que significa "cualquier otra red": todo lo que no encaje en las filas anteriores sale hacia Internet. Sin ella, el router solo conocería sus dos redes y descartaría el resto.

El algoritmo del router para cada paquete que le llega es siempre el mismo:

1. Lee la IP destino del paquete.
2. Busca en la tabla la fila más específica que la contenga (la ruta por defecto solo gana si ninguna otra encaja).
3. Reenvía el paquete por la interfaz indicada, restando 1 al TTL.
4. Si ninguna fila encaja y no hay ruta por defecto, descarta el paquete y lo notifica por ICMP.

En una pyme como Meridiano las rutas se escriben a mano (enrutamiento estático): son tres filas y no cambian nunca. En redes grandes y en Internet, los routers se intercambian rutas automáticamente mediante protocolos de enrutamiento dinámico (OSPF, BGP...), que quedan fuera del alcance de este curso introductorio; nos basta con saber que existen y que hacen a escala planetaria lo que aquí hacemos con tres líneas.

Los hosts también tienen su miniatura de tabla de rutas, reducida casi siempre a una sola decisión: la puerta de enlace predeterminada (default gateway) es la IP del router al que el equipo entrega todo el tráfico destinado fuera de su red local. Es el dato que, junto a la IP y la máscara, completa la configuración mínima de red de cualquier equipo:

Los tres valores cuentan la historia completa: "soy el host .21 de la red 192.168.10.0/24, y todo lo que no sea para mi red se lo doy a 192.168.10.1". Un equipo con IP y máscara correctas pero sin puerta de enlace funciona perfectamente en su LAN... y está ciego para todo lo demás: ni Bilbao, ni Internet. Es una de las averías "misteriosas" más frecuentes en soporte.

IP necesita un compañero para avisar de los problemas: ICMP (Internet Control Message Protocol). No transporta datos de aplicaciones; transporta mensajes de control y error entre equipos y routers. Es el protocolo que trabaja cuando la red te dice algo sobre sí misma. Sus mensajes más importantes:

El ping que conocimos en el módulo 1 es, por dentro, pura mensajería ICMP: envía echo requests y cronometra los echo replies. Desde el PC de Marta hacia la impresora de Bilbao:

Ahora podemos leer esta salida con ojos nuevos:

• tiempo=38ms: la latencia de ida y vuelta hasta Bilbao (compárala con el <1 ms típico dentro de la LAN: el túnel VPN por Internet se nota).
• TTL=62: la impresora respondió con TTL inicial 64, y el paquete de vuelta ha atravesado 2 routers (64 − 62): el de Bilbao y el de Valencia. El TTL de un ping es una pista gratuita de cuántos saltos hay hasta el destino.
• Si en lugar de respuestas viéramos Tiempo de espera agotado (nada contestó) o Host de destino inaccesible (un ICMP destination unreachable), ya sabríamos distinguir entre "el paquete se pierde en silencio" y "alguien me avisa activamente de que no hay camino": dos averías distintas. La metodología completa de diagnóstico llegará en el módulo 6.

Juntemos todas las piezas del módulo hasta ahora. Marta (192.168.10.21) envía un documento a la impresora de Bilbao (192.168.20.40). Viaje completo de un paquete:

1. Decisión en el PC de Marta: compara 192.168.20.40 con su red 192.168.10.0/24 → parte de red distinta → destino remoto → hay que entregárselo a la puerta de enlace, 192.168.10.1.
2. Enlace local en Valencia: el PC resuelve por ARP la MAC del router (no la de la impresora: ARP no cruza redes) y construye la trama: MAC destino = router de Valencia, conteniendo el paquete IP origen 192.168.10.21 → IP destino 192.168.20.40. El switch de Valencia la entrega al router por su puerto 1.
3. Decisión en el router de Valencia: desencapsula la trama, lee la IP destino, consulta su tabla: 192.168.20.0/24 → túnel VPN. Resta 1 al TTL y reenvía el paquete por el túnel. (Por dentro, la VPN cifra el paquete y lo envía por Internet hasta Bilbao, pero para nuestro paquete el túnel es un simple enlace punto a punto, tal y como lo dibujamos en la topología lógica del módulo 1.)
4. Decisión en el router de Bilbao: recibe el paquete por el túnel, lee la IP destino, consulta su tabla: 192.168.20.0/24 → conectada. Resta 1 al TTL, resuelve por ARP la MAC de la impresora y construye una trama nueva para el segmento de Bilbao.
5. Entrega final: el switch de Bilbao entrega la trama a la impresora, que desencapsula y pasa los datos al protocolo superior (campo Protocolo de la cabecera IP).

La observación que lo resume todo: las direcciones IP (origen y destino) no han cambiado en todo el viaje; las tramas y las MAC se han creado y destruido en cada tramo. IP es el viaje completo; el enlace de datos, cada etapa.

• Decir que "el switch enruta" o que "el router está en mi red... y ya". Vocabulario preciso: el switch conmuta tramas dentro de una red usando MACs; el router enruta paquetes entre redes usando IPs. Son operaciones distintas sobre unidades de datos distintas.
• Olvidar (o teclear mal) la puerta de enlace. Síntoma inconfundible: el equipo ve a sus vecinos de LAN pero no sale a otras redes. Antes de sospechar de la VPN o del ISP, un ipconfig/ip addr confirma los tres datos básicos en segundos.
• Esperar que IP garantice la entrega. IP es best effort por diseño: puede descartar, duplicar y desordenar. Si tu aplicación necesita fiabilidad, se la dará TCP (próxima lección), no IP. No es un defecto: es el reparto de trabajo de la pila.
• Interpretar mal un ping fallido. Que un equipo no responda a ping no siempre significa que esté caído: muchos cortafuegos descartan ICMP deliberadamente. El ping que sí responde es información fiable; el que no responde, solo un indicio.
• Consejo: acostúmbrate a mirar el TTL de las respuestas de ping. Valores cercanos a 64 o 128 menos unos pocos saltos te dicen "cerca"; valores muy rebajados, "lejos". Es diagnóstico gratuito en cada ping que lances.

Ejercicio 1. Clasifica estos envíos desde el portátil de Jon en Bilbao (192.168.20.12/24, puerta de enlace 192.168.20.1) como local (entrega directa vía ARP) o remoto (entrega al router), y justifica con la parte de red: a) 192.168.20.40 (impresora de Bilbao); b) 192.168.10.10 (servidor de ficheros de Valencia); c) 203.0.113.80 (servidor web en Internet); d) 192.168.20.1 (el propio router).

Ejercicio 2. Escribe la tabla de rutas del router de Bilbao (interfaces: LAN Bilbao, túnel VPN a Valencia, salida a Internet), siguiendo el formato de la tabla del router de Valencia de esta lección. ¿Qué fila usaría para un paquete dirigido a 192.168.10.10? ¿Y para uno dirigido a 198.51.100.7?

Ejercicio 3. Desde el PC de Marta, ping 192.168.20.40 devuelve respuestas con TTL=62, y ping 192.168.10.10 (servidor de ficheros) devuelve TTL=64. Ambos destinos arrancan con TTL inicial 64. ¿Cuántos routers atraviesa cada respuesta y por qué encaja con la topología de Meridiano?

Solución 1:

• a) Local: 192.168.20.40 comparte parte de red (192.168.20) con Jon → ARP y entrega directa por el switch de Bilbao.
• b) Remoto: parte de red 192.168.10 ≠ 192.168.20 → se entrega al router de Bilbao, que lo mandará por la VPN.
• c) Remoto: 203.0.113.80 no pertenece a 192.168.20.0/24 → al router, que lo sacará por la ruta por defecto hacia Internet.
• d) Local: el router es un vecino más de la LAN (192.168.20.1 está en 192.168.20) → ARP y entrega directa. Que además sea la puerta de enlace no cambia cómo se le habla cuando él mismo es el destino.

Solución 2:

• Paquete a 192.168.10.10: encaja en la fila 192.168.10.0/24 → sale por el túnel VPN hacia Valencia.
• Paquete a 198.51.100.7: no encaja en ninguna red conocida → ruta por defecto, sale hacia Internet por el router del ISP.

Solución 3: La respuesta de la impresora de Bilbao llega con TTL 62 = 64 − 2: ha atravesado 2 routers (Bilbao y Valencia), exactamente los dos extremos del túnel VPN de la topología. La del servidor de ficheros llega con TTL 64 = 64 − 0: ningún router por medio, porque el servidor está en la misma red local que Marta y la entrega es directa por el switch (solo enlace de datos, como vimos en 02-02). Los TTL confirman el plano de red del módulo 1.

Con esta lección los paquetes de Meridiano ya cruzan fronteras. Hemos visto que los protocolos de red convierten muchas redes en una sola: IP aporta el direccionamiento universal —direcciones de 32 bits con su parte de red y su parte de host, que permiten a cada equipo decidir si un destino es local o remoto— y un servicio de paquetes deliberadamente simple, no orientado a conexión y de mejor esfuerzo, con campos tan elocuentes como el TTL. Los routers encadenan el viaje consultando su tabla de rutas (redes conectadas, la ruta a Bilbao por la VPN, la ruta por defecto hacia Internet), los hosts delegan en su puerta de enlace predeterminada, e ICMP pone la voz de la red: los echo de ping, los avisos de destino inaccesible y de TTL agotado. Y hemos confirmado la gran división de trabajo: las IP viajan de extremo a extremo, las tramas viven y mueren en cada tramo. Pero fíjate en que todo lo dicho hoy entrega paquetes a una máquina, no a un programa: en el servidor de Valencia conviven los ficheros compartidos, quizá una web interna y otros servicios, y alguien tiene que llevar cada dato a la aplicación correcta, garantizando además —cuando importa— que no falte ni sobre nada. Ese es el terreno de los puertos, de TCP y de UDP: los Protocolos de Transporte de la próxima lección.