Cómo leer el primer intercambio IKEv2 en una captura de paquetes

Las capturas tomadas a mitad de sesión son el motivo habitual de que una traza IKEv2 parezca ruido, porque las partes ya están renovando claves o intercambiando cargas cifradas cuando empieza la grabación. Empieza mejor con un intento de conexión nuevo, de modo que el primer mensaje del archivo sea el que abre la negociación. El orden de lectura siguiente lo presupone y marca el punto en el que un paquete deja de demostrar nada sobre el extremo remoto. Saltarse ese paso es como un túnel que funciona acaba diagnosticado como un puerto bloqueado.

Confirma que estás viendo el intercambio inicial

Una negociación IKEv2 comienza con IKE_SA_INIT, tipo de intercambio 34, identificador de mensaje 0. El iniciador elige un SPI distinto de cero, y el SPI del respondedor es cero en esa primera petición y distinto de cero en la respuesta. Esos tres hechos separan un intento nuevo de una renovación de claves o de un mensaje IKE_AUTH que casualmente está en la parte superior de una captura.

Los campos de la cabecera son legibles, y también lo son las cargas de propuesta, intercambio de claves y nonce. Legible no significa autenticado: ninguna de las partes ha demostrado identidad en este punto, y el valor privado de Diffie-Hellman nunca aparece en el cable.

Imprime los campos como una tabla en lugar de desplazarte por un panel de decodificación, porque las retransmisiones y los SPI que no coinciden se vuelven evidentes en columnas.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Lee la salida por parejas. Una petición con identificador de mensaje 0 seguida de una respuesta que lleva el mismo identificador y un SPI de respondedor distinto de cero es un solo intercambio, incluso cuando aparece tres veces porque la petición se retransmitió. Tres peticiones idénticas no son tres inicios de sesión, y tratarlas así es como se llega a concluir que un cliente está en bucle cuando solo es paciente. Ordena por identificador de mensaje y luego por marca de tiempo, y toda la conversación se reduce a una lista corta de intentos.

Lee un rechazo antes de leer un éxito

Una respuesta no es automáticamente un avance. El respondedor puede contestar con una notificación cookie y esperar que el iniciador lo reintente, o con INVALID_KE_PAYLOAD nombrando un grupo que aceptaría en su lugar. Ambas llegan como mensajes IKE bien formados, y ambas parecen un intercambio terminado a un filtro que solo cuenta paquetes.

Abre la carga de notificación y lee el tipo antes que nada. Un desafío cookie significa que el respondedor se defiende de direcciones de origen falsificadas, y el cliente debe reenviar con la cookie adjunta. Un grupo no válido significa que las dos propuestas no coinciden, y ninguna cantidad de reintentos lo cambiará hasta que se mueva la configuración de una de las partes.

Solo IKE_AUTH, el segundo intercambio, transporta la identidad cifrada y las cargas de autenticación. Por tanto, un IKE_SA_INIT completado te dice que las partes coinciden en algoritmos y claves derivadas, y absolutamente nada sobre si se aceptarán las credenciales. Espera también dos mensajes ahí, y espera que ambos sean opacos sin las claves de sesión.

El puerto 4500 no es un solo protocolo

El UDP 500 suele llevar el intercambio inicial. Una vez que se ha ejecutado la detección de NAT, IKE pasa al 4500 y antepone a cada mensaje un marcador de cuatro bytes a cero que no es ESP. El ESP encapsulado en el mismo puerto empieza en cambio con un SPI de ESP distinto de cero, y un keepalive de NAT de un solo byte es una tercera forma que aparece cuando no ocurre nada más.

Un filtro que coincide solo con el puerto mezcla las tres cosas, y por eso "hay tráfico en el 4500" resuelve tan poco. Divide la vista por protocolo antes de concluir nada sobre el extremo remoto.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

El silencio describe el punto de observación

Las peticiones sin respuestas establecen exactamente una cosa: en ese punto de captura no apareció ninguna respuesta. El filtrado, una ruta que envía la respuesta a otro sitio, un respondedor inalcanzable o un respondedor al que no le gusta la propuesta producen todos el mismo resultado vacío, y una sonda UDP genérica no los separará.

Un ICMP inalcanzable es una evidencia de otro tipo. Lee el paquete citado que contiene y averigua qué dispositivo lo emitió, porque el rechazo administrativo de un enrutador no es un error autenticado del extremo remoto.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Correlaciona el mismo intento con los registros del servidor donde se te permita leerlos. ¿Llegó la petición, respondió el servicio y dónde se detuvo la respuesta? Esas tres respuestas te llevan a un problema de ruta o a un problema de política, y cuestan menos que rotar las credenciales por cuarta vez.