Anúncios BGP do VGW versus a tabela de rotas da VPC: o que muda o quê

Um prefixo ausente na tabela de rotas de uma sub-rede da VPC e um prefixo ausente no roteador do cliente são duas falhas diferentes, e apenas uma delas é corrigida dentro das tabelas de rotas da AWS. O gateway privado virtual anuncia os blocos CIDR associados à sua VPC; a tabela de rotas da sub-rede decide para onde uma carga de trabalho envia a resposta. Tratar a segunda como uma forma de mudar a primeira é o erro mais comum neste diagnóstico. Execute as verificações abaixo em ordem e mantenha as duas direções separadas.

Nomeie o anexo antes de ler qualquer tabela

Uma VPN site-to-site termina num gateway privado virtual ou num gateway de trânsito, e os IDs de recursos decidem qual modelo de roteamento se aplica. Leia-os primeiro: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. A resposta diz se a próxima tabela a inspecionar é uma tabela de rotas de VPC ou uma tabela de rotas do gateway de trânsito.

Se a VPN estiver anexada a um gateway de trânsito, pare de tratar a tabela de rotas da VPC como o plano de controle. Ali a tabela da VPC aponta para o anexo do gateway, e a associação e a propagação acontecem na tabela de rotas do gateway de trânsito. Misturar as duas visões produz conclusões confiantes sobre o objeto errado.

A direção da AWS para o escritório é um anúncio

Para um anexo VGW, o gateway anuncia os blocos CIDR associados à sua VPC ao gateway do cliente via BGP. Adicionar uma rota de sub-rede individual, ou apontar uma rota para uma VPC emparelhada ou para um dispositivo, não adiciona outro CIDR associado e não aparece nesse anúncio. Se faltar um prefixo no escritório, compare a lista de rotas recebidas com as associações da VPC antes de editar qualquer tabela de rotas.

A regra simples tem exceções, então mantenha-a dentro do seu escopo. Uma configuração VPN CloudHub pode reanunciar prefixos de site entre gateways de cliente, e um gateway de trânsito segue as suas próprias regras de propagação. A afirmação de que um VGW anuncia apenas a sua própria VPC é um padrão útil, não uma lei que cubra todas as topologias que encontrar.

A direção do escritório para a AWS é propagação mais seleção

Na direção inversa, o VGW aprende o prefixo do escritório, mas isso sozinho não move uma carga de trabalho. A tabela de rotas da sub-rede deve ter a propagação habilitada para o anexo ou conter uma rota estática para o mesmo destino. Quando ambas existem para um prefixo, a rota estática vence, e a correspondência de prefixo mais longo é executada antes de qualquer uma delas.

Leia a origem em vez de presumi-la: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Uma entrada com origem EnableVgwRoutePropagation veio do BGP; uma entrada com origem CreateRoute foi digitada por uma pessoa e continuará vencendo até que alguém a exclua.

Um runbook que mantém as duas direções separadas

Registre quatro fatos no lado da AWS antes de mudar qualquer coisa: o tipo de anexo, os CIDR associados da VPC, a origem da rota de sub-rede para o prefixo em questão e o estado do túnel e do BGP. A mesma chamada describe retorna VgwTelemetry com uma contagem de rotas aceitas por túnel, o que indica se a AWS aceitou alguma rota. Depois compare com o que o dispositivo do cliente realmente instalou. Um prefixo presente no BGP mas ausente da tabela de encaminhamento é um problema de importação local ou de melhor caminho, não um problema da tabela de rotas da AWS.

Se a tabela da sub-rede não tiver o prefixo de todo, habilite a propagação ou adicione uma rota estática, e então releia a mesma consulta após o intervalo de propagação em vez de presumir que a mudança foi imediata. Se o prefixo existir e o tráfego ainda falhar, deixe o plano de controle em paz e passe para o caminho de dados.

O que não mudar enquanto estiver lá

Não ative nem desative a propagação em tabelas de rotas não relacionadas para corrigir um prefixo em falta, e não adicione uma rota predefinida para encobrir um único CIDR ausente. Ambas as mudanças ampliam o âmbito do impacto e dificultam o próximo diagnóstico. Limite a edição à tabela que serve a sub-rede de carga de trabalho em questão.

O caminho de dados é separado de tudo isto. Os grupos de segurança são stateful, as ACL de rede não, e uma firewall de host ou um caminho de retorno assimétrico podem descartar tráfego que o encaminhamento entregou corretamente. Um agregado anunciado também não autoriza cada serviço dentro dele, por isso restrinja o acesso na fronteira da política em vez de confiar em que um endereço apareça por acaso num anúncio BGP.

Guarde o antes e o depois de cada consulta à tabela de rotas no registo de alterações. Se a mudança piorar as coisas, restaure as rotas anteriores e confirme com a mesma consulta, porque uma reversão que não pode verificar é apenas um palpite.