¿VGW o TGW? Dónde termina el túnel IPsec de AWS Site-to-Site

La gente pregunta dónde deja una VPN Site-to-Site de AWS de proteger el paquete y espera una única respuesta: en la pasarela. La versión útil de esa respuesta dice qué pasarela, porque una pasarela privada virtual y una pasarela de tránsito son disposiciones distintas con objetos de conexión distintos, y el revisor que asume la equivocada construye el resto de la evaluación sobre un diagrama que no existe. Realiza las tres comprobaciones siguientes en orden. Cada una o bien confirma el límite o bien te dice que la respuesta anterior trataba de otro recurso.

Nombra los tres extremos antes de evaluar nada

Una revisión del cifrado de esta ruta necesita tres cosas nombradas: la pasarela de cliente, el destino de VPN de AWS que termina IPsec y el extremo de aplicación que recibe el paquete interno. Anótalos con sus identificadores de recurso antes de abrir una sola página de la consola, porque todo lo que viene después es una afirmación sobre uno de esos tres.

La pasarela de cliente es tuya y su configuración es visible para ti. El destino de AWS es un recurso gestionado, y el error es darlo por supuesto: una conexión VPN puede asociarse a una pasarela privada virtual o directamente a una pasarela de tránsito, y ninguna implica la otra. El tercer extremo es el que la gente omite, y es el único que responde a la pregunta real sobre los datos de la aplicación.

Comprobación 1: qué pasarela termina realmente el túnel

Ambas disposiciones están soportadas y la guía de arquitectura de Site-to-Site VPN las describe una junto a otra, así que pregunta a la API en lugar de a un diagrama que a menudo tiene un año. Una consulta de solo lectura sobre una conexión devuelve los campos de destino de VPN:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

El discriminante es TransitGatewayId, no VpnGatewayId. Una conexión con TransitGatewayId vacío termina en una pasarela privada virtual independiente, mientras que una conexión con ese campo establecido termina en una conexión VPN de pasarela de tránsito, y VpnGatewayId puede seguir relleno en ese caso porque puede nombrar la pasarela de respaldo de la conexión. Lee primero el campo TGW y luego confirma el tipo de conexión en la lista de conexiones, no por el nombre de un campo, porque una conexión de VPC en esa pasarela de tránsito no es la conexión VPN. Encontrar la instancia de destino en una VPC asociada no te dice nada sobre qué conexión VPN transportó el paquete.

Ya que estás ahí, revisa los túneles. La conexión lleva dos túneles IPsec por redundancia, y una conexión cuyo segundo túnel nunca se ha levantado es un hallazgo real para la disponibilidad aunque no cambie nada del límite del cifrado:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Comprobación 2: qué sigue llevando el paquete interno

Una vez que IPsec termina, AWS reenvía el paquete desencapsulado por la ruta que coincidía con él. Desde ese punto el tráfico es tráfico de VPC ordinario, y la protección de la VPN ha terminado. Eso no es un hueco del servicio; es lo que significa el límite, y el punto de la lista es decirlo con claridad en lugar de dejar que "la VPN está cifrada" sustituya a "los datos están cifrados de extremo a extremo".

Ahora examina qué había dentro. Si el paquete interno es un protocolo de aplicación en texto plano, nada aguas abajo añade confidencialidad hasta que otra cosa lo cifre. Si el paquete interno ya lleva una sesión TLS, la retirada del IPsec exterior no cambia nada para esa sesión: sigue protegida hasta su propio extremo, esté donde esté.

La sobrecorrección habitual es concluir que todo lo que hay detrás de la pasarela está expuesto. No lo está. El transporte del servicio, el cifrado del almacenamiento y el TLS de la aplicación son mecanismos separados con condiciones separadas, y cada uno debe evaluarse en sus propios términos en lugar de inferirse de la forma de la VPN. Una entrada del registro de flujos que muestra ACCEPT demuestra que el enrutamiento funcionó y no dice nada sobre la confidencialidad, que es exactamente el error que esta lista existe para evitar.

Comprobación 3: qué termina el TLS detrás de la pasarela

Sigue al receptor, no a la dirección. Si un balanceador de carga o un proxy termina TLS, la conexión que mantiene tu cliente acaba ahí, y el proxy abre una segunda conexión al backend que puede ser texto plano o TLS con otra cadena de confianza. Una dirección IP privada y una ruta coincidente no son prueba sobre esa segunda conexión.

Prueba el extremo que de verdad te importa desde dentro de la VPC, con el nombre que usa la aplicación y no con una IP que resolviste una vez:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

Repítelo para cada salto por el que pasa la petición. Si la respuesta difiere entre el nombre de cara al cliente y el nombre del backend, has encontrado exactamente el segmento que la VPN nunca cubrió, y ese es el hallazgo que hay que anotar.

Registra el resultado como segmentos, no como veredicto

La salida de esta lista es una tabla pequeña con una fila por segmento: pasarela de cliente a destino de VPN de AWS, pasarela a carga de trabajo, carga de trabajo a almacén de datos y cualquier salto de proxy intermedio. Cada fila dice qué lo protege y de qué depende esa protección. "Cifrado" sin mecanismo y sin extremo no es una fila.

Luego responde al requisito original con los mismos términos con que se planteó. Si el requisito es que los datos sigan siendo confidenciales hasta que la carga de trabajo los reciba, la VPN satisface solo el primer segmento, y las filas restantes necesitan transporte de aplicación, TLS de servicio o cifrado de almacenamiento configurados y verificados por separado.

Conserva los identificadores de conexión, los estados de los túneles y los sujetos de los certificados en el registro. Cuando alguien vuelva al diseño dentro de seis meses, esos tres artefactos responden la pregunta del límite en minutos en lugar de reiniciar la discusión desde un diagrama.