Introducción
Lantern Festival ya tiene preparada la ruta de ida de Main Stage a Workshop, pero la respuesta no puede volver. Observarás paquetes reales de conexión y repararás el retorno ausente, conservando los servicios existentes.
Completa primero «Llegar a la otra zona del festival», o conoce su flujo de consulta de destinos, adición/sustitución de rutas limitadas y recuperación. Debes reconocer direcciones IPv4, un rango /24 sencillo, los papeles de cliente/servidor y los puertos, y saber introducir comandos y consultar direcciones con ip addr. Los nodos Linux preparados comparten un núcleo: son espacios de nombres de red, no máquinas físicas independientes. No se necesitan programación, firewalls, enrutamiento dinámico ni cálculos de subredes.
Usa Area Plan para hacer peticiones reales de programas, Area A y Area B para sus clientes, y West Router y East Router para cambiar rutas. Cada terminal conserva su directorio y estado de red. Abrir una pestaña no reinicia el progreso. Este laboratorio empieza de forma independiente. Los tiempos son estimaciones del autor con lectura y errores habituales, sin un estudio cronometrado con principiantes.
Restablecer el retorno y conservar la red del festival
En este paso observarás ambos sentidos de una conexión antes de cambiar una ruta. Este escenario independiente ya tiene la ruta de West Router hacia Workshop. Empieza en Area Plan: solicita Main Stage desde Area A y Workshop desde Area B. Ambos programas locales funcionan. Solicita también Broadcast Room desde Area A. Workshop desde Area A sigue fallando.
TCP (protocolo de control de transmisión) establece una conexión antes de este intercambio HTTP. El cliente elige un puerto de origen temporal, llamado efímero; la respuesta invierte direcciones y puertos de origen y destino. La conexión empieza con un SYN del cliente; el servidor contesta con SYN-ACK antes de poder enviar HTTP. Ver un SYN en la red del servidor no demuestra que la petición HTTP haya llegado al servicio. Observarás tráfico real y acotado en ambos routers.
Cambia a West Router. tcpdump observa paquetes; -n conserva direcciones numéricas, -i any observa las interfaces de este nodo y -c 8 detiene la captura tras un máximo de ocho paquetes coincidentes. El filtro entre comillas selecciona TCP 8080. timeout 120 también termina tras dos minutos si no llegan ocho paquetes. Esto limita la recogida, no genera tráfico. Las líneas pueden aparecer al detener la captura. Espera el mensaje inicial antes de cambiar de pestaña y lee lo recogido después de detenerla.
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Espera listening on any, cambia a East Router e inicia el mismo observador acotado:
timeout 120 tcpdump -ni any -c 8 'tcp port 8080'
Después de listening on any, cambia a Area A y realiza una petición. Se espera un tiempo de espera agotado de tres segundos:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
echo $?
Espera 28. Cambia a East Router tras el fallo. Si el observador sigue activo, pulsa Ctrl+C para detenerlo y vaciar las líneas almacenadas. Si ya volvió al indicador, déjalo detenido. En ambos casos imprime inmediatamente su estado, antes de cualquier otro comando:
echo $?
124 significa que terminó el límite deliberado de dos minutos. 0 puede significar que tcpdump alcanzó el recuento o gestionó Ctrl+C correctamente; un programa envolvente interrumpido puede informar de 130. Usa las líneas de paquetes como evidencia, no solo el estado del observador. Repite las dos capturas y la petición si el intervalo terminó antes de la petición o no capturaste nada. Los dos minutos permiten cambiar de pestaña; no son una garantía medida con principiantes.
Busca el origen 10.71.0.10 hacia 10.72.0.10.8080, con Flags [S], entrando por transit y saliendo por lan. La respuesta invierte las direcciones: 10.72.0.10.8080 hacia 10.71.0.10, con Flags [S.], entrando por lan. No tiene un camino operativo para continuar. Cambia a West Router, pulsa Ctrl+C si su observador sigue activo y lee también su estado:
echo $?
West ve SYN de salida hacia Workshop, pero ningún SYN-ACK de vuelta. Varían los tiempos, puertos efímeros y retransmisiones. La evidencia sitúa el fallo en el retorno; no es una captura de un intercambio HTTP completado.
Añadir la ruta de retorno
Aquí proporcionarás una ruta para el destino de la respuesta. Empieza en East Router. Lee la tabla y consulta la dirección del cliente original:
ip route
ip route get 10.71.0.10
Espera RTNETLINK answers: No route to host. East Router está conectado a 10.72.0.0/24 y al tránsito 172.22.0.0/24, pero el destino de la respuesta pertenece a 10.71.0.0/24. Su siguiente salto debe ser el West Router adyacente, 172.22.0.1, no el cliente remoto.
Usa la misma sintaxis de ruta limitada del laboratorio anterior:
ip route add 10.71.0.0/24 via 172.22.0.1 dev transit
ip route get 10.71.0.10
Espera via 172.22.0.1 dev transit. Cambia a Area A y repite la petición:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Lee el programa completo de Workshop y Request received from: 10.71.0.10. El éxito incluye ahora el establecimiento de conexión, la petición y la respuesta HTTP. El origen sigue siendo la dirección de Area A; una traducción de direcciones o un proxy ocultaría el retorno ausente en vez de repararlo.
Si la ruta ya existe, lee la tabla y usa ip route replace 10.71.0.0/24 via 172.22.0.1 dev transit. Si sigue fallando, compara destino y siguiente salto en ambos routers y reintenta desde la pestaña correcta del cliente. No reinicies todos los servicios ni cambies las direcciones de los extremos.
Mantener los demás caminos operativos
Aquí comprobarás ambos sentidos y la tercera red protegida. Empieza en Area B y solicita Main Stage:
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Espera la actuación inicial, el desfile de faroles y Request received from: 10.72.0.10. Solicita también el programa local y la indicación de emisión:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
Cambia a Area A y conserva su acceso local y de emisión original:
ip -4 addr show dev eth0
ip route show default
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
La dirección sigue siendo 10.71.0.10/24 y la ruta predeterminada del cliente via 10.71.0.1. Cambia a Area B y consulta los valores correspondientes:
ip -4 addr show dev eth0
ip route show default
Su dirección continúa siendo 10.72.0.10/24, con predeterminada via 10.72.0.1. En Area Plan, solicita cada uno de los tres recursos desde Area A y Area B. Lee contenido e identidad original y despliega ambas tablas. Se conservan las dos rutas unreachable default metric 32760 originales. Las rutas específicas tienen prioridad sin sustituir las predeterminadas.
Si borras por error la ruta protegida a la tercera red en East Router, restablece solo esa entrada con la sustitución ya enseñada:
ip route replace 10.73.0.0/24 via 172.22.0.1 dev transit
Las rutas predeterminadas originales de los extremos figuran arriba. Las de los routers pueden restaurarse en sus propias pestañas con ip route replace unreachable default metric 32760; no ejecutes estos comandos del curso sobre la red de la plataforma. Lee la tabla tras cualquier corrección y repite las peticiones afectadas. Conserva las rutas conectadas, direcciones, enlaces y procesos originales. Las comprobaciones son observaciones de solo lectura y peticiones GET normales; nunca añaden rutas ni reparan el escenario. Se aceptan rutas precisas equivalentes dentro del rango remoto indicado.
Localiza en el mapa los dos vecinos de tránsito y compara las filas de destino con las rutas predeterminadas conservadas. Las tablas desplegadas muestran rutas reales del núcleo en el laboratorio operativo.
Resumen
Usaste consultas reales de destino y rutas limitadas para entregar programas del festival, conservando direcciones y caminos ajenos. También distinguiste solicitudes de conexión y respuestas mediante capturas reales acotadas.
