Adicionar uma sub-rede local a uma VPN da AWS: VGW vs Transit Gateway

Uma VPN Site-to-Site existente transporta 10.60.0.0/16, uma nova rede de serviço aparece atrás do mesmo gateway local como 10.70.0.0/16, e alguém pergunta se é necessário um proxy. Normalmente não: um caminho roteado pode transportar o prefixo, mas apenas se três coisas se alinharem, e quais três depende da arquitetura da AWS que você já opera. Um gateway privado virtual tem um limite de tabela de rotas; um transit gateway adiciona um segundo. O anúncio correto com a tabela errada produz uma sessão que parece saudável e não entrega nada.

Publique um prefixo que o gateway realmente consiga entregar

O gateway local precisa de uma rota adiante para a nova rede antes que qualquer anúncio faça sentido. Anunciar 10.70.0.0/16 via BGP diz à AWS para onde enviar os pacotes daquele intervalo; isso não cria o caminho de encaminhamento local que torna o intervalo alcançável no outro extremo. Confirme que o gateway tem uma rota para o prefixo apontando para o dispositivo que o mantém, e que o dispositivo está configurado para responder por esses endereços. A política de exportação e os limites de prefixo aceitos são a próxima restrição, porque um prefixo que a sessão filtra nunca chega à AWS.

Mantenha agregados e rotas mais específicas deliberados. Caminhos sobrepostos que chegam de duas direções são uma decisão de projeto, não um detalhe descoberto depois.

Caminho um: o limite do gateway privado virtual

Com um gateway privado virtual, a documentação de roteamento da AWS VPN descreve dois modos de distribuição, rotas estáticas e anúncios BGP, e ambos dependem da tabela de rotas da sub-rede que a aplicação realmente usa. A propagação é conveniente quando você controla todo o intervalo, e uma rota explícita é mais fácil de raciocinar quando você quer o destino listado ao lado do alvo. Em qualquer caso, a verificação é a mesma: a tabela da sub-rede específica da aplicação contém um caminho funcional até o alvo da VPN para o novo prefixo, e ele vence contra algo mais específico?

Uma sessão BGP saudável prova que o canal existe. Não diz nada sobre se uma determinada tabela de sub-rede consumiu a rota.

Caminho dois: o transit gateway adiciona uma tabela

Um transit gateway divide essa única pergunta em duas. A sub-rede da VPC precisa enviar o destino ao anexo do transit gateway, e então a tabela de rotas do transit gateway precisa selecionar o anexo da VPN para o mesmo prefixo. As escolhas de associação e propagação determinam quais redes anexadas recebem a rota, então um prefixo pode ser anunciado corretamente pela VPN e ainda assim nunca chegar à VPC cuja tabela nunca foi associada à tabela de rotas correta.

A falha comum é uma rota que existe em uma tabela e não na outra, com cada equipe convencida de que seu lado está correto. Quando você compara as duas arquiteturas, esse limite extra é toda a diferença: mais lugares para olhar e um controle mais preciso sobre quem recebe a rota.

A propagação de rotas também não concede o prefixo a cada anexo. Ela o distribui para as tabelas configuradas para recebê-lo.

O caminho de retorno é uma decisão de política própria

O tráfego que chega é apenas metade da troca. A nova rede local precisa de uma rota de volta aos prefixos de origem da AWS pelo gateway correto, e a política de segurança nas duas pontas precisa permitir esse par de origem e destino. Se o túnel negociar um escopo de proteção com seletores de tráfego, o novo prefixo precisa estar dentro dele, ou o pacote é descartado antes de qualquer tabela de rotas ser consultada.

A sobreposição de endereços é a outra armadilha. Intervalos disjuntos e com propriedade explícita mantêm isso simples; intervalos sobrepostos significam tradução ou um redesenho, e nenhum dos dois é uma variante intercambiável da mesma receita.

Teste com uma origem na nova rede e um destino na sub-rede da aplicação, e repita na outra direção. Um teste unidirecional prova apenas uma direção.

Quando o proxy é de fato o melhor limite

Um proxy conquista seu lugar quando o requisito é uma interface de serviço estreita, quando a aplicação já espera essa arquitetura ou quando não se consegue fazer o caminho de rede transportar o prefixo sem uma tradução que você não quer. Ele não é a solução de reserva para uma entrada de tabela de rotas que ninguém verificou.

Decida nesta ordem: encaminhamento local, anúncio, limite da tabela, política de retorno. Corrija o primeiro que falhar e só então pergunte se o caminho roteado é mesmo a resposta correta.