VGW ou TGW? Onde remata o túnel IPsec de AWS Site-to-Site

A xente pregunta onde deixa unha VPN Site-to-Site de AWS de protexer o paquete e espera unha resposta única: na pasarela. A versión útil desa resposta di cal pasarela, porque unha pasarela privada virtual e unha pasarela de tránsito son disposicións distintas con obxectos de adhesión distintos, e o revisor que asume a equivocada constrúe o resto da avaliación sobre un diagrama que non existe. Fai as tres comprobacións seguintes en orde. Cada unha ou confirma o límite ou diche que a resposta anterior trataba doutro recurso.

Nomea os tres extremos antes de avaliar nada

Unha revisión do cifrado desta ruta necesita tres cousas nomeadas: a pasarela de cliente, o destino de VPN de AWS que remata IPsec e o extremo da aplicación que recibe o paquete interno. Anótaos cos seus identificadores de recurso antes de abrir unha soa páxina da consola, porque todo o que vén despois é unha afirmación sobre un deses tres.

A pasarela de cliente é túa e a súa configuración é visible para ti. O destino de AWS é un recurso xestionado, e o erro é dalo por suposto: unha conexión VPN pode adherirse a unha pasarela privada virtual ou directamente a unha pasarela de tránsito, e ningunha implica a outra. O terceiro extremo é o que a xente omite, e é o único que responde á pregunta real sobre os datos da aplicación.

Comprobación 1: que pasarela remata realmente o túnel

Ambas as disposicións están soportadas e a guía de arquitectura de Site-to-Site VPN descríbeas unha xunto á outra, así que pregunta á API en lugar dun diagrama que a miúdo ten un ano. Unha consulta de só lectura sobre unha conexión devolve os 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}'

O discriminante é TransitGatewayId, non VpnGatewayId. Unha conexión con TransitGatewayId baleiro remata nunha pasarela privada virtual independente, mentres que unha conexión con ese campo definido remata nunha adhesión VPN de pasarela de tránsito, e VpnGatewayId pode seguir cuberto nese caso porque pode nomear a pasarela de respaldo da adhesión. Le primeiro o campo TGW e despois confirma o tipo de adhesión na lista de adhesións, non polo nome dun campo, porque unha adhesión de VPC nesa pasarela de tránsito non é a adhesión VPN. Atopar a instancia de destino nun VPC adherido non che di nada sobre que adhesión VPN transportou o paquete.

Xa que estás alí, revisa os túneles. A conexión leva dous túneles IPsec por redundancia, e unha conexión cuxo segundo túnel nunca se levantou é un achado real para a dispoñibilidade aínda que non cambie nada do límite do 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: que segue levando o paquete interno

Unha vez que IPsec remata, AWS reenvía o paquete desencapsulado pola ruta que coincidía con el. Desde ese punto o tráfico é tráfico de VPC ordinario, e a protección da VPN rematou. Iso non é un oco do servizo; é o que significa o límite, e o punto da lista é dicilo con claridade en lugar de deixar que "a VPN está cifrada" substitúa "os datos están cifrados de extremo a extremo".

Agora examina que había dentro. Se o paquete interno é un protocolo de aplicación en texto plano, nada augas abaixo engade confidencialidade ata que outra cousa o cifre. Se o paquete interno xa leva unha sesión TLS, a retirada do IPsec exterior non cambia nada para esa sesión: segue protexida ata o seu propio extremo, estea onde estea.

A sobrecorrección habitual é concluír que todo o que está detrás da pasarela está exposto. Non o está. O transporte do servizo, o cifrado do almacenamento e o TLS da aplicación son mecanismos separados con condicións separadas, e cada un debe avaliarse nos seus propios termos en lugar de inferirse da forma da VPN. Unha entrada do rexistro de fluxos que mostra ACCEPT demostra que o encamiñamento funcionou e non di nada sobre a confidencialidade, que é exactamente o erro que esta lista existe para evitar.

Comprobación 3: que remata o TLS detrás da pasarela

Segue o oínte, non o enderezo. Se un balanceador de carga ou un proxy remata TLS, a conexión que mantén o teu cliente acaba alí, e o proxy abre unha segunda conexión ao backend que pode ser texto plano ou TLS cunha cadea de confianza distinta. Un enderezo IP privado e unha ruta coincidente non son proba sobre esa segunda conexión.

Proba o extremo que de verdade che importa desde dentro do VPC, co nome que usa a aplicación e non cun IP que resolveches unha vez:

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

Repíteo para cada salto polo que pasa a petición. Se a resposta difire entre o nome de cara ao cliente e o nome do backend, atopaches exactamente o segmento que a VPN nunca cubriu, e ese é o achado que hai que anotar.

Rexistra o resultado como segmentos, non como veredicto

A saída desta lista é unha táboa pequena cunha fila por segmento: pasarela de cliente a destino de VPN de AWS, pasarela a carga de traballo, carga de traballo a almacén de datos e calquera salto de proxy entre eles. Cada fila di que o protexe e de que depende esa protección. "Cifrado" sen mecanismo e sen extremo non é unha fila.

Despois responde ao requisito orixinal cos mesmos termos con que se formulou. Se o requisito é que os datos sigan sendo confidenciais ata que a carga de traballo os reciba, a VPN satisface só o primeiro segmento, e as filas restantes necesitan transporte de aplicación, TLS de servizo ou cifrado de almacenamento configurados e verificados por separado.

Conserva os identificadores de conexión, os estados dos túneles e os suxeitos dos certificados no rexistro. Cando alguén volva ao deseño dentro de seis meses, eses tres artefactos responden a pregunta do límite en minutos en lugar de reiniciar a discusión desde un diagrama.