Introducción
Alder dice que la página de reservas de Lantern Room procesó dos intentos, pero solo uno produjo una reserva. El equipo de soporte dispone de una grabación HTTPS autorizada y su registro de claves TLS correspondiente. Ambos intentos utilizan el mismo URI y conexión TCP, y el archivo contiene también a otro visitante.
Utilizarás la interfaz real de Wireshark para identificar cada resultado de aplicación y entregar una tabla breve más un paquete de captura completo que se pueda leer de forma independiente. Debes haber completado Read Your Authorized HTTPS Session o conocer la configuración del registro de claves TLS y Follow TLS Stream. También necesitas introducción básica de comandos y rutas. Este laboratorio empieza de forma independiente con sus propias grabaciones controladas; su duración estimada incluye lectura y errores habituales.
Relaciona Cada Intento Con Su Resultado De Negocio
En este paso relacionarás cada trama de solicitud original con su propia respuesta completa y registrarás ambos resultados.
Empieza en Desktop → Applications → Terminal Emulator. Abre la entrada preparada en el perfil vacío Booking:
wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng
Maximiza Wireshark. Los dos archivos de entrada de solo lectura son casebook.pcapng y casebook.keys; todos los entregables van en /home/labex/project/booking/output/. Los datos son sintéticos, pero cada intercambio inicial TLS, intercambio HTTP y segmento TCP fue generado por una aplicación local controlada real.
En Edit → Preferences → Protocols → TLS, establece (Pre)-Master-Secret log filename en:
/home/labex/project/booking/input/casebook.keys
Mantén activadas ambas opciones de reensamblado TLS y pulsa OK. El registro autoriza descifrar estas sesiones grabadas; no es una clave general para cualquier conexión HTTPS.
| Visitante | Dirección del cliente | Alcance |
|---|---|---|
| alder | 127.0.0.22 | Los dos intentos de reserva paper-lantern que debes explicar |
| birch | 127.0.0.23 | Otro visitante; exclúyelo de la entrega |
Aplica este filtro de visualización y pulsa Enter:
ip.addr == 127.0.0.22 && http
ip.addr coincide con cualquiera de los extremos. && exige que se cumplan ambas condiciones, así que la vista contiene los mensajes HTTP descifrados de Alder en ambas direcciones. Debes ver dos solicitudes POST y dos respuestas 200 OK. Ambos intentos comparten el URI /api/bookings y el flujo TCP; ninguno identifica por sí solo una transacción.
Selecciona el primer POST. En el panel central de detalles, expande Hypertext Transfer Protocol con el triángulo pequeño. Lee [Response in frame: ...] cerca del final. Este campo generado enlaza la solicitud con la respuesta que Wireshark realmente ha relacionado. En los detalles de esa respuesta, [Request in frame: ...] apunta hacia atrás. Selecciona la respuesta enlazada mediante la lista de paquetes. No. muestra el número de trama original. El HTTP reensamblado puede aparecer en el segmento final; utiliza estas referencias de tramas de análisis, en lugar de adivinar por filas TCP adyacentes.
Observa [Response in frame: 21] en los detalles HTTP expandidos. El enlace pertenece a la primera solicitud seleccionada; la segunda tiene una respuesta diferente.
Haz clic derecho en la solicitud y elige Follow → TLS Stream. Lee la solicitud y su respuesta completas. El JSON de solicitud identifica attempt, workshop y slot. La respuesta repite esos valores. Lee juntos accepted, reason y confirmation. Después lee la segunda solicitud y su respuesta más abajo en el mismo flujo.
El primer intento de Alder se rechaza porque la sesión está llena: accepted es false, reason es "session_full" y confirmation es null. El reintento se acepta y tiene su propia confirmación. Ambas líneas de estado HTTP son 200 OK: el servidor procesó ambas solicitudes, pero sus resultados de negocio difieren. No se puede tomar prestada para un intento rechazado una confirmación vista en otra parte del flujo o en la visita de Birch.
Cierra Follow con Close. El filtro de flujo resultante incluye toda la conexión. Vuelve al filtro original de Alder y HTTP para registrar los cuatro números de trama originales. Utiliza siempre este archivo de entrada para la tabla; un archivo exportado renumera los paquetes.
Prepara attempts.csv, un pequeño índice de entrega que otra persona pueda contrastar con la captura. CSV significa valores separados por comas: una cabecera nombra las columnas y cada línea posterior representa un intento. Hay siete columnas:
| Columna | Significado |
|---|---|
| attempt | Valor exacto de attempt en la solicitud |
| request_frame | Número de trama del POST en la entrada original |
| response_frame | Número de su propia respuesta enlazada en la entrada original |
| slot | Sesión solicitada y repetida por esa respuesta |
| accepted | true o false del JSON de respuesta |
| reason | Texto exacto del motivo en la respuesta |
| confirmation | Confirmación de ese intento, o campo vacío para null |
Cambia a la terminal mediante el panel inferior, o abre otro Terminal Emulator si el primero sigue ocupado por Wireshark. Inicia el editor preparado:
mousepad /home/labex/project/booking/output/attempts.csv
Escribe exactamente la cabecera siguiente y las dos filas leídas de la captura original. No copies la palabra null en la columna de confirmación: termina la fila rechazada con una coma para representar un último campo vacío. Ninguno de estos valores contiene comas, por lo que no hacen falta campos CSV entre comillas. Puedes cambiar el orden de filas y columnas si las cabeceras siguen correspondiendo a sus valores.
attempt,request_frame,response_frame,slot,accepted,reason,confirmation
Utiliza File → Save y cierra el editor. Comprueba que hay una fila por cada intento diferente y que cada una apunta a su propia respuesta. Si escribes mal un valor, abre el mismo archivo con el comando anterior, corrígelo y guarda. Un error de escritura no requiere otra captura ni reiniciar la VM. Deja Wireshark abierto para el siguiente paso.
Entrega Un Paquete De Pruebas Legible Independientemente
En este paso exportarás una conexión objetivo completa y volverás a abrirla con el registro de claves entregado.
Empieza en Desktop, con Wireshark en el original input/casebook.pcapng. La tabla indexa la fuente, mientras la captura de entrega debe contener únicamente la conexión TCP completa de Alder. El intercambio inicial TLS y los segmentos anteriores son necesarios para descifrar y reensamblar los datos de aplicación.
Sustituye el filtro de visualización por:
ip.addr == 127.0.0.22
Conserva ambas direcciones y todas las capas de Alder. Selecciona uno de sus POST descifrados, haz clic derecho y elige Follow → TLS Stream. Confirma que ambos intentos pertenecen a Alder y cierra Follow con Close. Conserva su filtro tcp.stream eq ...: incluye la conexión entera seleccionada, no solo las filas HTTP.
Elige File → Export Specified Packets. Selecciona formato pcapng, rango Displayed y All packets dentro de ese conjunto mostrado. Guarda en:
/home/labex/project/booking/output/evidence.pcapng
El diálogo muestra Displayed y All packets, con 38 paquetes objetivo. El original contiene 65, así que seleccionar Captured incluiría también al otro visitante.
No uses Export Packet Dissections, que exporta resúmenes. No exportes solo las filas http: pueden omitir el intercambio inicial o segmentos TLS/TCP anteriores necesarios para descifrar y reensamblar. No incorpores secretos mediante Inject TLS Secrets; el paquete utiliza un registro separado.
Cambia a un Terminal Emulator y copia el registro autorizado junto a la salida. cp copia la primera ruta a la segunda; conserva la entrada original en lugar de renombrarla.
cp /home/labex/project/booking/input/casebook.keys /home/labex/project/booking/output/booking.keys
Esta entrega de formación permanece en el mismo alcance autorizado. El registro proporcionado contiene secretos de las sesiones sintéticas de la fuente; minimizar o censurar sus entradas queda fuera del ejercicio. La captura debe excluir de todos modos los paquetes de Birch. Se aceptan registros equivalentes correspondientes si descifran independientemente ambas respuestas objetivo.
Cierra la ventana principal y abre la exportación real en el perfil BookingReview, inicialmente vacío:
wireshark -C BookingReview /home/labex/project/booking/output/evidence.pcapng
En Edit → Preferences → Protocols → TLS, configura (Pre)-Master-Secret log filename con el registro de salida siguiente y pulsa OK:
/home/labex/project/booking/output/booking.keys
Aplica http y sigue un POST con Follow → TLS Stream. Lee otra vez ambos cuerpos completos de solicitud y respuesta. La exportación debe mostrar el rechazo y la confirmación de Alder con sus propios intentos, sin visita de Birch. Debe funcionar con el registro de salida, sin depender silenciosamente de la ruta de claves original.
Lee el attempt repetido junto a cada resultado: el rechazo no tiene confirmación y solo el reintento tiene ALDER-02-CONF. El título identifica el archivo de salida evidence.pcapng.
Cierra Follow y borra el filtro para confirmar que también están el intercambio inicial y los demás paquetes TCP. Este archivo tiene su propia numeración; mantén attempts.csv referido a las tramas de la entrada original. Cierra la ventana principal.
Si la salida está vacía o falta un cuerpo, abre otra vez la entrada, restaura el filtro de la conexión completa de Alder y repite Export Specified Packets con Displayed → All packets, sustituyendo la salida incompleta. Si sigue cifrada, corrige la ruta del registro de salida en las preferencias TLS. Son problemas distintos: sin claves no se descifra, pero cambiar una preferencia no recrea segmentos que faltan en la captura.
La entrega consta de tres archivos reales: attempts.csv, evidence.pcapng y booking.keys. La captura y las claves deben respaldar independientemente la tabla. Una imagen o una afirmación de éxito escrita no sustituyen las pruebas reales de paquetes.
Resumen
Has distinguido dos resultados de negocio transportados por estados HTTP idénticos, relacionado cada solicitud con su propia respuesta y registrado las referencias de tramas originales en una tabla concisa. Has exportado toda la conexión TCP objetivo y abierto la salida real con su registro de claves separado.
La entrega de tres archivos se puede comprobar sin tu perfil de Wireshark. Establece lo que indican estos intercambios controlados; no demuestra un pago de producción, una actualización de inventario ni un defecto interno del servidor.
