De strongSwan a AWS Site-to-Site: por que o Child SA non selecciona nada

Un túnel IKE pode estar activo mentres a asociación filla exclúe as súas subredes. Compare primeiro os CIDR local e remoto de AWS con leftsubnet e rightsubnet.

A consola indica up, strongSwan informa dunha asociación IKE establecida e os paquetes seguen sen chegar. O seguinte que hai que comparar non é a clave precompartida, senón o par de prefixos que cada lado cre que protexe o túnel. Percorra as comprobacións seguintes en orde, porque as dúas primeiras deciden se o túnel pode transportar o seu tráfico sequera.

Traduza os nomes de AWS aos termos de strongSwan

AWS describe a conexión desde o lado do cliente: o enderezo da pasarela do cliente e o CIDR local son seus, e o CIDR remoto pertence á VPC. strongSwan chama aos dous extremos left e right, co seu prefixo en leftsubnet e o prefixo da VPC en rightsubnet. Inverter un par produce un túnel que negocia e selecciona o tráfico equivocado.

Descargue a configuración que AWS xera para a conexión e trátea como a referencia desa conexión concreta, incluídos os enderezos do túnel e os prefixos. Se deixa ambos os campos CIDR baleiros ao creala, o servizo usa o valor predeterminado 0.0.0.0/0 en cada lado. Un enrutador configurado cun prefixo estreito nunca coincidirá entón, así que encha os campos ou amplíe o selector a propósito.

Unha discrepancia aquí parece un fallo de enrutamento e non o é.

Fixe o enderezo que AWS ve realmente

Un enrutador detrás de NAT pode orixinar IKE desde unha interface que o lado remoto nunca coñeceu. O enderezo da pasarela rexistrado en AWS ten que ser o que AWS observa na rede, e o enrutador debe fixarse ao mesmo enderezo local en lugar de seguir a súa ruta predeterminada.

conn %default
    local_addrs = 203.0.113.10

En strongSwan, local_addrs selecciona o enderezo de orixe para IKE, e as configuracións antigas de OpenSwan escriben a mesma idea como left. Apúnteo á interface que ten o enderezo público, logo verifique no propio dispositivo NAT que UDP 500 e 4500 chegan a ese host, porque unha regra que quedou dun enrutador anterior descártaos en silencio. Un par de selectores correcto co enderezo de orixe equivocado segue fallando, e o rexistro culpará a proposta. Ese desvío é a razón pola que o enderezo de orixe merece a súa propia comprobación.

Confirme a regra de reenvío en lugar de supoñela, porque unha regra que era correcta para o enrutador anterior adoita quedar.

Trate a fase 1 e a fase 2 por separado

AWS expón as opcións de IKE e ESP como listas separadas. Un conxunto IKE que ambos os lados aceptan non di nada sobre a proposta ESP, porque as dúas listas son independentes. Lea ambas na configuración xerada e compáraas unha a unha.

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

A sintaxe non viaxa entre implementacións. Un par que funciona en OpenSwan, como phase2alg=aes_gcm con ike=aes256-sha1;modp1024, necesita tradución á forma esp= e ike= de strongSwan, e os nomes dos algoritmos difiren. Como GCM autentica mentres cifra, non necesita unha transformación de integridade aparte, a diferenza dun conxunto CBC emparellado con SHA. Unha liña de fase 2 pegada dun demo a outro sen traducir produce un rexeitamento que se le como unha discrepancia de selectores.

Comprobe a asociación filla, non o indicador do túnel

Se a conexión se carga pero non aparece ningunha asociación filla, rexeitouse a proposta ou os selectores. Se aparece unha filla e os seus selectores exclúen os seus prefixos, os paquetes fíltranse antes de chegar ao túnel. O indicador da consola só cobre o nivel IKE, así que non pode dicirlle cal das dúas cousas ocorreu.

ipsec statusall

Busque a asociación de seguridade filla e lea os selectores de tráfico impresos ao lado, e despois compáraos cos prefixos da configuración xerada.

Probe desde un host dentro do prefixo local cara a un host dentro do prefixo da VPC, e comprobe a ruta de retorno ademais de calquera grupo de seguridade ou ACL de rede no lado de AWS. Uns selectores correctos non protexen un paquete de ser descartado máis adiante.

Cando segue fallando despois de que os selectores coincidan

Confirme que a ruta en ambos os lados apunta ao túnel, logo confirme que o dispositivo NAT non reescribe o tráfico dunha forma que a política non espera. Un túnel baseado en políticas compara enderezos de paquetes, así que unha tradución aplicada despois da decisión de política cambia o resultado.

Rexistre un paquete de entrada e un de saída en cada lado antes de cambiar outra proposta.

Anote os selectores, as propostas de fase 1 e fase 2 e o enderezo de orixe no tícket. Eses catro valores explican a maioría dos fallos site-to-site sen unha chamada.

Artigos relacionados