Práctica P1.7: PC-A ↔ Router1 ↔ PC-B

Objetivo: montar tu primer router casero con 3 máquinas virtuales y entender de verdad qué hace un router que un switch no hace: dos redes separadas que no se ven entre sí, hasta que alguien las conecta a propósito.

Nivel: básico — primer contacto con enrutamiento. Trabajarás con 3 VMs en vez de 1 (como en P1.3/P1.4), así que organízate la RAM del portátil: si puedes, usa VMs sin escritorio con 512 MB y clones enlazados.

Antes de empezar: necesitas VirtualBox y la VM de Debian de P1.3. Vas a clonarla dos veces (o crear 3 VMs nuevas, como prefieras).

⚠️ Instala lo que necesites ANTES de aislar las VMs. Con “Red interna” no hay Internet, así que no habrá apt. En la VM que será Router1, instala ahora las herramientas de diagnóstico (con el adaptador aún en modo Puente o NAT):

sudo apt install tcpdump

Tampoco hay copiar/pegar entre VMs (sin Guest Additions): tendrás que teclear los comandos en cada una.

⚠️ Modo de red: ni NAT ni Puente — aquí toca “Red interna”. En P1.3/P1.4 usaste Adaptador puente, para que la VM entrara en la red real del aula. En esta práctica es justo lo contrario: necesitas que las VMs NO vean ni la red del aula ni Internet.

Modo VirtualBox	¿Qué hace?	¿Sirve aquí?
NAT (por defecto)	la VM sale a Internet a través del Host; nadie de fuera (ni otras VMs) puede verla	❌ cada VM quedaría aislada en su propia NAT
Adaptador puente (P1.3/P1.4)	la VM entra en la red real del aula como un PC más	❌ mezclaría tu 10.50.0.0/24 con el aula y con las VMs de tus compañeros
Red interna (esta práctica)	crea un “cable” virtual privado entre VMs, sin tocar el aula ni Internet	✅ exactamente lo que necesitas

Configuración → Red → Adaptador → “Conectado a: Red interna”.

Escenario

┌───────────────┐        ┌─────────────────────────┐        ┌───────────────┐
│     PC-A      │        │        Router1          │        │     PC-B      │
│ 10.50.0.10/24 ├──segA──┤ enp0s3: 10.50.0.1/24    │        │               │
│gw 10.50.0.1   │        │ enp0s8: 172.16.60.1/24  ├──segB──┤172.16.60.10/24│
│               │        │ ip_forward = ?          │        │gw 172.16.60.1 │
└───────────────┘        └─────────────────────────┘        └───────────────┘

• Red A (10.50.0.0/24) y Red B (172.16.60.0/24) son dos “Redes internas” (Internal Network) distintas de VirtualBox.
• Router1 es la única máquina con un pie en cada red (2 adaptadores). PC-A y PC-B solo tienen un adaptador cada una.

Parte 1: crea las 3 VMs y sus adaptadores de red

⚠️ Al clonar, marca “Generar nuevas direcciones MAC de todos los adaptadores de red”. Si no, dos VMs en el mismo segmento tendrán la misma MAC y el ARP se comportará de forma extraña.

En VirtualBox, con la VM apagada, Configuración → pestaña Red:

⚠️ El Adaptador 2 viene desactivado por defecto: marca la casilla “Habilitar adaptador de red” en su pestaña.

⚠️ El nombre de la red interna (segA, segB) debe escribirse idéntico en las VMs que comparten red: si te equivocas en una letra, VirtualBox crea otra red interna distinta sin avisarte.

Pon nombre a cada máquina

Las 3 VMs nacieron del mismo clon y se llaman igual. Cámbiales el nombre para no confundirte de terminal:

sudo hostnamectl set-hostname PC-A      # (PC-B y Router1 en las otras)

Cierra y abre la terminal para ver el cambio en el prompt.

Parte 2: IP estática en cada máquina

Las redes internas de VirtualBox no tienen DHCP: hay que poner la IP a mano. Hay dos caminos, elige UNO (mezclarlos da errores del tipo RTNETLINK answers: File exists):

💡 Antes de nada: enp0s3/enp0s8 son los nombres habituales en VirtualBox, pero no están garantizados. Comprueba los tuyos con ip -br a y sustituye el nombre si no coincide.

Camino A: temporal (para probar)

# PC-A
PC-A$ sudo ip addr add 10.50.0.10/24 dev enp0s3
PC-A$ sudo ip link set enp0s3 up
PC-A$ sudo ip route add default via 10.50.0.1

# PC-B
PC-B$ sudo ip addr add 172.16.60.10/24 dev enp0s3
PC-B$ sudo ip link set enp0s3 up
PC-B$ sudo ip route add default via 172.16.60.1

# Router1 (dos interfaces, una por red)
Router1$ sudo ip addr add 10.50.0.1/24 dev enp0s3
Router1$ sudo ip addr add 172.16.60.1/24 dev enp0s8
Router1$ sudo ip link set enp0s3 up
Router1$ sudo ip link set enp0s8 up

Camino B: persistente

Edita /etc/network/interfaces (con nano, por ejemplo). Sustituye el bloque iface enp0s3 inet dhcp que ya existe (de P1.3): si lo dejas, el arranque se queda esperando un DHCP que no existe.

# PC-A — /etc/network/interfaces
auto enp0s3
iface enp0s3 inet static
    address 10.50.0.10
    netmask 255.255.255.0
    gateway 10.50.0.1

# PC-B — /etc/network/interfaces
auto enp0s3
iface enp0s3 inet static
    address 172.16.60.10
    netmask 255.255.255.0
    gateway 172.16.60.1

# Router1 — /etc/network/interfaces
# Sin "gateway": Router1 solo conecta segA y segB, no sale a ningún sitio más.
auto enp0s3
iface enp0s3 inet static
    address 10.50.0.1
    netmask 255.255.255.0

auto enp0s8
iface enp0s8 inet static
    address 172.16.60.1
    netmask 255.255.255.0

Aplícalo con sudo systemctl restart networking (o reinicia la VM). Si antes probaste el Camino A y te da File exists, limpia primero: sudo ip addr flush dev enp0s3.

Comprobación intermedia (obligatoria)

Antes de probar PC-A → PC-B, comprueba que cada PC ve a su router:

PC-A$ ping -c3 10.50.0.1          # debe funcionar
PC-B$ ping -c3 172.16.60.1        # debe funcionar

Si esto falla, el problema está en la IP, en el nombre de la red interna o en que alguna VM está apagada. No sigas hasta que funcione.

Parte 3: comprueba que, de momento, NO se ven

Desde PC-A, intenta llegar a PC-B:

PC-A$ ping -c3 172.16.60.10

Debe fallar. Fíjate cómo: con ip_forward=0, Router1 descarta el paquete en silencio, así que verás solo 100% packet loss (timeout). Los otros fallos significan otra cosa:

Comprueba el interruptor del kernel (leer no requiere privilegios, y es lo mismo que lee sysctl):

Router1$ cat /proc/sys/net/ipv4/ip_forward
0          # <- este es el interruptor que falta

💡 Leer /proc/sys/... está abierto a cualquier usuario; cambiarlo (Parte 4) requiere privilegios porque afecta a toda la máquina.

¿Dónde se pierde el paquete? Míralo con tcpdump

En Router1, abre dos terminales y escucha cada interfaz:

Router1$ sudo tcpdump -ni enp0s3 icmp     # terminal 1 (lado segA)
Router1$ sudo tcpdump -ni enp0s8 icmp     # terminal 2 (lado segB)

Repite el ping desde PC-A. Verás las peticiones entrar por enp0s3, pero nada sale por enp0s8. Anota esto para la Parte 5.

Parte 4: enciende el router (literalmente)

Router1$ sudo sysctl -w net.ipv4.ip_forward=1

Si sysctl da command not found, usa su ruta completa (/usr/sbin/sysctl) o echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward.

Repite el ping desde PC-A con los tcpdump aún abiertos: ahora el paquete entra por enp0s3 y sale por enp0s8. Prueba también PC-B → PC-A.

💡 Si sigue sin funcionar, revisa que PC-A y PC-B tengan su default route hacia Router1 (ip route). Sin ella, el paquete llega a su destino pero la respuesta nunca vuelve (lo verás en tcpdump: peticiones sin respuestas).

Hazlo persistente (opcional)

sysctl -w se pierde al reiniciar. Crea un fichero propio:

Router1$ echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-forward.conf
Router1$ sudo sysctl --system

Parte 5: documenta

Desde cada máquina: ip -br a, ip route y cat /proc/sys/net/ipv4/ip_forward.

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

• ¿Qué diferencia hay entre lo que hace un switch (como las “Redes internas” de VirtualBox) y lo que hace Router1? ¿Por qué un switch nunca habría podido conectar segA con segB?
• Antes de activar ip_forward, ¿por qué fallaba el ping? Usa lo que viste en tcpdump: ¿dónde se “perdía” el paquete?
• ¿Para qué sirve el default route de PC-A y PC-B? ¿Qué pasaría si solo lo hubieras puesto en una de las dos? (pista: tcpdump en Router1)

Entrega

Un único fichero PDF (practica-router-apellido.pdf) con:

• La tabla de la Parte 5 rellena para las 3 máquinas.
• Captura del ping fallando (Parte 3) y funcionando (Parte 4).
• Captura del tcpdump antes y después de activar ip_forward.
• Las respuestas a las preguntas de cierre.

Súbelo por sFTP a nuestro servidor.

¡Happy Routing! ;-)

RUBRICA DE CALIFICACIÓN

Criterios de contenido (100%)

El fichero de entrega debe ser un único PDF (practica-router-apellido.pdf). Si falta alguna de las dos comprobaciones (antes/después) o la tabla está vacía, se penaliza en el criterio correspondiente.

Escala orientativa

• Excelente (9-10): las dos direcciones probadas, tabla completa, explica con precisión por qué fallaba antes de activar ip_forward y qué papel juega el default route.
• Notable (7-8.9): todo presente con algún detalle menor (falta un sentido del ping, una celda de la tabla sin rellenar), explicaciones correctas pero genéricas.
• Suficiente (5-6.9): solo se prueba un sentido, o falta la comprobación “antes” (sin ip_forward=0), preguntas respondidas sin mucha justificación.
• Insuficiente (<5): sin evidencia de conectividad funcionando, tabla vacía, o topología de red mal montada (segA/segB no coinciden entre VMs).

“Recuerda … KISS!” :-)