Caso 04: Los paquetes salen pero no vuelven¶

El escenario¶

Red con un router en el medio. El ping de PC-A a PC-B no recibe respuesta — pero el packet capture muestra algo inesperado.

Topología¶

name: "caso-04-ruta-vuelta"
nodes:
  - name: PC-A
    type: HOST
    x: 100
    y: 200
  - name: ROUTER
    type: ROUTER
    x: 350
    y: 200
  - name: PC-B
    type: HOST
    x: 600
    y: 200
links:
  - source: PC-A
    target: ROUTER
  - source: ROUTER
    target: PC-B

Configuración inicial¶

En PC-A:

ip addr add 192.168.1.10/24 dev eth1
ip link set eth1 up
ip route add default via 192.168.1.1

En ROUTER:

ip addr add 192.168.1.1/24 dev eth1
ip addr add 10.0.0.1/30 dev eth2
ip link set eth1 up
ip link set eth2 up
ip route add 10.0.0.0/30 via 10.0.0.1 2>/dev/null; true

En PC-B:

ip addr add 10.0.0.2/30 dev eth1
ip link set eth1 up

Introducir la falla¶

⚙️ Comando para romper el escenario — no leer si sos el alumno

# PC-B no tiene gateway configurado — no sabe responder a 192.168.1.x
# (simplemente no ejecutar ip route add default en PC-B)
# Si ya lo configuraste, eliminarlo:
# ip route del default

El escenario está roto desde el inicio: PC-B no tiene gateway.

🔴 El síntoma¶

Desde PC-A:

ping -c 4 10.0.0.2

Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3

Sin respuesta. Pero abrís el Packet Capture en eth2 del ROUTER y ves esto mientras hacés ping:

ICMP echo request  192.168.1.10 → 10.0.0.2
ICMP echo request  192.168.1.10 → 10.0.0.2
ICMP echo request  192.168.1.10 → 10.0.0.2

Los paquetes llegan al router. ¿Pero dónde está la respuesta?

Tu misión¶

Los paquetes claramente están viajando en algún punto. Encontrá dónde mueren y arreglalo.

Pistas¶

Pista 1

El packet capture en el router muestra que los paquetes de PC-A llegan. El router tiene las dos redes directamente conectadas, así que los reenvía a PC-B sin problema. Abrí el packet capture en la interfaz `eth1` de **PC-B** mientras hacés el ping. ¿Llegán los paquetes?

Pista 2

Si los paquetes llegan a PC-B pero no hay respuesta, el problema es que PC-B no sabe cómo responder. La respuesta debe ir a `192.168.1.10` — ¿PC-B tiene ruta hacia `192.168.1.0/24`? Mirá la tabla de ruteo de PC-B con `ip route show`.

Solución completa

**Diagnóstico:** Packet capture en `eth1` de PC-B confirma que los pings llegan:

ICMP echo request  192.168.1.10 → 10.0.0.2   ← llega

Pero no hay reply. PC-B recibe el ping y quiere responder a `192.168.1.10`, pero:

# En PC-B
ip route show

10.0.0.0/30 dev eth1 proto kernel

PC-B solo conoce su propia red (`10.0.0.0/30`). No tiene ruta hacia `192.168.1.0/24` ni gateway por defecto. La respuesta se descarta. **Fix:**

# En PC-B
ip route add default via 10.0.0.1

**Verificación:**

# Desde PC-A
ping -c 4 10.0.0.2   # ✅

**La lección:** un ping requiere dos caminos. El problema puede estar en la ida O en la vuelta. El packet capture es la herramienta clave para distinguir cuál es — si ves el request llegar pero no hay reply, mirá la ruta de vuelta.