Do strongSwan ao AWS Site-to-Site: por que a Child SA não seleciona nada

Um túnel IKE pode estar ativo enquanto a associação filha exclui as suas sub-redes. Compare primeiro os CIDR local e remoto da AWS com leftsubnet e rightsubnet.

O console indica up, o strongSwan relata uma associação IKE estabelecida e os pacotes continuam a não chegar. A próxima coisa a comparar não é a chave pré-compartilhada, mas o par de prefixos que cada lado acredita protegido pelo túnel. Percorra as verificações abaixo por ordem, porque as duas primeiras decidem se o túnel consegue sequer transportar o seu tráfego.

Traduza os nomes da AWS para os termos do strongSwan

A AWS descreve a ligação do lado do cliente: o endereço do gateway do cliente e o CIDR local são seus, e o CIDR remoto pertence à VPC. O strongSwan chama às duas extremidades left e right, com o seu prefixo em leftsubnet e o prefixo da VPC em rightsubnet. Inverter um par produz um túnel que negocia e seleciona o tráfego errado.

Descarregue a configuração que a AWS gera para a ligação e trate-a como a referência para essa ligação concreta, incluindo os endereços e prefixos do túnel. Se deixar os dois campos CIDR vazios na criação, o serviço usa o valor predefinido 0.0.0.0/0 em cada lado. Um router configurado com um prefixo estreito nunca coincidirá, por isso preencha os campos ou alargue o seletor de propósito.

Uma divergência aqui parece uma falha de encaminhamento e não é.

Fixe o endereço que a AWS vê realmente

Um router atrás de NAT pode originar IKE a partir de uma interface que o lado remoto nunca conheceu. O endereço do gateway registado na AWS tem de ser o que a AWS observa na rede, e o router tem de ser fixado ao mesmo endereço local em vez de seguir a rota predefinida.

conn %default
    local_addrs = 203.0.113.10

No strongSwan, local_addrs seleciona o endereço de origem para IKE, e as configurações antigas do OpenSwan escrevem a mesma ideia como left. Aponte-o para a interface que tem o endereço público, depois verifique no próprio dispositivo NAT que UDP 500 e 4500 chegam a esse anfitrião, porque uma regra que ficou de um router anterior os descarta em silêncio. Um par de seletores correto com o endereço de origem errado continua a falhar, e o registo culpará a proposta. É essa ilusão que faz o endereço de origem merecer a sua própria verificação.

Confirme a regra de reencaminhamento em vez de a presumir, porque uma regra que estava correta para o router anterior costuma ficar.

Trate a fase 1 e a fase 2 separadamente

A AWS expõe as opções de IKE e ESP como listas separadas. Um conjunto IKE que ambos os lados aceitam não diz nada sobre a proposta ESP, porque as duas listas são independentes. Leia ambas na configuração gerada e compare-as uma a uma.

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

A sintaxe não viaja entre implementações. Um par que funciona no OpenSwan, como phase2alg=aes_gcm com ike=aes256-sha1;modp1024, precisa de tradução para a forma esp= e ike= do strongSwan, e os nomes dos algoritmos diferem. Como o GCM autentica enquanto cifra, não precisa de uma transformação de integridade separada, ao contrário de um conjunto CBC emparelhado com SHA. Uma linha de fase 2 colada de um daemon para outro sem tradução produz uma rejeição que se lê como uma divergência de seletores.

Verifique a associação filha, não o indicador do túnel

Se a ligação carrega mas não aparece nenhuma associação filha, foi rejeitada a proposta ou os seletores. Se aparece uma filha e os seus seletores excluem os seus prefixos, os pacotes são filtrados antes de chegarem ao túnel. O indicador do console só cobre o nível IKE, por isso não lhe pode dizer qual das duas coisas aconteceu.

ipsec statusall

Procure a associação de segurança filha e leia os seletores de tráfego impressos ao lado, depois compare-os com os prefixos da configuração gerada.

Teste de um anfitrião dentro do prefixo local para um anfitrião dentro do prefixo da VPC, e verifique o caminho de retorno além de qualquer grupo de segurança ou ACL de rede do lado da AWS. Seletores corretos não impedem que um pacote seja descartado mais tarde.

Quando continua a falhar depois de os seletores coincidirem

Confirme que a rota dos dois lados aponta para o túnel e depois confirme que o dispositivo NAT não reescreve o tráfego de uma forma que a política não espera. Um túnel baseado em política compara endereços dos pacotes, por isso uma tradução aplicada depois da decisão de política altera o resultado.

Registe um pacote de entrada e um de saída em cada lado antes de alterar outra proposta.

Anote os seletores, as propostas de fase 1 e fase 2 e o endereço de origem no ticket. Esses quatro valores explicam a maioria das falhas site-to-site sem uma chamada.

Artigos relacionados