Paquetes IKE duplicados: encuentra la transición que falta

El registro muestra la misma solicitud IKE dos veces, alguien señala el enlace móvil y el ticket se cierra con una conjetura. Esa conjetura es el mito: un paquete repetido es una observación sobre un intercambio, no un diagnóstico de un enlace. La retransmisión es un comportamiento normal con sus propias reglas, y aparece en rutas sanas siempre que una respuesta tarda. Sigue la respuesta antes de culpar a una interfaz.

El mito: una solicitud repetida demuestra pérdida en un enlace

Dos cosas distintas producen un duplicado y ninguna de ellas nombra a un culpable. El solicitante puede repetir una solicitud porque no recibió respuesta, o el punto de captura puede mostrar el mismo paquete dos veces por dónde está conectado a la pila. Una sonda que ve la entrada y la salida en el mismo host registrará alegremente un paquete como dos, y el operador que lee ese registro no tiene forma de distinguirlo sin los identificadores del intercambio. Trata el duplicado como un evento de temporizador hasta que puedas decir cuál de los dos tienes en la mano.

Dos enlaces ascendentes empeoran la confusión en lugar de mejorarla. Una sola línea de registro nombra una interfaz, mientras que la respuesta puede haber salido por la otra, así que la interfaz del mensaje describe dónde se vio un paquete y no la forma de la conversación. Por eso la primera pregunta es qué intercambio estás mirando, no qué enlace está defectuoso.

Qué te dice realmente la retransmisión

En IKEv2, la retransmisión funciona así: el solicitante repite una solicitud cuando no ha llegado ninguna respuesta, y el respondedor puede reenviar su respuesta en caché en lugar de recalcular una. Los identificadores de mensaje pertenecen a ese intercambio, y eso es lo que hace que una solicitud repetida con el mismo identificador se reconozca como el protocolo funcionando y no como un intento nuevo. Un intento inicial a menudo necesita más que una dirección de origen o un SPI de iniciador para correlacionarse, así que el registro de intercambio de la plataforma supera a un listado de paquetes. IKEv1 sigue reglas distintas con identificadores distintos, y una advertencia de proveedor sobre un primer paquete duplicado no significa lo mismo entre versiones.

Así que una marca de tiempo de retransmisión te dice que un temporizador expiró. No te dice qué salto era lento, y desde luego no te dice que el operador tenga la culpa. Son afirmaciones separadas, y solo la segunda es útil en un ticket.

La consecuencia práctica es registrar el intercambio antes de sacar una conclusión. Anota la dirección local de recepción, la ruta de respuesta que eligió la política, la tupla del par y los identificadores del intercambio en un solo lugar, porque cada uno responde a una pregunta distinta cuando el registro se lee más tarde.

Cuatro puntos de observación como una sola cadena

Piensa en el intercambio como cuatro eslabones de una cadena y no como cuatro lugares separados donde mirar. Un eslabón contiene pruebas o queda desconocido, y la cadena solo es tan informativa como su eslabón registrado más débil. La tabla siguiente es el inventario: qué puede establecer cada posición y qué deja intacto.

Rellena la cadena solo donde tengas acceso y marca el resto como desconocido en lugar de inferirlo. Un gancho que registra paquetes en una máquina no dice nada sobre lo que recibió la máquina remota, y una línea de registro que anota que se vio una solicitud no es prueba de que alguna vez saliera una respuesta. Los huecos honestos son más útiles que un registro que parece completo y está construido con conjeturas.

Encuentra la primera transición que falta

Recorre la cadena desde el iniciador hacia fuera y detente en el primer eslabón sin pruebas. Si la puerta de enlace nunca registra la solicitud, la falla está en la ruta anterior. Cuando la puerta de enlace registra la misma solicitud una y otra vez mientras el cliente nunca registra una respuesta, la dirección de vuelta es la sospechosa: dirección de origen, traducción y filtrado en cada frontera que controles. Si la respuesta llega y el cliente sigue sin avanzar, la pregunta ha dejado el transporte y se ha convertido en política o estado.

Mantén fijos el par y el protocolo mientras comparas, y recuerda que el retardo, la pérdida, la política y el estado producen cada uno una línea temporal distinta. Una red móvil no es automáticamente la causa, y una línea fija no es automáticamente lo bastante fiable para todos los requisitos. Captura ambas direcciones mientras el intercambio está activo:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

Cuando el acceso se detiene antes del extremo lejano, el registro sigue ayudando si dice dónde se detiene. Una captura solo en el iniciador puede mostrar una solicitud que sale y ninguna respuesta que llega, lo que estrecha la falla a todo lo posterior a ese gancho sin pretender saber qué salto la dejó caer. Marca los eslabones lejanos como desconocidos y deja que la siguiente persona con acceso los rellene. Escrito así, el registro se mantiene honesto y aún breve.

Compara antes de cambiar nada. Repetir la misma solicitud contra el mismo par con el mismo protocolo mantiene las variables contables, mientras que un reinicio, una renovación de clave o una edición de política entre capturas destruye la comparación. Si un cambio es inevitable, captura de nuevo inmediatamente después para que el antes y el después sigan describiendo el mismo intercambio.

Qué dice un informe útil

Un informe que merece actuación empareja una solicitud con su respuesta y nombra el primer paso que no tiene pruebas detrás. Esa frase sobrevive a ser leída una semana después por un ingeniero que no estaba allí, y da a la siguiente persona un lugar por donde empezar en lugar de un sospechoso.

Nunca debilites las comprobaciones de identidad ni amplíes el conjunto de protocolos permitido solo para comprobar una teoría de retransmisión. Guarda los paquetes y los registros de eventos originales antes de cualquier reinicio, porque un reinicio destruye exactamente el material que estabas a punto de recoger y borra la temporización que mostraba dónde se atascó el intercambio.

El mito es que un duplicado demuestra que el operador tiene la culpa. La realidad es que un duplicado demuestra que un temporizador expiró, y la respuesta vive en la ruta de respuesta.