strongSwan en EC2: fai que a VPC encamiñe a carga de traballo

O túnel está activo, a instancia da pasarela pode facer ping á rede remota e a instancia de aplicación de ao lado non chega a nada. Nada está roto. A proba que saíu ben orixinouse no host VPN e nunca preguntou se ese host podía transportar un enderezo de orixe distinto pola mesma relación IPsec. Este runbook pecha esa fenda en catro pasos, na orde que mantén visible cada fallo.

Primeiro escribide os catro enderezos

Cada paso de abaixo refírese a eles, así que enchédeos para a vosa propia conta antes de tocar unha táboa de rutas.

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 supón unha conexión IPsec baseada en políticas aprobada e funcional, e un fluxo que preserva a orixe. Non é un cliente de acceso remoto con NAT que toma prestado un enderezo asignado, e esa diferenza decide se os selectores teñen que cambiar.

Paso 1: dádelle unha ruta á subrede de carga

A táboa de rutas realmente asociada á subrede de carga necesita un camiño para o prefixo remoto que apunte á interface de rede da pasarela. Unha ruta de convidado instalada dentro da instancia non é unha entrada nesa táboa de rutas de AWS, e ningunha cantidade de configuración de strongSwan creará unha.

A guía de encamiñamento mediante dispositivos de AWS describe os destinos de interface de rede e o requisito de comprobación de orixe/destino da instancia que reenvía. Limita ese cambio de comprobación ao rol de pasarela e deixa en paz as instancias de aplicación normais.

Non substitúas a ruta local da VPC nin todas as entradas existentes para facer sitio a unha rede aprobada. Inspecciona que está asociado e activo, en lugar do que mostra unha páxina de consola para unha táboa de rutas que ninguén usa. Dúas táboas parecidas poden ter asociacións distintas. A que importa é á que está conectada a subrede de carga.

Paso 2: activade o reenvío no convidado

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

O kernel ten que reenviar e a devasa do host ten que permitir o tránsito. Engadide as regras de reenvío previstas para os prefixos de carga e remotos en lugar de aceptalo todo, e confirmade que a subrede da pasarela conserva unha ruta de transporte utilizábel para o seu propio tráfico.

Os grupos de seguridade son onde este paso adoita atascarse. Un intermediario non herda o comportamento de referencia de grupos de seguridade da comunicación directa entre instancias, así que unha regra copiada dun exemplo de Client VPN xestionado pode non coincidir nunca. Comprobade o grupo de seguridade e a ACL da subrede na ruta real, en ambos os sentidos.

Paso 3: ampliade os selectores ás fontes reais

Unha política que só cobre 10.60.1.10/32 no lado de AWS explica un éxito orixinado na pasarela sen cubrir 10.60.2.20. Unha ruta cara ao destino remoto non amplía un selector de tráfico, e esa é a segunda metade da mesma sorpresa.

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

Se o deseño acordado protexe toda a VPC, ambos os pares deben aceptar 10.60.0.0/16 e 10.90.0.0/24. Se protexe unha soa carga, usade deliberadamente ese prefixo máis estreito. En calquera caso, inspeccionade a política CHILD-SA instalada, porque unha configuración que editastes e un par que a estreitou doutro xeito non son o mesmo acordo.

O sitio remoto tamén debe encamiñar as respostas das fontes de VPC preservadas de volta pola pasarela IPsec prevista. Mantede a exención de NAT admitida para o tráfico protexido onde existan outras regras de NAT de orixe; traducir unha carga non aprobada a un enderezo de host permitido é outro contrato de identidade, non un atallo cara ao acceso que queríades.

Paso 4: verificade e, se fai falta, revertede

Probade desde a propia carga cunha operación de aplicación permitida e nova, e despois repetide cun destino que debería quedar excluído. Anotade o enderezo de orixe que ve o servizo remoto e a ruta de volta que usa. Un ping á pasarela ou un estado IKE en verde non son esa proba.

Se a carga segue fallando mentres a pasarela funciona, retroceded polos pasos en orde: selector, despois reenvío e grupos de seguridade, despois a táboa de rutas asociada. Cada un ten un síntoma distinto, e adiviñar salta o que está realmente mal.

A reversión inverte a mesma orde. Retirade a ruta da subrede de carga ao final, despois de restaurar os selectores anteriores, para non deixar unha subrede apuntando a unha pasarela que xa non protexe as súas fontes. O autoaloxamento pode servir máis que o host da pasarela cando se cumpren estes contratos, e a VPN de sitio a sitio xestionada por AWS é un modelo operativo distinto no que strongSwan pode estar no extremo da pasarela do cliente.