IKE-SA establecida, CHILD-SA ausente: dónde se detienen los datos

El cliente dice que se autenticó, el estado de IKE parece sano y los contadores de paquetes siguen en cero. Esa combinación no es una contradicción: IKEv2 mantiene separadas la relación de control y la relación de datos, y la primera puede tener éxito mientras la segunda nunca se levanta. El padre lleva la negociación; el hijo lleva el tráfico. Lee las dos capas por separado antes de declarar el túnel caído.

Qué hacen las dos SA

La IKE-SA es la relación de control: autentica a los pares y transporta los intercambios que negocian, reemplazan y eliminan la protección. Nunca transporta los paquetes de tus aplicaciones. Por eso un padre sano solo demuestra que los dos extremos pueden acordar una política de seguridad, y nada más.

Una CHILD-SA es la relación de datos, creada bajo el padre, con selectores de tráfico y material de claves para un conjunto protegido. Es direccional, así que la salida de estado lista una asociación de entrada y otra de salida con identificadores separados, y normalmente contadores separados para cada dirección. Ese emparejamiento explica por qué una dirección puede funcionar mientras la otra cae, y por qué la frase el túnel está levantado no dice nada sobre el tráfico. Un padre también puede tener varios hijos, y así una sola etiqueta de conexión esconde el que necesitas.

Lee las entradas hijas, no la etiqueta de conexión

Abre el estado del padre y la lista de hijos a la vez, y encuentra el hijo cuyos selectores coincidan con el flujo que pruebas. Anota sus selectores de tráfico, los algoritmos negociados, su vida útil y los contadores en ambas direcciones. Si hay varios hijos, compara por selectores y no por posición, porque la posición cambia tras una renovación de claves. Escribe los identificadores antes de cambiar nada.

Si el padre lista un conjunto de tráfico distinto del que pruebas, estás leyendo el hijo equivocado. Eso es un problema de selectores, no un túnel roto.

Anota también las marcas de tiempo. La renovación de claves puede reemplazar una capa mientras la otra sigue establecida, y un hijo que parece nuevo puede ser el reemplazo del que estabas vigilando. Compara los identificadores antes de concluir que un hijo desapareció.

Cuando no existe ningún hijo

La autenticación puede tener éxito mientras la propuesta de datos o los selectores fallan, y el padre se queda sin ningún hijo. La causa habitual es una discrepancia de algoritmo o de selectores de tráfico, y ambos pares registran la propuesta rechazada. Lee los dos extremos, porque el lado al que llegas puede mostrar solo el rechazo. Corrige la discrepancia en vez de reiniciar el padre, que repite la misma negociación fallida y añade una interrupción a la evidencia.

Un padre que se reestablece una y otra vez es un fallo distinto de un padre que se mantiene sin hijo. En el segundo caso los registros nombran la propuesta rechazada, así que reúne esa propuesta de ambos extremos antes de editar una política.

Cuando el hijo existe pero los contadores siguen en cero

Envía una petición nueva que coincida con los selectores del hijo. Una petición a un destino fuera de esa política no moverá sus contadores, por exitosa que parezca.

Comprueba la ruta que debe empujar el flujo al túnel, porque un hijo sin tráfico suele ser un hijo al que nada se enruta. Los contadores que solo se mueven en una dirección apuntan a una discrepancia de selectores o de política en el camino de vuelta. Mira los selectores de vuelta del par remoto antes de tocar el lado local. Una petición nueva también te da una marca de tiempo para correlacionar con la salida de estado de ambos extremos.

Nombra la capa en el informe

Informa del fallo como tres campos en lugar de un veredicto: la capa que falló, el intercambio o hijo que inspeccionaste, y la evidencia que tienes. La capa es una de tres: el padre nunca se estableció, la negociación del hijo fue rechazada, o existe un hijo y el tráfico no llega a él. La evidencia es el identificador del hijo con sus selectores y contadores, o la propuesta rechazada citada de ambos registros. Quien lo lea puede ir directo al intercambio que importa en vez de preguntar a qué VPN te refieres.

La documentación de strongSwan sobre IKEv2 muestra cómo aparecen esas capas en la salida de estado. Adjunta la salida del hijo que probaste, no solo el resumen del padre.