Porque é que a sua sessão BGP não aparece na tabela de rotas da VPC

A história que se repete é que um daemon de encaminhamento num appliance VPN EC2 vai ensinar à VPC os seus prefixos remotos assim que o BGP subir. Metade disso é verdade. A sessão sobe, e nada muda na tabela de rotas da VPC por causa disso, e é por isso que o primeiro sintoma costuma ser uma sub-rede que manda o tráfego silenciosamente para um buraco negro.

Duas coisas diferentes estão a ser confundidas aqui: o peering com um servidor de rotas e a instalação de rotas numa tabela.

O mito: sobe o BGP e a VPC aprende os prefixos

O BGP é uma conversa entre dois interlocutores, e neste desenho os interlocutores são o daemon de encaminhamento no seu appliance e um endpoint do VPC Route Server que a AWS coloca numa sub-rede que lhe pertence. Essa conversa transporta prefixos. Não toca na tabela de rotas das suas sub-redes de carga, porque essas tabelas só aprendem através da propagação que tem de ser ativada em cada uma. Até isso acontecer, a malha da VPC não sabe nada sobre o que o appliance sabe.

Os passos de configuração estão separados por uma razão: associar, criar o endpoint, fazer peering e depois ativar a propagação.

O Route Server é um plano de controlo, não um túnel

O Route Server não cifra, não encaminha nem inspeciona um único pacote. Existe para trocar BGP com o appliance e entregar os prefixos resultantes às tabelas de rotas configuradas para os receber. O plano de dados não muda: os pacotes continuam a sair pela interface de rede do appliance, viajam pela sua VPN e voltam pelo mesmo caminho.

Isso significa que a verificação de origem e destino na instância de encaminhamento continua a importar, porque a instância agora encaminha tráfego endereçado a outra pessoa.

Os grupos de segurança e os controlos de sub-rede também se aplicam ao fluxo encaminhado. O Route Server não fará um appliance que descarta tráfego encaminhá-lo, nem reparará uma rota de retorno em falta do lado remoto.

A propagação é por tabela de rotas, não por VPC

Associar o servidor de rotas à VPC e ativar a propagação numa tabela de rotas são duas decisões, e só a segunda muda o que uma sub-rede faz. Uma VPC com seis tabelas de rotas pode receber um prefixo propagado numa e não nas outras cinco, o que é exatamente correto para uma sub-rede concentradora e exatamente o que produz o resultado desconcertante de «funciona a meio». Mesmo onde a propagação está ativa, uma rota concorrente pode ganhar, porque a seleção de rotas da VPC prefere o prefixo mais longo e, a igual comprimento, prefere uma rota estática a uma propagada. Essa preferência é aplicada em silêncio.

Verifique a tabela efetiva da sub-rede concreta em vez da lista de prefixos anunciados pelo appliance. A API responde a essa pergunta diretamente: aws ec2 associate-route-server e aws ec2 enable-route-server-propagation --route-table-id <id> são os dois passos de que as pessoas se esquecem, e aws ec2 describe-route-tables --route-table-ids <id> mostra se o prefixo chegou como entrada de route server.

O appliance continua a transportar cada pacote

Anunciar alcançabilidade não é o mesmo que tê-la. Uma sessão BGP pode permanecer estabelecida enquanto a VPN do appliance está em baixo, e um anúncio estático que nunca muda continua a puxar o tráfego para um caminho morto. O Route Server suporta deteção de falhas como BFD, mas isso testa a vitalidade do par, não a saúde de tudo o que está por trás.

Ligue o anúncio à rota remota real: anuncie o prefixo quando o túnel e a rede remota estão ativos, e retire-o quando não estão.

Retire um prefixo e veja o que acontece

Teste por etapas, e faça da última etapa uma remoção. Confirme que o anúncio chega, que o prefixo aparece em cada tabela prevista, que o appliance é o próximo salto, que o encaminhamento atravessa o túnel ativo e que o extremo remoto responde. Depois retire um prefixo de teste, ou feche um túnel aprovado, e observe se o tráfego se move para onde o desenho diz. Registe as tabelas antes e depois enquanto o teste ainda está aberto.

Mover uma rota para um segundo appliance não move as sessões que ela transportava, porque o estado de NAT e de firewall fica no primeiro equipamento.

Para um conjunto fixo de uma dúzia de prefixos, as rotas estáticas nas tabelas da VPC continuam a ser a resposta mais barata. O Route Server ganha o seu lugar quando a lista de prefixos muda de facto e a política de retirada é algo que consegue explicar à pessoa de serviço.