Cuando IKEv2 devuelve TS_UNACCEPTABLE, compare las subredes reales

Lea TS_UNACCEPTABLE como un desacuerdo de cobertura, no como un perfil dañado. La puerta de enlace dice que los dos pares no lograron acordar qué direcciones puede transportar este túnel. La IKE SA ya puede estar activa en ese momento, por eso un cliente puede parecer conectado sin ninguna SA hija detrás. Una vez que lo plantea así, el trabajo se vuelve mecánico. Anote los prefijos previstos de ambos lados, compárelos en una sola dirección y estreche hasta que se crucen.

Primero anote los pares previstos

Antes de tocar la configuración, enumere cuatro valores: el rango de origen del iniciador, su rango de destino y el mismo par visto desde el respondiente. Anote también la familia de direcciones de cada uno. Un rango IPv4 y un rango IPv6 son tipos de selector distintos, y ninguno puede plegarse en la carga útil del otro.

Añada cualquier restricción de protocolo o puerto que lleve la política. Una regla que solo permite TCP 445 hacia un servidor de archivos describe un conjunto más estrecho que la subred en la que se encuentra. Si lo deja fuera de sus notas, el resultado de la negociación parecerá incoherente por razones que no ve.

Invierta las etiquetas antes de compararlas

Local y remoto son etiquetas relativas. El prefijo local del cliente es el rango remoto de la puerta de enlace, y el rango local de la puerta de enlace es el remoto del cliente. Por eso las capturas de pantalla de los dos extremos nunca coinciden, y compararlas literalmente es la forma habitual de perder una tarde.

Un respondiente puede estrechar una oferta hasta un subconjunto aceptable en lugar de rechazarla. Ese resultado es peor que un fallo limpio, porque funciona a medias. Pida 10.0.0.0/16 cuando la política permite 10.0.5.0/24 y puede acabar con una SA hija que cubre solo ese /24. Un host responde, todo lo demás queda fuera, y nada en el cliente lo dice. Lea los selectores aceptados y no los solicitados antes de concluir que la negociación tuvo éxito.

Los perfiles road warrior que piden una ruta predeterminada caen aquí constantemente. Una puerta de enlace construida para acceso dividido estrecha una oferta de rango completo a sus propias subredes, y el cliente debe aceptar el resultado estrechado o fallar ruidosamente.

Lea el rechazo a partir de un solo intento

Recoja ambos registros del mismo intento de conexión. Un perfil guardado muestra lo que usted configuró, no lo que se propuso, y en strongSwan swanctl --log imprime la notificación recibida junto con los selectores que llevaba.

Después inspeccione qué se instaló realmente. swanctl --list-sas muestra los selectores de la SA hija, y ip xfrm policy muestra los mismos rangos como entradas de política del núcleo. Una SA hija en esa lista con selectores que no pretendía es un evento de estrechamiento; ninguna SA hija más TS_UNACCEPTABLE en el registro es un rechazo.

Mientras esté ahí, separe los vecinos cercanos. INVALID_SELECTORS se queja de un selector dentro de una SA hija establecida, mientras que INTERNAL_ADDRESS_FAILURE significa que el respondiente no pudo asignar una dirección virtual, lo cual es un problema de pozo y no de cobertura.

Compruebe qué encoge el conjunto en silencio

Tres cosas encogen un conjunto de selectores sin decir nada. La política del respondiente es la primera, mediante listas de subredes, reglas de grupo o autorización por usuario que reducen la oferta a un subconjunto. La familia de direcciones es la segunda: un cliente de doble pila suele proponer IPv6 junto a IPv4 y recibe un rechazo por rangos que la puerta de enlace nunca configuró.

Las restricciones de protocolo y puerto son la tercera. Donde la política solo permite TCP 445, una SA hija puede levantarse mientras ICMP y UDP quedan fuera, y el usuario informa de un túnel roto cuando un solo protocolo era todo lo que se había permitido.

Por tanto, ampliar solo las direcciones no puede arreglar una política restringida por puerto, que es el caso con más probabilidades de sobrevivir intacto a tres rondas de diagnóstico.

Demuestre la cobertura con tráfico que encaje

Una vez instalada la SA hija, envíe una petición que caiga con seguridad dentro de los rangos aceptados. Mire los contadores en lugar del icono de estado: ip -s xfrm state y los contadores detrás de ip xfrm policy aumentan cuando un paquete coincide y se protege. Un recuento de bytes que se queda en cero tras tráfico real significa que el núcleo nunca seleccionó esa política.

Ese cero es un problema de enrutamiento o de orden de políticas, no de criptografía. También parece idéntico a un rechazo de selector desde el asiento del usuario, por eso vale la pena recoger los contadores antes de reabrir el perfil. Los contadores que solo suben en una dirección apuntan más bien al camino de vuelta.

Termine escribiendo el par aceptado en el ticket, junto al rango que se solicitó originalmente. Mantenga la selección tan estrecha como el requisito, porque borrar el error sustituyendo un rango privado por todas las direcciones concede mucho más acceso del que se aprobó para la cuenta.