Su SA IKEv2 está activa pero no existe SA hija: lea el intercambio
La autenticación puede terminar mientras la negociación de la SA hija falla. Lea el intercambio de creación de la SA hija, luego la propuesta y los selectores, antes de las rutas o los contadores.
IKE dice que el túnel está activo, que falta la SA hija, y ambas afirmaciones pueden ser ciertas a la vez. Una relación de control establecida no es una asociación de datos, y los dos objetos tienen vidas, negociaciones y modos de fallo separados. Informar lo primero como conectividad es como un tique acaba afirmando que el túnel está activo mientras nada funciona. Lea la lista de asociaciones en lugar de la etiqueta resumen de la conexión, porque esa lista es el único lugar donde el objeto que falta es visible. Lo que sigue es el orden en el que la lista tiene sentido.
Dos asociaciones, dos trabajos
Una SA IKE lleva el canal de control: identidades, claves y las propuestas para el propio intercambio de control. Una SA hija lleva la protección ESP, con sus propios algoritmos y sus propios selectores de tráfico. La autenticación y la creación de la SA hija suelen viajar juntas, porque la primera SA hija se negocia dentro de IKE_AUTH, y justo ese agrupamiento sorprende a la gente con la separación.
También explica las dos formas de fallo que encontrará. Una SA hija rechazada durante el intercambio inicial normalmente arrastra consigo la SA IKE, así que no ve ningún canal de control establecido. Una SA IKE que queda sola suele significar que la primera SA hija tuvo éxito y que un intento posterior de crear una SA hija falló, por ejemplo durante una renovación de claves. Las marcas de tiempo separan esos casos más rápido que cualquier revisión de la configuración.
Qué capa rechazó
Cuando se rechaza una SA hija, la notificación nombra la capa. Un rechazo de propuesta significa que las partes no pudieron ponerse de acuerdo sobre algoritmos, a menudo porque una exige un grupo de secreto perfecto hacia adelante distinto o un cifrado que la otra no aceptará. Un rechazo de selector significa que el conjunto de tráfico fue rechazado de plano, y eso es un argumento de cobertura, no criptográfico.
A veces la ausencia de SA hija es el diseño. Una SA IKE sin SA hija es una extensión definida que se usa donde la asociación de datos debe crearse a demanda, así que la ausencia es correcta y la SA hija aparece cuando llega tráfico coincidente. Las notas de strongSwan sobre IKEv2 cubren tanto el estilo a demanda como los ajustes de propuesta que deciden el primer caso.
Compruebe si hay una configuración a demanda o de trampa antes de diagnosticar una avería. Si las SA hijas se crean de forma perezosa, ninguna SA hija en reposo es el estado esperado y la prueba real es si el tráfico levanta una. Esa prueba también separa un diseño perezoso de un fallo silencioso, porque una creación fallida deja el disparador sin respuesta en lugar de solo en reposo.
Luego pregunte por la ruta de datos
Una vez que existe una SA hija, los contadores responden a la siguiente pregunta. ip -s xfrm state informa los recuentos de paquetes y bytes por asociación, y una SA hija que no transporta nada mientras genera tráfico apunta a coincidencia o enrutamiento en lugar de a una asociación que falta. swanctl --list-sas imprime los selectores de la SA hija junto a esos contadores, y eso confirma que el paquete está dentro del conjunto aceptado.
Mantenga la autenticación exitosa y el intercambio fallido de la SA hija separados en el informe. Un informe que dice que la autenticación falló envía al siguiente ingeniero al almacén de certificados, y la frase exacta es mucho más corta: la SA IKE subió, y la SA hija para este flujo nunca se aceptó.
Correlacione los dos extremos
Para un servidor que usted ejecuta, tome los registros del cliente y de la pasarela del mismo intercambio en lugar de comparar dos intentos de reconexión con una hora de diferencia. Las notificaciones deberían coincidir en ambos lados, y donde no coinciden ha encontrado el extremo mal configurado.
Corrija la negociación de la SA hija y luego vuelva a probar con tráfico dentro del selector previsto. Esa es la única prueba que demuestra que el objeto que faltaba ahora está presente, porque una lista de asociaciones refrescada en reposo puede verse idéntica antes y después de la corrección.