De strongSwan a AWS Site-to-Site: por qué el Child SA no selecciona nada

Un túnel IKE puede estar activo mientras la asociación secundaria excluye sus subredes. Compare primero los CIDR local y remoto de AWS con leftsubnet y rightsubnet.

La consola indica up, strongSwan informa de una asociación IKE establecida y los paquetes siguen sin llegar. Lo siguiente que hay que comparar no es la clave precompartida, sino el par de prefijos que cada lado cree que protege el túnel. Recorra las comprobaciones siguientes en orden, porque las dos primeras deciden si el túnel puede transportar su tráfico siquiera.

Traduzca los nombres de AWS a los términos de strongSwan

AWS describe la conexión desde el lado del cliente: la dirección de la puerta de enlace del cliente y el CIDR local son suyos, y el CIDR remoto pertenece a la VPC. strongSwan llama a los dos extremos left y right, con su prefijo en leftsubnet y el prefijo de la VPC en rightsubnet. Invertir un par produce un túnel que negocia y selecciona el tráfico equivocado.

Descargue la configuración que AWS genera para la conexión y trátela como la referencia de esa conexión concreta, incluidas las direcciones del túnel y los prefijos. Si deja ambos campos CIDR vacíos al crearla, el servicio usa el valor predeterminado 0.0.0.0/0 en cada lado. Un enrutador configurado con un prefijo estrecho nunca coincidirá entonces, así que rellene los campos o amplíe el selector a propósito.

Una discrepancia aquí parece un fallo de enrutamiento y no lo es.

Fije la dirección que AWS ve realmente

Un enrutador detrás de NAT puede originar IKE desde una interfaz que el lado remoto nunca conoció. La dirección de puerta de enlace registrada en AWS tiene que ser la que AWS observa en la red, y el enrutador debe fijarse a la misma dirección local en lugar de seguir su ruta predeterminada.

conn %default
    local_addrs = 203.0.113.10

En strongSwan, local_addrs selecciona la dirección de origen para IKE, y las configuraciones antiguas de OpenSwan escriben la misma idea como left. Apúntelo a la interfaz que tiene la dirección pública, luego verifique en el propio dispositivo NAT que UDP 500 y 4500 llegan a ese host, porque una regla que quedó de un enrutador anterior las descarta en silencio. Un par de selectores correcto con la dirección de origen equivocada sigue fallando, y el registro culpará a la propuesta. Ese desvío es la razón por la que la dirección de origen merece su propia comprobación.

Confirme la regla de reenvío en lugar de suponerla, porque una regla que era correcta para el enrutador anterior suele quedarse.

Trate la fase 1 y la fase 2 por separado

AWS expone las opciones de IKE y ESP como listas separadas. Un conjunto IKE que ambos lados aceptan no dice nada sobre la propuesta ESP, porque las dos listas son independientes. Lea ambas en la configuración generada y compárelas una a una.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

La sintaxis no viaja entre implementaciones. Un par que funciona en OpenSwan, como phase2alg=aes_gcm con ike=aes256-sha1;modp1024, necesita traducción a la forma esp= e ike= de strongSwan, y los nombres de los algoritmos difieren. Como GCM autentica mientras cifra, no necesita una transformación de integridad aparte, a diferencia de un conjunto CBC emparejado con SHA. Una línea de fase 2 pegada de un demonio a otro sin traducir produce un rechazo que se lee como una discrepancia de selectores.

Compruebe la asociación secundaria, no el indicador del túnel

Si la conexión se carga pero no aparece ninguna asociación secundaria, se rechazó la propuesta o los selectores. Si aparece una secundaria y sus selectores excluyen sus prefijos, los paquetes se filtran antes de llegar al túnel. El indicador de la consola solo cubre el nivel IKE, así que no puede decirle cuál de las dos cosas ocurrió.

ipsec statusall

Busque la asociación de seguridad secundaria y lea los selectores de tráfico impresos junto a ella, luego compárelos con los prefijos de la configuración generada.

Pruebe desde un host dentro del prefijo local hacia un host dentro del prefijo de la VPC, y compruebe la ruta de retorno además de cualquier grupo de seguridad o ACL de red en el lado de AWS. Unos selectores correctos no protegen un paquete de que se descarte más adelante.

Cuando sigue fallando después de que los selectores coincidan

Confirme que la ruta en ambos lados apunta al túnel, luego confirme que el dispositivo NAT no reescribe el tráfico de una forma que la política no espera. Un túnel basado en políticas compara direcciones de paquetes, así que una traducción aplicada después de la decisión de política cambia el resultado.

Registre un paquete de entrada y uno de salida en cada lado antes de cambiar otra propuesta.

Anote los selectores, las propuestas de fase 1 y fase 2 y la dirección de origen en el ticket. Esos cuatro valores explican la mayoría de los fallos site-to-site sin una llamada.

Artículos relacionados