Simular Conectividad de Capa de Red en Linux

Introducción

En este laboratorio, explorará los principios fundamentales de la conectividad de la capa de red en un entorno Linux. Utilizando contenedores Docker para simular dos nodos separados, aprenderá a asignar manualmente direcciones IP estáticas con el comando ip. Luego, utilizará la utilidad ping para probar la ruta de comunicación directa entre estos nodos en una red virtual compartida.

Al configurar primero los nodos en la misma subred, observará una conectividad exitosa. Luego, reconfigurará un nodo a una subred diferente para presenciar un fallo de comunicación predecible: el error 'Destination Host Unreachable' (Host de destino inalcanzable). Este ejercicio práctico proporciona una demostración clara y práctica de cómo las subredes IP rigen la comunicación directa y por qué los dispositivos en redes lógicas diferentes no pueden conectarse sin un router.

Este es un Guided Lab, que proporciona instrucciones paso a paso para ayudarte a aprender y practicar. Sigue las instrucciones cuidadosamente para completar cada paso y obtener experiencia práctica. Los datos históricos muestran que este es un laboratorio de nivel principiante con una tasa de finalización del 99%. Ha recibido una tasa de reseñas positivas del 100% por parte de los estudiantes.

Preparar el Entorno de Laboratorio de Dos Nodos

En este paso, configurará el entorno fundamental para nuestro laboratorio. En lugar de utilizar máquinas virtuales completas, aprovecharemos contenedores Docker ligeros y aislados para simular dos nodos de red separados. Para permitir la comunicación entre ellos, primero crearemos una red Docker personalizada. Esta red virtual actúa como un switch de red físico, colocando ambos nodos en el mismo segmento de comunicación compartido.

Descarguemos la imagen de Ubuntu 22.04 de Docker para los nodos.

docker pull ubuntu:22.04

Primero, creemos la red virtual que utilizarán nuestros dos nodos. La llamaremos lab_net y le asignaremos un rango de direcciones IP específico, lo cual será importante en pasos posteriores.

Ejecute el siguiente comando en su terminal:

docker network create --subnet=192.168.56.0/24 lab_net

Este comando le indica a Docker que cree una nueva red de tipo bridge llamada lab_net y la configura para usar la subred 192.168.56.0/24. Verá un ID único largo para la red como salida, confirmando su creación.

e8c1c2a3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1

A continuación, iniciaremos nuestro primer nodo, un contenedor llamado node1, y lo conectaremos a la red lab_net.

docker run -d --name node1 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity

Analicemos este comando:

docker run: El comando estándar para crear e iniciar un nuevo contenedor.
-d: Ejecuta el contenedor en modo "detached" (separado), lo que significa que se ejecuta en segundo plano.
--name node1: Asigna un nombre simple y fácil de recordar a nuestro contenedor.
--network lab_net: Conecta el contenedor a la red virtual que creamos anteriormente.
--cap-add=NET_ADMIN: Otorga al contenedor la capacidad NET_ADMIN, que es necesaria para modificar la configuración de red, como agregar direcciones IP.
ubuntu:22.04: La imagen de Docker que estamos utilizando, que proporciona un entorno Ubuntu estándar.
sleep infinity: Un comando simple que se ejecuta indefinidamente para mantener el contenedor activo.

Ahora, inicie el segundo nodo, node2, utilizando un comando similar:

docker run -d --name node2 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity

Finalmente, verifiquemos que ambos nodos se están ejecutando correctamente. El comando docker ps lista todos los contenedores en ejecución actualmente.

docker ps

Debería ver una salida similar a la siguiente, confirmando que node1 y node2 están activos y funcionando.

CONTAINER ID   IMAGE          COMMAND                  CREATED          STATUS          PORTS     NAMES
a1b2c3d4e5f6   ubuntu:22.04   "sleep infinity"         5 seconds ago    Up 4 seconds              node2
g7h8i9j0k1l2   ubuntu:22.04   "sleep infinity"         15 seconds ago   Up 14 seconds             node1

Con ambos nodos ejecutándose en la misma red virtual, nuestro entorno de laboratorio está ahora preparado. En los siguientes pasos, configuraremos sus direcciones IP y probaremos su conectividad.

Configurar una IP Estática en el Primer Nodo usando `ip addr`

En este paso, asignará una dirección IP estática a nuestro primer contenedor, node1. Una IP estática es una dirección que se configura manualmente y no cambia, a diferencia de una IP dinámica que a menudo es asignada automáticamente por un servidor DHCP. Para nuestra simulación, el uso de IPs estáticas nos brinda un control preciso sobre la configuración de red.

Realizaremos todas las acciones desde su terminal principal en la máquina host, utilizando el comando docker exec para ejecutar comandos dentro del contenedor node1.

Primero, la imagen base ubuntu:22.04 es muy mínima. Necesitamos instalar las herramientas de red necesarias. Comencemos actualizando la lista de paquetes dentro del contenedor node1:

docker exec node1 apt-get update

Verá la salida mientras el contenedor obtiene la información más reciente de los paquetes.

A continuación, instale el paquete iproute2 (que proporciona el comando ip) y iputils-ping (que proporciona el comando ping que usaremos más adelante).

docker exec node1 apt-get install -y iproute2 iputils-ping

Ahora que las herramientas están instaladas, inspeccionemos la configuración de red actual de node1. La interfaz de red dentro de un contenedor Docker estándar se llama típicamente eth0.

docker exec node1 ip addr show eth0

La salida mostrará los detalles de la interfaz eth0. Es posible que vea una dirección IP ya asignada por el servidor DHCP interno de Docker (por ejemplo, 192.168.56.2). Vamos a agregar nuestra propia IP estática.

9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
       valid_lft forever preferred_lft forever

Ahora, asignemos la dirección IP estática 192.168.56.10 a node1. El /24 es la notación CIDR para la máscara de red 255.255.255.0, que define el tamaño de la red.

docker exec node1 ip addr add 192.168.56.10/24 dev eth0

Este comando no debería producir ninguna salida si tiene éxito. Para confirmar el cambio, ejecute nuevamente el comando ip addr show eth0:

docker exec node1 ip addr show eth0

Ahora debería ver su nueva dirección IP estática listada junto a la original, marcada como secondary. Esto confirma que node1 ahora está configurado con la dirección 192.168.56.10.

9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.56.10/24 scope global secondary eth0
       valid_lft forever preferred_lft forever

Configurar una IP Estática en el Segundo Nodo en la Misma Subred

En este paso, configuraremos nuestro segundo nodo, node2, con una dirección IP estática. Para que dos dispositivos se comuniquen directamente sin un router, deben residir en la misma subred lógica. Asignaremos a node2 una dirección IP de la misma subred 192.168.56.0/24 que utilizamos para node1. Esta configuración imita lógicamente dos PCs conectados con un cable cruzado, donde ambos forman parte de la misma red local.

Primero, al igual que hicimos para node1, necesitamos instalar las herramientas de red necesarias dentro del contenedor node2. Comience actualizando la lista de paquetes:

docker exec node2 apt-get update

A continuación, instale los paquetes iproute2 y iputils-ping en node2:

docker exec node2 apt-get install -y iproute2 iputils-ping

Con las herramientas instaladas, ahora podemos asignar una dirección IP estática a node2. Usaremos 192.168.56.11, que está en la misma subred que node1 (192.168.56.10) pero es una dirección única.

docker exec node2 ip addr add 192.168.56.11/24 dev eth0

Este comando agrega la dirección IP 192.168.56.11 con una máscara de red /24 a la interfaz de red eth0 del contenedor node2. Si el comando es exitoso, no producirá ninguna salida.

Para verificar que la dirección IP se asignó correctamente, inspeccionemos la configuración de red de node2:

docker exec node2 ip addr show eth0

La salida ahora debería mostrar la dirección IP estática recién agregada, marcada como secondary. Esto confirma que node2 está configurado correctamente y listo para el siguiente paso donde probaremos la conectividad.

11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.56.3/24 brd 192.168.56.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.56.11/24 scope global secondary eth0
       valid_lft forever preferred_lft forever

Verificar Conectividad Directa Entre Nodos con `ping`

En este paso, probará la conectividad de red entre node1 y node2. Ahora que ambos nodos tienen direcciones IP en la misma subred, deberían poder comunicarse directamente. Utilizaremos el comando ping, una utilidad de red fundamental que envía un pequeño paquete de datos (una Solicitud de Eco ICMP) a un host de destino y espera una respuesta. Una respuesta exitosa confirma que existe una ruta de red entre los dos dispositivos.

Esta prueba exitosa es análoga a conectar dos PCs con un cable cruzado, donde ambos dispositivos están en el mismo segmento de red local y pueden verse directamente.

Primero, intentemos hacer ping a node2 desde node1. Ejecutaremos el comando ping dentro del contenedor node1, apuntando a la dirección IP de node2, 192.168.56.11.

docker exec node1 ping -c 4 192.168.56.11

Analicemos este comando:

docker exec node1: Ejecuta el siguiente comando dentro del contenedor node1.
ping: La utilidad para probar la conectividad.
-c 4: Una bandera que le dice a ping que envíe exactamente 4 paquetes y luego se detenga. Sin esto, ping se ejecutaría indefinidamente.
192.168.56.11: La dirección IP de destino de node2.

Debería ver una salida exitosa, con respuestas recibidas de node2.

PING 192.168.56.11 (192.168.56.11) 56(84) bytes of data.
64 bytes from 192.168.56.11: icmp_seq=1 ttl=64 time=0.123 ms
64 bytes from 192.168.56.11: icmp_seq=2 ttl=64 time=0.087 ms
64 bytes from 192.168.56.11: icmp_seq=3 ttl=64 time=0.091 ms
64 bytes from 192.168.56.11: icmp_seq=4 ttl=64 time=0.085 ms

--- 192.168.56.11 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.085/0.096/0.123/0.015 ms

La línea "4 packets transmitted, 4 received, 0% packet loss" confirma que la conexión está funcionando. Ahora, verifiquemos la conexión en la otra dirección haciendo ping a node1 desde node2.

docker exec node2 ping -c 4 192.168.56.10

Nuevamente, debería ver una serie exitosa de respuestas, confirmando que la comunicación es bidireccional.

PING 192.168.56.10 (192.168.56.10) 56(84) bytes of data.
64 bytes from 192.168.56.10: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 192.168.56.10: icmp_seq=2 ttl=64 time=0.088 ms
64 bytes from 192.168.56.10: icmp_seq=3 ttl=64 time=0.092 ms
64 bytes from 192.168.56.10: icmp_seq=4 ttl=64 time=0.089 ms

--- 192.168.56.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3081ms
rtt min/avg/max/mdev = 0.088/0.092/0.099/0.004 ms

¡Éxito! Ambos nodos pueden comunicarse entre sí, como si fueran dos computadoras en el mismo segmento de red local.

Reconfigurar el Segundo Nodo a una Subred Diferente

En este paso, romperemos intencionalmente la conectividad directa entre nuestros dos nodos. Haremos esto reconfigurando node2 para que esté en una subred IP completamente diferente a la de node1. Esto simula un escenario donde dos dispositivos están conectados físicamente pero están lógicamente separados en diferentes redes.

Actualmente, node1 está en la subred 192.168.56.0/24. Ahora moveremos node2 a la subred 192.168.58.0/24. Dado que el tercer número (octeto) es diferente (56 vs. 58), estos se consideran subredes separadas.

Para asegurar que node2 esté completamente aislado en la nueva red, primero debemos eliminar todas las direcciones IP existentes de su interfaz eth0. Esto incluye tanto la IP estática que agregamos anteriormente como la IP original que Docker asignó automáticamente. El comando ip addr flush es la herramienta correcta para esta tarea.

docker exec node2 ip addr flush dev eth0

Este comando elimina todas las configuraciones IP de eth0, asegurando un estado limpio. No debería producir ninguna salida si tiene éxito.

Ahora, agreguemos la nueva dirección IP, 192.168.58.11, que pertenece a la nueva subred.

docker exec node2 ip addr add 192.168.58.11/24 dev eth0

Para confirmar los cambios, inspeccionemos nuevamente la configuración de red de node2.

docker exec node2 ip addr show eth0

Verá que todas las direcciones IP antiguas han desaparecido y solo existe la nueva (192.168.58.11). Esto confirma que node2 ya no está en la subred 192.168.56.0/24.

11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.58.11/24 scope global eth0
       valid_lft forever preferred_lft forever

Con node1 en la subred 192.168.56.0/24 y node2 en la subred 192.168.58.0/24, ahora están lógicamente aislados.

Probar Conectividad y Observar Fallo

En este paso final, intentaremos hacer ping entre los nodos nuevamente. Con node2 ahora verdaderamente aislado en una nueva subred, esperamos que la comunicación falle, pero de dos maneras diferentes e importantes que revelan cómo operan las capas de red.

Primero, intentemos hacer ping a la nueva dirección IP de node2 (192.168.58.11) desde node1.

docker exec node1 ping -c 4 192.168.58.11

Observe la salida. El comando fallará por tiempo de espera (timeout), resultando en una pérdida de paquetes del 100%.

PING 192.168.58.11 (192.168.58.11) 56(84) bytes of data.

--- 192.168.58.11 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3076ms

Este tiempo de espera ocurre porque node1 todavía tiene una ruta hacia la red de Docker, por lo que envía el paquete ping. La red lo reenvía a node2. Sin embargo, dado que node2 ya no está en esa red y no tiene una ruta de regreso, no puede enviar una respuesta. El ping desde node1 nunca recibe una respuesta.

A continuación, probemos la otra dirección. Intente hacer ping a node1 desde node2.

docker exec node2 ping -c 4 192.168.56.10

Esta vez, verá un mensaje de error diferente casi de inmediato.

ping: connect: Network is unreachable

El mensaje ping: connect: Network is unreachable es significativo. Es una respuesta inmediata del sistema operativo en node2. Significa que el sistema operativo consultó su tabla de enrutamiento, vio que el destino 192.168.56.10 está en una red a la que no tiene acceso, y se negó incluso a intentar enviar el paquete. Esto es un resultado directo de usar ip addr flush, que eliminó todas las rutas, aislando completamente el contenedor de otras redes.

Este laboratorio ha demostrado exitosamente el papel crítico de la subred IP y el enrutamiento. Cuando los dispositivos están en la misma subred, pueden comunicarse directamente. Cuando están en subredes diferentes, se requiere un dispositivo de Capa 3 como un enrutador con las rutas apropiadas para reenviar el tráfico entre ellos.

Resumen

En este laboratorio, aprendió a simular un entorno de red de dos nodos utilizando contenedores Docker conectados a una red bridge personalizada. Practicó la habilidad esencial de Linux de configurar direcciones IP estáticas en interfaces de red utilizando el comando ip addr. Al asignar direcciones IP de la misma subred a ambos nodos, verificó con éxito la conectividad directa de Capa 3 entre ellos con la utilidad ping, demostrando el requisito fundamental para la comunicación en un segmento de red local.

El laboratorio ilustró además un concepto crítico de redes al reconfigurar un nodo con una dirección IP de una subred diferente después de haber vaciado completamente su configuración de red original. Los intentos posteriores de comunicación a través de ping fallaron con dos resultados distintos: un tiempo de espera (timeout) en una dirección y un error de 'Destino no alcanzable' (Destination Host Unreachable) en la otra. Este resultado demostró efectivamente que los nodos en subredes lógicas diferentes no pueden comunicarse directamente sin un enrutador, y resaltó cómo las tablas de enrutamiento y la configuración de la interfaz afectan la conectividad de red.