strongSwan en EC2: haz que la VPC enrute la carga de trabajo

El túnel está activo, la instancia de puerta de enlace puede hacer ping a la red remota y la instancia de aplicación de al lado no llega a nada. Nada está roto. La prueba que salió bien se originó en el host VPN y nunca preguntó si ese host podía transportar una dirección de origen distinta por la misma relación IPsec. Este runbook cierra esa brecha en cuatro pasos, en el orden que mantiene visible cada fallo.

Primero, escribe las cuatro direcciones

Cada paso de abajo remite a ellas, así que rellénalas para tu propia cuenta antes de tocar una tabla 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

El ejemplo supone una conexión IPsec basada en políticas aprobada y funcional, y un flujo que preserva el origen. No es un cliente de acceso remoto con NAT que toma prestada una dirección asignada, y esa diferencia decide si los selectores tienen que cambiar.

Paso 1: dale una ruta a la subred de carga

La tabla de rutas realmente asociada a la subred de carga necesita una ruta para el prefijo remoto que apunte a la interfaz de red de la puerta de enlace. Una ruta de invitado instalada dentro de la instancia no es una entrada en esa tabla de rutas de AWS, y ninguna cantidad de configuración de strongSwan creará una.

La guía de enrutamiento mediante dispositivos de AWS describe los destinos de interfaz de red y el requisito de comprobación de origen/destino de la instancia que reenvía. Limita ese cambio de comprobación al rol de puerta de enlace y deja en paz las instancias de aplicación normales.

No sustituyas la ruta local de la VPC ni todas las entradas existentes para hacer sitio a una red aprobada. Inspecciona qué está asociado y activo, en lugar de lo que muestra una página de consola para una tabla de rutas que nadie usa. Dos tablas parecidas pueden tener asociaciones distintas. La que importa es a la que está conectada la subred de carga.

Paso 2: activa el reenvío en el invitado

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

El kernel tiene que reenviar y el firewall del host tiene que permitir el tránsito. Añade las reglas de reenvío previstas para los prefijos de carga y remotos en lugar de aceptarlo todo, y confirma que la subred de puerta de enlace conserva una ruta de transporte utilizable para su propio tráfico.

Los grupos de seguridad son donde este paso suele atascarse. Un intermediario no hereda el comportamiento de referencia de grupos de seguridad de la comunicación directa entre instancias, así que una regla copiada de un ejemplo de Client VPN gestionado puede no coincidir nunca. Comprueba el grupo de seguridad y la ACL de subred en la ruta real, en ambos sentidos.

Paso 3: amplía los selectores a las fuentes reales

Una política que solo cubre 10.60.1.10/32 en el lado de AWS explica un éxito originado en la puerta de enlace sin cubrir 10.60.2.20. Una ruta hacia el destino remoto no amplía un selector de tráfico, y esa es la segunda mitad de la misma sorpresa.

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

Si el diseño acordado protege toda la VPC, ambos pares deben aceptar 10.60.0.0/16 y 10.90.0.0/24. Si protege una sola carga, usa deliberadamente ese prefijo más estrecho. En cualquier caso, inspecciona la política CHILD-SA instalada, porque una configuración que has editado y un par que la ha estrechado de otra forma no son el mismo acuerdo.

El sitio remoto también debe enrutar las respuestas de las fuentes de VPC preservadas de vuelta por la puerta de enlace IPsec prevista. Mantén la exención de NAT admitida para el tráfico protegido donde existan otras reglas de NAT de origen; traducir una carga no aprobada a una dirección de host permitida es otro contrato de identidad, no un atajo hacia el acceso que querías.

Paso 4: verifica y, si hace falta, revierte

Prueba desde la propia carga con una operación de aplicación permitida y nueva, y luego repite con un destino que debería quedar excluido. Anota la dirección de origen que ve el servicio remoto y la ruta de vuelta que usa. Un ping a la puerta de enlace o un estado IKE en verde no son esa prueba.

Si la carga sigue fallando mientras la puerta de enlace funciona, recorre los pasos en orden inverso: selector, luego reenvío y grupos de seguridad, luego la tabla de rutas asociada. Cada uno tiene un síntoma distinto, y adivinar se salta el que está realmente mal.

La reversión invierte el mismo orden. Quita la ruta de la subred de carga al final, después de restaurar los selectores anteriores, para no dejar una subred apuntando a una puerta de enlace que ya no protege sus fuentes. El autoalojamiento puede servir más que el host de puerta de enlace cuando se cumplen estos contratos, y la VPN de sitio a sitio gestionada por AWS es un modelo operativo distinto en el que strongSwan puede estar en el extremo de la puerta de enlace del cliente.