Explora la Interacción de Capa de Red con ping y arp en Linux

Introducción

En este laboratorio, explorará la interacción fundamental entre la capa de red (Capa 3) y la capa de enlace de datos (Capa 2) en un entorno Linux. Utilizará las utilidades de línea de comandos comunes ping y arp para observar el Protocolo de Resolución de Direcciones (ARP) en acción. El objetivo principal es comprender cómo su sistema resuelve las direcciones IP a direcciones MAC físicas para los dispositivos en la red local y cómo maneja la comunicación con hosts remotos.

Comenzará inspeccionando el estado de la caché ARP. Luego, utilizará ping para comunicarse con un dispositivo local (su puerta de enlace predeterminada) y un dispositivo remoto (google.com). Al observar la caché ARP antes y después de estas acciones, verá cómo su sistema utiliza las direcciones MAC para la comunicación local y confía en la puerta de enlace predeterminada para el tráfico remoto.

Ver la Caché ARP Inicial con arp -a

En este paso, inspeccionará el estado inicial de la caché del Protocolo de Resolución de Direcciones (ARP) de su sistema. La caché ARP es un componente de red crucial que almacena las correspondencias entre las direcciones de Capa 3 (IP) y sus correspondientes direcciones de Capa 2 (MAC) para los dispositivos en la misma red local.

Primero, comprobemos el estado actual de la caché ARP utilizando el comando arp. La opción -a indica al comando que muestre todas las entradas actuales.

En su terminal, que ya se encuentra en la ruta ~/project, ejecute el siguiente comando:

arp -a

Probablemente verá una o más entradas. Es común que la puerta de enlace predeterminada ya esté presente en la caché. Su salida puede parecerse a esto:

_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0

Es importante tener en cuenta que, debido a la naturaleza virtualizada del entorno LabEx, no siempre es posible borrar completamente la caché ARP. Por lo tanto, es probable que vea una caché pre-poblada desde el principio. En una configuración típica no virtualizada, sería más probable ver una entrada vacía o <incomplete> para la puerta de enlace antes de la primera comunicación.

Esta salida muestra el estado inicial de nuestra caché ARP. Sirve como línea de base para nuestros próximos pasos, donde activaremos la actividad de red y observaremos cómo se utiliza esta tabla.

Ping a un Dispositivo Local para Desencadenar una Solicitud ARP

En este paso, utilizará el comando ping para iniciar la comunicación con otro dispositivo en su red local. Esta acción utilizará la correspondencia del Protocolo de Resolución de Direcciones (ARP) si se requiere una. Cuando su sistema intenta enviar un paquete a una dirección IP local, primero verifica su caché ARP. Si no encuentra una dirección MAC correspondiente, envía una solicitud ARP de difusión (broadcast). Si la entrada ya existe, utilizará la dirección MAC almacenada en caché.

Para realizar esto, primero necesitamos identificar la dirección IP de un dispositivo en la red local. El objetivo más confiable en este entorno es su puerta de enlace predeterminada (el router virtual). Puede encontrar su dirección IP inspeccionando la tabla de enrutamiento.

En su terminal, ejecute el siguiente comando para mostrar la tabla de enrutamiento:

ip route show

La salida le mostrará la ruta predeterminada. Busque la línea que comienza con default via. La dirección IP que aparece allí es su puerta de enlace.

default via 172.16.50.253 dev eth0 ...
...

De la salida de ejemplo anterior, la dirección IP de la puerta de enlace es 172.16.50.253. Ahora, utilice esta dirección IP para enviar algunos paquetes ping. La opción -c 4 le indica a ping que envíe exactamente 4 paquetes y luego se detenga. Reemplace 172.16.50.253 con la IP de puerta de enlace real que encontró.

ping -c 4 172.16.50.253

Debería ver una respuesta exitosa para cada paquete, lo que confirma que su sistema pudo comunicarse con la puerta de enlace.

PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms

--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms

Esta simple acción ha obligado a su sistema a realizar una búsqueda ARP. En el siguiente paso, inspeccionaremos nuevamente la caché ARP para ver el resultado.

Verificar la Resolución Local de IP a MAC en la Caché ARP

En este paso, volverá a examinar la caché ARP para ver el resultado directo del comando ping que ejecutó anteriormente. Dado que su sistema se comunicó con éxito con la puerta de enlace local, debe haber tenido una correspondencia válida de dirección IP a MAC. Veamos si la tabla ha cambiado.

Inspeccionemos la caché ARP nuevamente. En su terminal, ejecute el mismo comando que en el primer paso:

arp -a

Esta vez, la salida será diferente solo si la entrada no estaba ya completa. En nuestro caso, dado que la entrada ya se resolvió en el Paso 1, la salida será idéntica.

_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0

Compare esta salida con la del Paso 1. Es idéntica. Esto se debe a que la entrada ARP para la puerta de enlace ya estaba completa antes de que enviáramos el ping. Su sistema no necesitó realizar una nueva solicitud ARP; simplemente confió en la información que ya estaba en la caché.

Esto demuestra un principio clave: la caché ARP evita solicitudes ARP redundantes. Si la entrada hubiera estado <incomplete> (incompleta) o faltante, este comando ping la habría poblado, y habría visto un cambio en la salida.

Ping a un Host Externo para Involucrar la Puerta de Enlace Predeterminada

En este paso, pasará de comunicarse con un dispositivo local a comunicarse con un host en Internet. Esto demuestra un concepto fundamental de redes: cómo su computadora utiliza su puerta de enlace predeterminada para alcanzar destinos fuera de su propia red local.

Cuando la dirección IP de destino no está en la misma subred que su computadora, su sistema sabe que no puede enviar el paquete directamente. En su lugar, debe enviar el paquete a su puerta de enlace predeterminada designada. La puerta de enlace (un router) es responsable de reenviar el paquete hacia su destino final a través de Internet.

Para ver esto en acción, hará ping a un host externo conocido, google.com.

En su terminal, ejecute el siguiente comando:

ping -c 4 google.com

Verá que el dominio google.com se resuelve a una dirección IP, y luego recibirá respuestas de esa dirección.

PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms

A pesar de que se comunicó con éxito con google.com, su computadora no realizó una solicitud ARP para la dirección IP de Google. Solo necesitó la dirección MAC de su puerta de enlace local, que ya encontró en los pasos anteriores. En el siguiente paso, analizará la caché ARP para confirmar este comportamiento.

Analizar la Caché ARP para Comunicación Remota

En este paso final, analizará la caché ARP una última vez para confirmar cómo su sistema maneja la comunicación con hosts remotos. Esto solidificará la distinción entre la comunicación de red local y remota y resaltará el papel de la puerta de enlace predeterminada.

Ahora que ha hecho ping correctamente a google.com, volvamos a comprobar la caché ARP. En su terminal, ejecute el comando arp -a:

arp -a

Examine cuidadosamente la salida. Debería ser idéntica al estado de la caché de los pasos anteriores.

_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0

Notará que no hay ninguna entrada para google.com o su dirección IP (por ejemplo, 142.250.189.174). La única entrada significativa presente sigue siendo la de su puerta de enlace predeterminada.

Esta es la conclusión clave de este laboratorio. ARP opera en la Capa 2 y solo se utiliza para encontrar direcciones MAC en el segmento de red local. Cuando su computadora envía un paquete a un destino remoto, sabe que el destino no es local, por lo que envía el paquete a la dirección MAC del siguiente salto, es decir, su puerta de enlace predeterminada. El router se encarga de reenviar el paquete IP hacia su destino final. Su computadora no necesita conocer la dirección MAC de google.com; solo necesita conocer la dirección MAC del dispositivo que puede reenviar el paquete por ella.

Resumen

En este laboratorio, exploró la interacción fundamental entre las redes de Capa 3 (IP) y Capa 2 (MAC) utilizando los comandos ping y arp en Linux. Comenzó inspeccionando el estado de la caché del Protocolo de Resolución de Direcciones (ARP) con arp -a, observando que puede contener entradas para dispositivos críticos como la puerta de enlace predeterminada. Al hacer ping a la puerta de enlace local, confirmó que el sistema utiliza esta información en caché para la comunicación local, evitando búsquedas de direcciones redundantes.

Además, investigó cómo difiere la comunicación con un host remoto. Cuando hizo ping a una dirección IP externa, observó que el sistema no realiza una solicitud ARP para el destino final. En su lugar, envía el paquete a la puerta de enlace predeterminada para que sea enrutado fuera de la red local. El análisis final de la caché ARP reforzó este concepto, mostrando que no se agregó ninguna entrada para el host remoto. La única entrada relevante que quedó fue la de la puerta de enlace predeterminada, lo que resalta su papel crucial como intermediario para todo el tráfico destinado a redes externas.