Práctica P1.6: MAC vs IP — quién traduce a quién

Objetivo: entender de verdad la diferencia entre el direccionamiento de Capa 2 - Enlace de Datos (la MAC) y el de Capa 3 - Red (la IP), y cómo ARP y DHCP son los protocolos que los conectan entre sí.

💡 Aclaración antes de empezar: la MAC no es de Capa 1 - Física. La Capa 1 son solo señales eléctricas/ópticas/radio — ahí no hay direcciones de ningún tipo, solo bits viajando por un cable o por el aire. La MAC es la primera dirección que aparece, y es de Capa 2: identifica una tarjeta de red dentro de una red local. La IP es de Capa 3: identifica un equipo dentro de una red (y entre redes, gracias a los routers de P1.7).

Nivel: básico — primer contacto con ARP y DHCP “en vivo”.

Antes de empezar: necesitas tu VM de Debian de la P1.3, en modo puente (igual que en P1.3/P1.4 — aquí sí quieres que la VM esté en la misma red real que tu Host, nada de Red interna como en P1.7), encendida. También necesitarás tcpdump en la VM:

VM$ sudo apt install tcpdump

Escenario

  Host (tu PC del aula)                    VM Debian (modo puente)
┌──────────────────────┐                 ┌──────────────────────┐
│ MAC: aa:bb:cc:...     │ ── misma LAN ── │ MAC: xx:yy:zz:...     │
│ IP:  192.168.3.??     │   del aula      │ IP:  192.168.3.??     │
└──────────────────────┘                 └──────────────────────┘
        ▲                                          ▲
        └──────────── ¿quién traduce IP ↔ MAC? ─────┘
                         ARP (dentro de la LAN)

Sin router de por medio (a diferencia de P1.7): Host y VM están en la misma red local, así que se hablan directamente a nivel de MAC.

Parte 1: dos direcciones para una misma tarjeta

En el Host y en la VM, por separado:

$ ip link show          # tu MAC: "link/ether xx:xx:xx:xx:xx:xx"
$ ip -br a               # tu IP

Parte 2: ¿cómo llegó tu IP? (DHCP, en vivo)

La IP de la VM no vino de fábrica: la pidió por DHCP al arrancar. Repite el proceso a propósito, dentro de la VM:

VM$ sudo dhclient -v enp0s3

Fíjate en las líneas DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK que aparecen.

💡 El detalle clave: el primer mensaje, DHCPDISCOVER, se manda en broadcast a nivel de MAC (ff:ff:ff:ff:ff:ff) — no en broadcast de IP, porque todavía no tienes IP. Sin una dirección MAC, ni siquiera podrías pedir una IP: la MAC es lo único que tienes al arrancar.

Anota la salida (o las líneas relevantes) de dhclient -v.

Parte 3: la tabla ARP — cómo se traduce IP → MAC

Antes de nada, mira tu tabla de vecinos (puede estar vacía):

$ ip neigh

Ahora, desde el Host, haz ping a la VM (o al revés):

HOST$ ping -c3 IP_de_la_VM

Y vuelve a mirar la tabla:

HOST$ ip neigh
# IP_de_la_VM dev enp... lladdr xx:xx:xx:xx:xx:xx REACHABLE

Ha aparecido la MAC de la VM, asociada a su IP. Eso es ARP trabajando: traduce “quiero hablar con esta IP” en “esta es la MAC a la que realmente tengo que enviar la trama”.

Parte 4: captura la conversación ARP con tus propios ojos

Borra lo que ya sabías, a propósito:

HOST$ sudo ip neigh flush all

Abre una segunda terminal en el Host y lanza la captura (todavía sin hacer ping):

HOST$ sudo tcpdump -i <tu_interfaz> -e arp -n

Desde la primera terminal, repite el ping a la VM:

HOST$ ping -c3 IP_de_la_VM

En la terminal de tcpdump deberías ver algo así (pégalo):

... Request who-has IP_de_la_VM tell IP_del_Host, length 28
... Reply IP_de_la_VM is-at xx:xx:xx:xx:xx:xx, length 28

Esa es la pregunta ("¿quién tiene esta IP?") y la respuesta (“yo, y esta es mi MAC”) de ARP, en bruto.

Tabla de datos a entregar

Preguntas de cierre (3-4 líneas cada una)

• El switch del aula reenvía tramas sin saber nada de direcciones IP. ¿Por qué le basta con la MAC? ¿Y por qué el router de la P1.7 necesitaba, además, trabajar con IPs?
• Si clonas una VM sin cambiar su adaptador de red, a veces dos VMs terminan con la misma MAC. ¿Qué problema concreto te daría eso en esta práctica (piensa en la tabla ARP)? ¿Y si en vez de la MAC fuera la IP la que se repitiera?
• ¿Por qué el DHCPDISCOVER tiene que ir en broadcast de MAC (ff:ff:ff:ff:ff:ff) y no puede ir dirigido a una IP concreta?

Entrega

Un único fichero PDF (practica-mac-arp-dhcp-apellido.pdf) o Markdown con:

• La tabla de datos rellena.
• Captura de la salida de dhclient -v (Parte 2).
• Captura de tcpdump -e arp mostrando el Request y el Reply (Parte 4).
• Las respuestas a las preguntas de cierre.
• POR sFTP a nuestro servidor

HAppy Sniffing! ;-)

RUBRICA DE CALIFICACIÓN

Criterios de contenido (100%)

El fichero de entrega debe ser un único PDF (practica-mac-arp-dhcp-apellido.pdf) con la tabla rellena, las capturas de dhclient -v y tcpdump -e arp, y las respuestas. Si falta alguno de estos elementos, se penaliza en el criterio correspondiente.

Escala orientativa

• Excelente (9-10): MAC/IP bien diferenciadas, proceso DHCP documentado, tabla ARP antes/después clara, captura tcpdump con request y reply legibles, preguntas con razonamiento técnico propio.
• Notable (7-8.9): todo presente con algún detalle menor (captura parcial, un dato de la tabla incompleto), preguntas correctas pero algo genéricas.
• Suficiente (5-6.9): falta uno de los tres bloques (DHCP, ARP antes/después, o captura tcpdump), preguntas mínimas sin justificar.
• Insuficiente (<5): sin evidencia de dhclient/tcpdump, tabla vacía, o confusión persistente entre MAC e IP (o entre Capa 1 y Capa 2).

“Recuerda … KISS!” :-)