strongSwan na EC2: faça a VPC encaminhar a carga de trabalho

O túnel está ativo, a instância do gateway consegue fazer ping à rede remota, e a instância de aplicação ao lado não alcança nada. Nada está quebrado. O teste que passou começou no host VPN, e nunca perguntou se esse host poderia transportar um endereço de origem diferente pela mesma relação IPsec. Este runbook fecha essa lacuna em quatro passos, na ordem que mantém cada falha visível.

Primeiro, anote os quatro endereços

Cada passo abaixo remete a eles, então preencha-os para a sua própria conta antes de tocar numa tabela de rotas.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

O exemplo pressupõe uma ligação IPsec baseada em políticas aprovada e funcional, e um fluxo que preserva a origem. Isto não é um cliente de acesso remoto com NAT que toma emprestado um endereço atribuído, e essa diferença decide se os seletores têm de mudar.

Passo 1: dê uma rota à sub-rede da carga

A tabela de rotas realmente associada à sub-rede da carga precisa de um caminho para o prefixo remoto que aponte para a interface de rede do gateway. Uma rota de convidado instalada dentro da instância não é uma entrada nessa tabela de rotas da AWS, e nenhuma quantidade de configuração strongSwan criará uma.

As orientações da AWS sobre encaminhamento por appliance descrevem destinos de interface de rede e o requisito de verificação de origem/destino da instância que encaminha. Limite essa alteração de verificação à função de gateway e deixe as instâncias de aplicação comuns em paz.

Não substitua a rota local da VPC nem todas as entradas existentes para abrir espaço a uma rede aprovada. Inspecione o que está associado e ativo, em vez do que uma página da consola mostra para uma tabela de rotas que ninguém usa. Duas tabelas parecidas podem ter associações diferentes. A que importa é aquela a que a sub-rede da carga está ligada.

Passo 2: ative o encaminhamento no convidado

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

O kernel tem de encaminhar e a firewall do host tem de permitir o trânsito. Adicione as regras de encaminhamento previstas para os prefixos da carga e remotos em vez de aceitar tudo, e confirme que a sub-rede do gateway mantém uma rota de transporte utilizável para o seu próprio tráfego.

Os grupos de segurança são onde este passo costuma encravar. Um dispositivo intermédio não herda o comportamento de referência de grupos de segurança da comunicação direta entre instâncias, por isso uma regra copiada de um exemplo de Client VPN gerido pode nunca corresponder. Verifique o grupo de segurança e a ACL da sub-rede no caminho real, em ambos os sentidos.

Passo 3: amplie os seletores para as origens reais

Uma política que só cobre 10.60.1.10/32 do lado da AWS explica um sucesso originado no gateway sem cobrir 10.60.2.20. Uma rota para o destino remoto não amplia um seletor de tráfego, e essa é a segunda metade da mesma surpresa.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Se o desenho acordado proteger toda a VPC, ambos os pares têm de aceitar 10.60.0.0/16 e 10.90.0.0/24. Se proteger uma só carga, use deliberadamente esse prefixo mais estreito. Em qualquer caso, inspecione a política CHILD-SA instalada, porque uma configuração que editou e um par que a restringiu de outra forma não são o mesmo acordo.

O local remoto também tem de encaminhar as respostas das origens da VPC preservadas de volta pelo gateway IPsec previsto. Mantenha a isenção de NAT suportada para o tráfego protegido onde existirem outras regras de NAT de origem; traduzir uma carga não aprovada num endereço de host permitido é outro contrato de identidade, não um atalho para o acesso que queria.

Passo 4: verifique e, se necessário, reverta

Teste a partir da própria carga com uma operação de aplicação permitida e nova, e depois repita com um destino que deveria ficar excluído. Registe o endereço de origem que o serviço remoto vê e o caminho de retorno que utiliza. Um ping ao gateway ou um estado IKE verde não é esse teste.

Se a carga continuar a falhar enquanto o gateway funciona, recue pelos passos por ordem: seletor, depois encaminhamento e grupos de segurança, depois a tabela de rotas associada. Cada um tem um sintoma distinto, e adivinhar salta aquele que está realmente errado.

A reversão inverte a mesma ordem. Remova a rota da sub-rede da carga por último, depois de restaurar os seletores anteriores, para não deixar uma sub-rede a apontar para um gateway que já não protege as suas origens. O alojamento próprio pode servir mais do que o host do gateway quando estes contratos se verificam, e a VPN Site-to-Site gerida pela AWS é um modelo operacional diferente em que o strongSwan pode estar do lado do gateway do cliente.