Introducción
Lantern Festival tiene servicios locales operativos en cada zona, pero el personal aún no puede obtener el programa de la otra. Restablecerás un camino limitado entre redes separadas, manteniendo disponible la sala de emisió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 camino a Workshop
En este paso establecerás un ejemplo local operativo antes de investigar un destino remoto. Empieza en Area Plan. En la tarjeta Main Stage, selecciona Request from Area A. Verás la actuación inicial y el desfile de faroles, terminando con Request received from: 10.71.0.10. Vuelve con el botón Atrás del navegador. En Broadcast Room, selecciona Request from Area A: su indicación también está disponible. Estos servicios operativos deben conservarse.
Cambia a Area A. Su terminal ya está en /home/labex/project/festival-routes/a. pwd muestra ese directorio. ip -4 addr show muestra las direcciones IPv4; dev eth0 selecciona la interfaz del curso.
pwd
ip -4 addr show dev eth0
Espera 10.71.0.10/24. En este plan, /24 indica que las direcciones que empiezan por 10.71.0 son locales. Workshop utiliza otra subred, 10.72.0.0/24. Un router reenvía paquetes entre redes sin cambiar sus direcciones originales.
HTTP es el protocolo de petición/respuesta del servicio de programas preparado. curl solicita un recurso HTTP. --noproxy '*' evita los proxies para todos los destinos; las comillas mantienen * literal. -f trata los errores HTTP como fallos, -s oculta el progreso y -S sigue mostrando errores. --max-time 3 limita el intento completo a tres segundos. El puerto 8080 corresponde al servicio de programas preparado.
curl --noproxy '*' -fsS --max-time 3 http://10.71.0.10:8080/programme.txt
Lee el programa local completo, incluida su dirección de origen. Ahora prueba Workshop. Se espera que la siguiente petición falle; no daña la red.
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Espera un fallo de conexión en lugar del programa. Lee inmediatamente el estado de salida nativo: $? contiene el estado del último comando y echo lo imprime.
echo $?
Un estado distinto de cero indica un intento fallido. Fallo de conexión (a menudo 7), tiempo de espera agotado (28) y rechazo HTTP (22 con -f) describen observaciones diferentes; ninguna identifica por sí sola todas las causas. Un puerto rechazado puede indicar que se llegó al host, pero ningún servicio aceptó la conexión. Si escribes mal una petición, comprueba la pestaña, dirección y puerto exactos y repítela. No reinicies la VM.
El servicio local y la tercera red funcionan. La siguiente pregunta es qué camino elegiría West Router para Workshop.
Leer la decisión del router
Aquí distinguirás la puerta de enlace predeterminada del cliente de la ruta específica de un router. Empieza en Area A. ip route lee la tabla activa; ip route get pregunta al núcleo qué camino elegiría sin enviar una petición de programa.
ip route
ip route get 10.72.0.10
Espera via 10.71.0.1 dev eth0: el siguiente salto es el West Router adyacente. via identifica ese vecino y dev la interfaz de salida. Esto no demuestra que West Router conozca el resto del camino.
Cambia a West Router, cuyo directorio del curso termina en /west. Lee sus interfaces y rutas:
ip -4 addr show
ip route
ip route get 10.72.0.10
Espera RTNETLINK answers: No route to host en la última consulta. La interfaz LAN es 10.71.0.1/24; transit tiene 172.22.0.1/24. El East Router adyacente usa 172.22.0.2/24 y conecta Workshop mediante 10.72.0.1/24. Broadcast Room está detrás de la interfaz broadcast de West Router, 10.73.0.1/24.
La ruta preparada unreachable default metric 32760 es deliberada: rechaza los destinos sin otra coincidencia en este ejercicio aislado. Una ruta predeterminada normal puede usar una puerta de enlace. Conserva aquí la existente. metric 32760 expresa su preferencia entre rutas con el mismo prefijo; en esa comparación se prefiere una métrica menor. Una ruta para 10.72.0.0/24 es más específica que la predeterminada y solo cambia el camino de esa zona. No sustituyas la predeterminada ni vacíes la tabla.
En Area Plan, despliega West Router · live routing table para comparar la misma tabla nativa. El mapa describe la estructura; las peticiones comprueban comunicación real. En este primer laboratorio ya está preparada la ruta de retorno de East Router. Solo falta la ruta de destino en West Router.
Añadir el camino limitado
Aquí añadirás una ruta de destino y recuperarás el recurso remoto completo. Empieza en West Router. Esta terminal ya tiene derechos administrativos dentro del espacio de nombres del curso. ip route add añade una ruta activa; 10.72.0.0/24 es el rango de destino, via 172.22.0.2 indica el router adyacente y dev transit selecciona el enlace a ese vecino.
ip route add 10.72.0.0/24 via 172.22.0.2 dev transit
Normalmente el éxito no imprime nada. Vuelve a consultar la decisión:
ip route get 10.72.0.10
Espera via 172.22.0.2 dev transit. El src mostrado pertenece a una petición originada en el propio router; el tráfico reenviado de Area A conserva su dirección. Cambia a Area A y realiza la petición desde el cliente real:
curl --noproxy '*' -fsS --max-time 3 http://10.72.0.10:8080/programme.txt
Espera Workshop, el taller de faroles de papel y el círculo de ritmo, además de Request received from: 10.71.0.10.
Guardar el programa y conservar otros caminos
En este paso guardarás el recurso remoto y conservarás los caminos local y de emisión. Empieza en Area A. -o remote-programme.txt guarda los bytes recibidos en el directorio de esta terminal. cat lee el archivo guardado.
curl --noproxy '*' -fsS --max-time 3 -o remote-programme.txt http://10.72.0.10:8080/programme.txt
cat remote-programme.txt
Comprueba también el camino de emisión protegido:
curl --noproxy '*' -fsS --max-time 3 http://10.73.0.10:8080/programme.txt
En Area Plan, vuelve a la página principal y selecciona Request from Area A de Workshop. Lee el mismo programa y la dirección original. Usa Atrás del navegador para solicitar otra vez Main Stage y Broadcast Room. La tabla desplegable debe seguir mostrando las rutas predeterminada y conectadas originales.
Si add informa de File exists, consulta ip route en West Router. replace añade o actualiza únicamente el prefijo indicado:
ip route replace 10.72.0.0/24 via 172.22.0.2 dev transit
Si añadiste por error 10.72.1.0/24, no coincide con este destino. Elimina solo esa entrada con ip route del 10.72.1.0/24 y utiliza después la ruta correcta mostrada. Ante otros errores de escritura, lee la tabla y quita únicamente el prefijo adicional que introdujiste. Nunca uses flush. Conserva direcciones, rutas originales, enlaces y servicios. Repite la misma descarga si el intento fallido no dejó un archivo completo. Las rutas están activas para esta sesión; la persistencia tras reinicios queda fuera.
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. La puerta de enlace del cliente solo es el primer salto; cada router necesita una siguiente decisión utilizable.
