Empezamos el recorrido por la pila TCP/IP desde abajo, por la capa que casi nunca sale en los diagramas de aplicaciones pero sin la cual ningún bit se mueve: la capa de acceso a la red. En OSI eran dos capas (física y enlace, que ya estudiaste en 03-02 y 03-03); TCP/IP las funde en una y, sobre todo, la deja deliberadamente abierta: no dicta cómo debe ser, solo exige que sea capaz de llevar paquetes IP hasta el siguiente salto. Esta lección explica esa decisión de diseño y, sobre todo, te enseña a ver y manejar la capa en un sistema real: las interfaces de red, su estado, su MTU y cómo se materializan en el router de Valencia. Es importante porque las interfaces son la frontera física de la pila: cuando algo "no tiene red", lo primero que un profesional comprueba es esta capa.

1. Qué agrupa la capa de acceso a la red
2. Por qué TCP/IP la deja "abierta": IP sobre cualquier cosa
3. Las interfaces de red: la capa hecha objeto
4. Interfaces en la práctica: ip link y compañía
5. La MTU: una propiedad de cada interfaz
6. Caso Meridiano: las interfaces del router de Valencia

La capa de acceso a la red (también llamada link layer, capa de enlace de TCP/IP o network interface layer, según el libro) reúne todo lo necesario para entregar un paquete IP al siguiente dispositivo del camino, dentro de un mismo enlace:

• Lo físico (03-02): medios, señales, codificación, conectores — el cable Cat 6 de Marta, la fibra del operador, las ondas del punto de acceso Wi-Fi.
• El enlace (03-03): tramas, direcciones MAC, acceso al medio, detección de errores con FCS, VLANs.
• Y el pegamento entre IP y el enlace: ARP (02-02), que traduce la IP del siguiente salto a la MAC a la que dirigir la trama.

No vamos a repetir nada de eso — ya lo dominas. Lo que cambia aquí es el punto de vista: para TCP/IP, todo ese mundo es un único servicio con un contrato mínimo:

"Dame un paquete IP y la IP del siguiente salto, y yo lo entrego por este enlace. Cómo lo haga es asunto mío."

Por eso muchas RFC ni siquiera detallan esta capa: cada tecnología (Ethernet, Wi-Fi, PPP...) tiene su propio estándar, y TCP/IP solo define cómo encajar IP encima de cada una (existe literalmente una RFC para "IP sobre Ethernet", otra para "IP sobre Wi-Fi", e incluso una humorística para "IP sobre palomas mensajeras" — la RFC 1149, publicada un 1 de abril, que dice mucho del espíritu pragmático y con humor de la comunidad).

Recuerda la cintura del reloj de arena de 04-01: debajo de IP puede haber cualquier tecnología. Eso no es un accidente, es el requisito fundacional: TCP/IP nació para interconectar redes heterogéneas (cable, radio, satélite), así que no podía casarse con ninguna.

La consecuencia práctica se ve en un solo día de trabajo en Meridiano:

Y si Marta trabaja desde el tren con el móvil compartiendo 4G/5G, su paquete empieza su vida sobre radio celular y acaba sobre Ethernet — sin que ninguna aplicación ni ningún protocolo de capas superiores cambie una coma. La capa de acceso a la red se renueva en cada salto; IP la atraviesa entera. Esa es la división de trabajo: la capa de acceso resuelve "el siguiente metro" y la capa de Internet (siguiente lección) resuelve "el camino completo".

Si en el módulo 3 la capa 1 y 2 eran conceptos, en un sistema real la capa de acceso a la red se toca a través de un objeto concreto: la interfaz de red. Una interfaz es el punto por el que la pila TCP/IP del sistema operativo se conecta a un enlace. Puede ser:

• Física: una tarjeta Ethernet, un adaptador Wi-Fi. Tiene MAC "de fábrica", cable o antena.
• Virtual: creada por software. Las más comunes:
  • Loopback (lo, la famosa 127.0.0.1): la interfaz con la que la máquina se habla a sí misma; nunca toca ningún cable.
  • Interfaces de túnel (VPN): la VPN de Meridiano aparece en cada router como una interfaz más, aunque debajo no haya un cable propio sino paquetes cifrados viajando por Internet.
  • Subinterfaces VLAN: una interfaz física puede desdoblarse lógicamente (una por VLAN).

La idea clave para tu modelo mental: para las capas superiores, todas las interfaces son iguales. La tabla de rutas (lo veremos en 04-03) decide "este paquete sale por tal interfaz", y le da igual que esa interfaz sea una tarjeta Ethernet o un túnel VPN. La interfaz es la frontera de la pila: por encima de ella, todo es software del kernel; por debajo, driver, hardware y medio.

En Linux (como el servidor de la intranet), la herramienta moderna es el comando ip. Su subcomando link opera exactamente en la capa de acceso a la red — enlaces, no direcciones IP.

Leámoslo línea a línea, porque cada campo cuenta algo:

• 1: / 2: — índice de la interfaz (un número interno del kernel).
• lo / enp3s0 — nombre de la interfaz. lo es la loopback. enp3s0 sigue el esquema de nombres predecibles de Linux moderno: en = Ethernet, p3s0 = posición física en la placa (bus PCI 3, slot 0). Verás también eth0 (esquema clásico), wlan0/wlp2s0 (Wi-Fi, wl = wireless LAN), tun0/wg0 (túneles VPN). En Windows, los nombres son descriptivos: "Ethernet", "Wi-Fi", y se listan con ipconfig /all.
• <BROADCAST,MULTICAST,UP,LOWER_UP> — capacidades y estado. Los dos que importan para diagnóstico:
  • UP: la interfaz está administrativamente habilitada (alguien la activó por configuración).
  • LOWER_UP: hay portadora — el nivel físico detecta enlace (cable conectado a un switch encendido, Wi-Fi asociado). Es el equivalente al LED de link del que hablamos en 03-02.
• mtu 1500 — lo vemos en el apartado siguiente.
• state UP — resumen operativo del estado.
• link/ether aa:bb:cc:00:10:10 — la dirección MAC de la interfaz (02-02); brd ff:ff:... es la dirección de difusión del enlace.

La combinación de los dos flags de estado es una mini-tabla de diagnóstico en sí misma:

Dos operaciones administrativas básicas (requieren privilegios):

Esto es lo primero que se mira cuando un equipo "no tiene red": antes de sospechar de IP, de DNS o del servidor, comprueba que la interfaz existe, está UP y tiene LOWER_UP. Si esta capa falla, todo lo de arriba falla — es la lección de dependencia vertical que ya conoces de OSI, aplicada al mundo real.

En 03-04 viste la MTU (Maximum Transmission Unit) al hablar de fragmentación. Ahora podemos situarla con precisión en el sistema: la MTU es una propiedad de cada interfaz, visible en la salida de ip link que acabamos de leer.

• enp3s0: mtu 1500 — 1500 bytes es la MTU clásica de Ethernet: el paquete IP más grande que cabe en una trama.
• lo: mtu 65536 — la loopback no tiene medio físico real, así que puede permitirse tramas enormes.
• Una interfaz de túnel VPN suele mostrar una MTU menor (p. ej. 1400-1460): el túnel añade sus propias cabeceras al paquete, y ese sobrecoste hay que descontarlo del 1500 del enlace real por el que viaja el túnel.

Cada interfaz puede tener una MTU distinta, y el kernel la respeta al construir paquetes que salen por ella. Qué pasa cuando un paquete es más grande que la MTU del camino — y por qué la VPN de Meridiano es el sitio donde esto muerde — lo veremos en la próxima lección, porque la reacción (fragmentar o avisar) es trabajo de la capa de Internet. Aquí quédate con el reparto: la interfaz declara el límite; la capa de Internet decide qué hacer con él.

Los routers son el mejor sitio para ver que "interfaz" es el concepto central de esta capa, porque tienen varias y de naturaleza distinta. El router de Valencia (192.168.10.1) tiene, conceptualmente, estas:

• lan0 — interfaz física hacia el switch de la oficina. Es la puerta de enlace que todos los equipos de Valencia tienen configurada (192.168.10.1). Por ella entran las tramas de la VLAN 10 corporativa (y, según el diseño de 03-03, el tráfico de la VLAN 20 de invitados llega etiquetado por el mismo enlace troncal).
• wan0 — interfaz física hacia el operador. Tecnología distinta (fibra), dirección IP pública, mundo exterior.
• tun0 — la interfaz virtual del túnel VPN hacia Bilbao. Para la tabla de rutas del router es una interfaz como las demás ("para llegar a 192.168.20.0/24, sal por tun0"), pero no tiene cable propio: cada paquete que "sale" por tun0 es cifrado y reenviado dentro de paquetes normales que salen por wan0. Es la materialización, ahora con nombre técnico, de la VPN conceptual del módulo 1 — y nota su MTU reducida.

El router de Bilbao (192.168.20.1) es el espejo: su lan0 hacia el switch de Jon, su wan0 hacia su operador y su tun0 apuntando a Valencia. Cuando en 04-03 leamos tablas de rutas, estas interfaces serán la columna final de cada ruta: toda decisión de encaminamiento termina en un "sal por esta interfaz".

• Confundir "sin cable" con "deshabilitada". UP sin LOWER_UP = problema físico (cable, puerto del switch, asociación Wi-Fi); interfaz en DOWN = alguien la apagó por software. El tratamiento es completamente distinto: en el primer caso revisas hardware, en el segundo, configuración.
• Creer que una interfaz virtual es "menos real". Para la pila, tun0 es tan interfaz como lan0: tiene estado, MTU y rutas que salen por ella. La mitad de los problemas de VPN se diagnostican exactamente igual que los de una tarjeta física: ¿está la interfaz arriba? ¿qué MTU tiene? ¿hay rutas que la usen?
• Buscar eth0 en un Linux moderno y concluir que "no hay red". Los nombres predecibles (enp3s0, wlp2s0) desconcertaron a toda una generación de administradores. Lista siempre con ip link show en lugar de asumir nombres.
• Olvidar que Wi-Fi y Ethernet son la misma capa pero no el mismo enlace. Un portátil con cable y Wi-Fi activos tiene dos interfaces, cada una con su MAC, su estado y potencialmente su propia red. Muchos "va lento" se explican porque el tráfico sale por la interfaz que no esperabas.
• Tocar la MTU sin motivo. La MTU por defecto (1500 en Ethernet) es correcta casi siempre. Solo tiene sentido ajustarla en escenarios concretos como túneles — y eso, mejor tras entender la lección siguiente.
• Consejo: ante "no tengo red", diagnostica de abajo arriba empezando aquí: ip link (¿interfaz UP y con portadora?) antes que ip addr, antes que ping, antes que culpar al servidor. Te ahorrará horas.

En el servidor de la intranet, un administrador junior ejecuta ip link show y obtiene:

Los usuarios reportan que la intranet no responde. (a) ¿La interfaz está habilitada administrativamente? (b) ¿Qué indica NO-CARRIER (ausencia de LOWER_UP)? (c) ¿Cuáles son las dos comprobaciones físicas más probables que resolverán el caso?

Jon, desde Bilbao, descarga un documento del servidor .10 a través de la VPN. Enumera, en orden, las interfaces (con su tipo: física LAN, física WAN o virtual de túnel) por las que el paquete de petición sale en su viaje: PC de Jon → router de Bilbao → router de Valencia → servidor. ¿Cuántas tramas distintas habrá encapsulado, como mínimo, ese único paquete IP?

La interfaz tun0 del router de Valencia muestra mtu 1436 mientras que wan0 muestra mtu 1500. Explica con tus palabras por qué la MTU del túnel es menor, y qué representa aproximadamente la diferencia de 64 bytes.

Ejercicio 1: (a) Sí: el flag UP está presente, así que administrativamente está habilitada (el state DOWN final refleja el estado operativo, no el administrativo). (b) NO-CARRIER significa que no hay señal física: la tarjeta no detecta enlace al otro extremo del cable. (c) Comprobar el cable entre el servidor y el switch (desconectado o dañado) y el puerto del switch (apagado, averiado o deshabilitado). No tiene sentido revisar IP, DNS ni el servicio web hasta recuperar la portadora: sin capa de acceso, nada de arriba funciona.

Ejercicio 2: Salidas del paquete: (1) interfaz Ethernet física del PC de Jon hacia el switch de Bilbao; (2) en el router de Bilbao, la decisión de rutas lo manda por la interfaz virtual de túnel (tun0) — y el paquete cifrado resultante sale físicamente por su interfaz WAN física hacia el operador; (3) en el router de Valencia, tras descifrarse, sale por su interfaz LAN física hacia el switch y el servidor .10. Tramas distintas: al menos tres visibles para Meridiano (Ethernet en la LAN de Bilbao, el enlace WAN del operador, Ethernet en la LAN de Valencia) — y en realidad más, porque dentro de Internet cada salto entre routers del operador re-encapsula de nuevo. La cabecera IP original (protegida dentro del túnel) sobrevive intacta; las tramas se renuevan en cada enlace.

Ejercicio 3: Los paquetes que "salen" por tun0 no viajan solos: el túnel los cifra y los envuelve con cabeceras adicionales (las del protocolo VPN más las nuevas cabeceras IP/transporte exteriores), y el resultado debe seguir cabiendo en los 1500 bytes de MTU del enlace real (wan0). Los ~64 bytes de diferencia son, aproximadamente, ese sobrecoste de encapsulación del túnel. Si tun0 mantuviera MTU 1500, cada paquete grande superaría los 1500 al añadirle la envoltura, forzando fragmentación o pérdidas — el tipo de problema que analizaremos en la próxima lección.

La capa de acceso a la red es el gran "contenedor abierto" de TCP/IP: agrupa lo físico y el enlace que ya estudiaste, y renuncia deliberadamente a imponer una tecnología para que IP pueda viajar sobre Ethernet, Wi-Fi, fibra o 5G indistintamente — renovándose en cada salto mientras el paquete la atraviesa entera. En la práctica, esta capa se ve y se administra a través de las interfaces: física o virtual, cada una con su nombre, su MAC, su estado (UP/LOWER_UP) y su MTU, y las del router de Valencia (lan0, wan0, tun0) resumen bien su variedad. Con la frontera inferior de la pila dominada, subimos un peldaño hacia la capa que convierte muchos enlaces sueltos en una sola red mundial: la capa de Internet, donde viven IP, ICMP y — ahora sí, línea a línea — las tablas de rutas.