VGW ou TGW? Onde termina o túnel IPsec do AWS Site-to-Site

As pessoas perguntam onde uma VPN Site-to-Site da AWS deixa de proteger o pacote e esperam uma única resposta: no gateway. A versão útil dessa resposta diz qual gateway, porque um gateway privado virtual e um gateway de trânsito são disposições diferentes com objetos de anexo diferentes, e o revisor que assume a errada constrói o resto da avaliação sobre um diagrama que não existe. Faça as três verificações abaixo em ordem. Cada uma ou confirma o limite ou diz que a resposta anterior era sobre outro recurso.

Nomeie os três pontos finais antes de avaliar qualquer coisa

Uma revisão da cifragem deste caminho precisa de três coisas nomeadas: o gateway do cliente, o destino VPN da AWS que termina o IPsec e o ponto final da aplicação que recebe o pacote interno. Anote-os com os seus identificadores de recurso antes de abrir uma única página da consola, porque tudo o que vem a seguir é uma afirmação sobre um desses três.

O gateway do cliente é seu e a sua configuração é visível para si. O destino da AWS é um recurso gerido, e o erro é assumi-lo: uma ligação VPN pode anexar-se a um gateway privado virtual ou diretamente a um gateway de trânsito, e nenhum implica o outro. O terceiro ponto final é o que as pessoas saltam, e é o único que responde à pergunta real sobre os dados da aplicação.

Verificação 1: qual gateway termina realmente o túnel

Ambas as disposições são suportadas e o guia de arquitetura do Site-to-Site VPN descreve-as lado a lado, por isso pergunte à API em vez de a um diagrama que muitas vezes tem um ano. Uma consulta só de leitura sobre uma ligação devolve os campos de destino 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, não VpnGatewayId. Uma ligação com TransitGatewayId vazio termina num gateway privado virtual autónomo, enquanto uma ligação com esse campo definido termina num anexo VPN do gateway de trânsito, e VpnGatewayId pode continuar preenchido nesse caso porque pode nomear o gateway de suporte do anexo. Leia primeiro o campo TGW e depois confirme o tipo de anexo na lista de anexos, não a partir do nome de um campo, porque um anexo de VPC nesse gateway de trânsito não é o anexo VPN. Encontrar a instância de destino numa VPC ligada não lhe diz nada sobre qual anexo VPN transportou o pacote.

Enquanto estiver aí, verifique os túneis. A ligação transporta dois túneis IPsec para redundância, e uma ligação cujo segundo túnel nunca subiu é um achado real para a disponibilidade, ainda que não mude nada no limite da cifragem:

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}'

Verificação 2: o que o pacote interno ainda transporta

Quando o IPsec termina, a AWS encaminha o pacote desencapsulado pela rota que lhe correspondia. A partir daí o tráfego é tráfego de VPC comum, e a proteção da VPN terminou. Isso não é uma falha do serviço; é o que o limite significa, e o ponto da lista é dizê-lo com clareza em vez de deixar "a VPN está cifrada" substituir "os dados estão cifrados de ponta a ponta".

Agora examine o que estava lá dentro. Se o pacote interno for um protocolo de aplicação em texto simples, nada a jusante acrescenta confidencialidade até que outra coisa o cifre. Se o pacote interno já transportar uma sessão TLS, a remoção do IPsec exterior não muda nada para essa sessão: continua protegida até ao seu próprio ponto final, onde quer que esse ponto final esteja.

A sobrecorreção habitual é concluir que tudo atrás do gateway está exposto. Não está. O transporte do serviço, a cifragem do armazenamento e o TLS da aplicação são mecanismos separados com condições separadas, e cada um tem de ser avaliado nos seus próprios termos em vez de inferido da forma da VPN. Um registo de fluxo que mostra ACCEPT prova que o encaminhamento funcionou e não diz nada sobre confidencialidade, que é exatamente o erro que esta lista existe para evitar.

Verificação 3: o que termina o TLS atrás do gateway

Siga o ouvinte, não o endereço. Se um balanceador de carga ou um proxy terminar o TLS, a ligação que o seu cliente mantém acaba ali, e o proxy abre uma segunda ligação ao backend que pode ser texto simples ou TLS com outra cadeia de confiança. Um endereço IP privado e uma rota correspondente não são prova sobre essa segunda ligação.

Teste o ponto final que realmente lhe importa a partir de dentro da VPC, com o nome que a aplicação usa e não com um IP que resolveu uma vez:

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

Repita isso para cada salto por onde passa o pedido. Se a resposta diferir entre o nome virado para o cliente e o nome do backend, encontrou exatamente o segmento que a VPN nunca cobriu, e é esse o achado a registar.

Registe o resultado como segmentos, não como veredicto

A saída desta lista é uma tabela pequena com uma linha por segmento: gateway do cliente até ao destino VPN da AWS, gateway até à carga de trabalho, carga de trabalho até ao armazenamento de dados e qualquer salto de proxy pelo meio. Cada linha diz o que a protege e de que depende essa proteção. "Cifrado" sem mecanismo e sem ponto final não é uma linha.

Depois responda ao requisito original nos mesmos termos em que foi colocado. Se o requisito for que os dados permaneçam confidenciais até a carga de trabalho os receber, a VPN satisfaz apenas o primeiro segmento, e as linhas restantes precisam de transporte de aplicação, TLS de serviço ou cifragem de armazenamento configurados e verificados em separado.

Guarde os identificadores de ligação, os estados dos túneis e os sujeitos dos certificados no registo. Quando alguém voltar ao desenho dentro de seis meses, esses três artefactos respondem à pergunta do limite em minutos em vez de reiniciar a discussão a partir de um diagrama.