Cómo leer un intercambio IKE_SA_INIT nuevo en una captura
Una negociación IKEv2 nueva se puede leer antes de que existan claves. Captura el intento, lee la cabecera, empareja la respuesta y distingue IKE de ESP en el puerto 4500.
Empieza por una captura que comience antes del primer paquete del intento, o estarás leyendo la mitad de una conversación. Una negociación que ya está en marcha muestra intercambios cifrados y renovaciones de claves, y ninguna de las dos se parece a la apertura. La apertura es la parte que puedes decodificar sin claves, y por eso responde tan bien a las preguntas de accesibilidad. Cuatro comprobaciones en orden te llevan de una captura recién hecha a una afirmación defendible sobre qué lado dejó de hablar.
Primero, confirma que la captura empieza por el principio
Una captura iniciada después de que el túnel suba contendrá el flujo de datos encapsulado y keepalives periódicos, y ambos están cifrados o casi vacíos. Reinicia el cliente y registra el intento en sí, o provoca deliberadamente una conexión nueva mientras la captura se ejecuta. Si no puedes producir un intento nuevo, dilo en tus notas, porque ninguna cantidad de decodificación recupera una apertura que nunca registraste.
Limita la captura a los dos extremos y a UDP 500 y 4500 para que el archivo siga siendo lo bastante pequeño para leerlo. En un host ocupado, una captura sin filtro entierra la negociación bajo tráfico ajeno.
tcpdump -i any -n -s 0 -w fresh-ike.pcap 'udp port 500 or udp port 4500'Guarda el archivo cuando el intento sea interesante, porque la misma captura responde a las dos preguntas siguientes: qué fue el intercambio y si volvió algo. Etiquétalo con la hora de inicio y el par de extremos por el que filtraste. Una captura sin esos dos datos es inútil una semana después, cuando las direcciones han cambiado y nadie recuerda qué intento registró.
Segundo, lee la cabecera antes de las cargas
La cabecera IKE lleva los índices de parámetros de seguridad, el tipo de intercambio y el ID de mensaje, y en una negociación nueva esos valores son distintivos. El iniciador inventa un SPI distinto de cero, la petición inicial lleva un SPI de respondedor de cero porque aún no se ha visto ninguna respuesta, el tipo de intercambio es IKE_SA_INIT y el ID de mensaje es cero. Cualquier otra cosa pertenece a una etapa posterior de la misma negociación o a un intento completamente distinto.
Las cargas de propuesta, intercambio de claves y nonce de este primer intercambio son legibles en claro. Legible no significa autenticado, y en este punto ninguna de las dos partes ha demostrado su identidad.
El valor privado de Diffie-Hellman nunca cruza el cable, así que la captura no te permite derivar claves de sesión. La autenticación ocurre en el siguiente intercambio, protegida por lo que negoció el primero. Si alguien pregunta si un extremo es genuino, este intercambio no puede responder a esa pregunta. Solo puede mostrar que ambas partes acordaron una propuesta y produjeron un secreto compartido que el archivo no contiene.
Tercero, empareja la petición con su respuesta
Empareja por el par de SPI, el tipo de intercambio y el ID de mensaje, y luego revisa el indicador de respuesta. Una retransmisión repite el ID de mensaje del original y no es un segundo intento de inicio de sesión. Contar paquetes en lugar de intercambios es como una negociación sana se convierte en un bucle fantasma.
Una respuesta también puede ser un rechazo: una petición de cookie, una notificación de grupo inaceptable o un error sobre una propuesta. Son respuestas legítimas, y significan que el camino funciona mientras la política no. Decodifica la notificación en lugar de tratar cada respuesta como un éxito. Cuando la notificación nombra un grupo o una propuesta, la reparación está en la configuración y no en el cortafuegos.
La dirección también importa. Una petición sin respuesta y una respuesta que nunca llega al cliente son fallos distintos, y solo la segunda parece un tiempo de espera del lado del cliente.
Cuarto, separa IKE de todo lo demás en 4500
El puerto 4500 lleva tres cosas que en una vista resumida parecen iguales: IKE detrás de un marcador non-ESP cero de cuatro bytes, ESP encapsulado cuya posición de marcador contiene un SPI distinto de cero, y keepalives cortos. Ese marcador es lo que separa IKE del ESP encapsulado, así que lee esos bytes antes de etiquetar el tráfico como IKE. Una etiqueta de captura que lee 4500 es un número de puerto, no un protocolo.
El ESP encapsulado es carga cifrada que no puedes interpretar sin claves, y su presencia puede ser la señal de un túnel que funciona más que la de un fallo.
Vigila ambos puertos para el mismo intento, porque IKE puede pasar a 4500 tras la detección de NAT aunque se haya abierto en 500. Una traza filtrada solo en 500 parece silenciosa justo cuando la negociación tuvo éxito y se trasladó. Amplía el filtro y vuelve a leer la misma ventana temporal antes de sacar cualquier conclusión de la ausencia.
Qué significa el silencio en un punto de observación
Ninguna respuesta en el cliente demuestra solo lo que observó ese punto. El filtrado, el enrutamiento, la dirección remota equivocada, un servicio caído y una discrepancia de protocolo producen la misma traza vacía.
Un ICMP unreachable relevante añade pruebas, pero lee el paquete citado que contiene y anota la dirección del dispositivo que lo envió.
El rechazo de un router es un evento distinto de un error autenticado devuelto por el extremo, y solo el segundo demuestra que el servicio está vivo. Correlaciona el mismo intento con registros del servidor o una observación aprobada para saber si llegó la petición y si salió una respuesta. Mantén las capturas acotadas y privadas, porque los campos legibles del saludo no hacen inofensivo el resto del archivo. El resultado que merece la pena es una petición y una respuesta emparejadas, o un hueco documentado con un punto de observación nombrado.