Por que o BGP sobre uma VPN não controla o caminho da camada inferior

Dois sites emparelham BGP por um túnel IPsec, aprendem os prefixos um do outro, e o diagrama é renomeado como controle de caminho. É esse rótulo que inicia a confusão. A sessão troca alcançabilidade e aplica política, mas não tem voz sobre qual provedor, cabo ou roteador transporta os pacotes cifrados. Já vi uma equipe reconstruir um túnel que funcionava porque esperava que uma mudança de rota BGP movesse o tráfego para outro caminho de fibra que a sessão nunca poderia influenciar.

O que as pessoas supõem que uma sessão compra

A maior parte da expectativa vem de como uma mudança de rota parece em laboratório. Você anuncia um prefixo pelo túnel, o lado remoto o instala, e o tráfego se move. A mesma sequência acontece em um roteador que realmente tem controles de engenharia de tráfego, então os dois se confundem. No laboratório os dois sites costumam compartilhar um único link de acesso, e é exatamente por isso que a diferença nunca aparece lá.

BGP é um protocolo de alcançabilidade. Ele diz a um par que você pode entregar pacotes para um prefixo e permite que cada lado ordene as ofertas que recebe. Isso é genuinamente útil por um túnel: os prefixos aparecem e desaparecem conforme os sites chegam e saem, e você pode recusar uma faixa sem escrever uma rota estática em cada dispositivo de borda. O que ele não faz é colocar os roteadores de um provedor sob o seu controle.

A camada inferior transporta o cabeçalho externo. O seu ponto final do túnel envia pacotes cifrados para um endereço de par, e a rede entre esses dois endereços os encaminha com as rotas que os operadores dela instalaram. Nada na sessão BGP muda essa decisão, a menos que o mesmo provedor exponha um serviço suportado que o faça.

O que a sessão realmente transporta

O falante BGP abre uma conexão TCP para a porta 179 do seu par, usando os formatos de mensagem e os atributos de caminho definidos na RFC 4271. Quando o endereço do par vive dentro do túnel, o túnel precisa estar ativo e esse endereço alcançável antes de a sessão sequer começar. Uma troca IKE concluída não é um vizinho BGP. Implementações de IPsec baseadas em rotas só deixam passar tráfego quando existe uma rota de túnel correspondente, e a baseada em política precisa do endereço do par dentro do seletor protegido. Inverter isso produz o estado clássico em que o túnel está verde e a sessão fica ociosa.

Depois que a sessão sobe, a política decide o que a atravessa. Listas de prefixos, filtros de AS-path, um teto de prefixos máximo e uma decisão explícita sobre rotas padrão são o mínimo, e valem nos dois sentidos. Um par que aceita tudo o que recebe pode entregar uma rota padrão que substitui silenciosamente o acesso local à internet. Os dois sentidos precisam de listas separadas, porque o que você aceita de um par e o que anuncia a ele são decisões diferentes.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

Depois morde a MTU. A encapsulação reduz a carga útil, então uma atualização grande pode travar uma sessão que parece perfeitamente estabelecida: o par continua ativo, os prefixos nunca chegam e nada óbvio cai no log. Limite o MSS de TCP na interface do túnel, ou defina uma MTU de túnel com espaço para a sobrecarga, antes de culpar os filtros.

Para onde os pacotes externos ainda vão

Pacotes cifrados de um site ao outro saem pelo que o roteador local seleciona para o endereço público do par. Se os dois sites compram trânsito do mesmo provedor, atravessam a mesma instalação metropolitana, ou um lado fica atrás de NAT de nível de operadora, o túnel sobrevive a uma falha do provedor só por acidente. Contar ícones de túnel numa ferramenta de monitorização não diz nada sobre isso.

Seleção de rota e instalação do encaminhamento também são eventos separados. Um prefixo pode estar na tabela BGP como o melhor e ainda faltar na tabela de encaminhamento, porque o próximo salto não é resolvível ou uma rota mais específica vence. Quando alguém relata que o BGP aprendeu o prefixo mas o tráfego não flui, a pergunta útil é se ele está instalado e para qual próximo salto aponta.

A resposta honesta para uma revisão de projeto é uma lista de dependências compartilhadas: circuito de acesso, provedor a montante, instalação e qualquer dispositivo com estado no caminho de volta. Uma sessão pelo túnel não pode remover uma dependência sobre a qual não se assenta.

Três decisões que vale a pena separar

Quando um projeto mistura essas coisas, toda conversa sobre falha dá voltas. Separe-as primeiro no papel e depois mapeie cada uma para o dispositivo que realmente a aplica.

Cada linha tem um dono diferente. A primeira é uma negociação, a segunda é configuração nos seus dispositivos, a terceira é sobretudo a rede de outra pessoa. Um pedido de mudança que nomeia a linha que toca é muito mais fácil de aprovar do que um que diz problema de BGP.

Modos de falha para os quais vale a pena planear

Aceitar a rota resumida de um par é a ferida autoinfligida mais comum. Alguém anuncia um agregado curto para simplificar a troca, o lado remoto aceita, e o tráfego para faixas que não estão atrás do túnel segue o túnel e morre. Filtre pelos prefixos exatamente esperados, ou use uma lista de prefixos com os limites corretos, e nunca aceite um agregado nu porque faz a sessão parecer arrumada.

O momento da retirada é o segundo. A deteção depende dos temporizadores de manutenção, de BFD se o ativou, da deteção de par morto do túnel e da rapidez com que o lado remoto deixa de anunciar. As sessões existentes são um problema à parte: uma rota nova pode restaurar novas ligações enquanto as sessões TCP estabelecidas continuam a usar endereços desatualizados, e firewalls com estado ou NAT no caminho podem manter entradas que já não correspondem. Coloque a recuperação da aplicação nos critérios de aceitação em vez de assumir que uma mudança de rota resolve tudo.

A terceira é a assimetria do caminho de volta. O tráfego pode chegar pelo túnel e voltar por um link do provedor que nunca foi pensado para o transportar, o que se manifesta como áudio unidirecional, handshakes falhados ou uma firewall que descarta as respostas. Verifique os dois sentidos separadamente.

O que escrever no contrato, e como verificá-lo

Peça por escrito os prefixos permitidos: quem está autorizado a originar cada faixa, se uma rota padrão é permitida e que famílias de endereços o serviço de túnel suporta. A RFC 8212 tornou a política explícita de importação e exportação a expectativa para o eBGP nas implementações que a seguem, por isso um par que ainda depende de aceitar tudo implicitamente merece uma pergunta.

Depois verifique a partir do dispositivo e não do diagrama. Comandos úteis em roteadores ao estilo FRR:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Acrescente duas observações que a tabela de rotas não consegue dar. Capture na interface externa para confirmar que endereço os pacotes encapsulados realmente visam, por exemplo tcpdump -ni eth0 udp port 51820 para um túnel WireGuard, ou um filtro ESP para IPsec. Depois trace em direção ao endereço público do par e compare os saltos com um trace dentro do túnel; se ambos seguirem a mesma cadeia de provedor, a sua redundância vive na política de rotas e não na rede.

Por fim, teste uma retirada de propósito. Baixe o túnel durante uma janela de manutenção, registe quanto tempo o prefixo permanece instalado, o que acontece às sessões existentes e se o lado remoto recua para uma rota que aceitaria mesmo. Esse exercício diz mais sobre o projeto do que qualquer diagrama.

Uma rota não é uma autorização. Os prefixos que combina trocar não dizem nada sobre que utilizadores podem alcançar que serviço atrás do túnel, por isso mantenha a autenticação, os serviços permitidos e as firewalls dos anfitriões exatamente onde estavam. Um par alcançável também não é permissão para trânsito ilimitado nem para originar endereços arbitrários, e esse tipo de autoridade pertence ao contrato como questão comercial, não a uma linha de política BGP.

• Nomeie os prefixos que cada lado pode originar, e os que nunca deve aceitar.
• Limite o MSS no túnel e confirme que as atualizações grandes chegam mesmo.
• Liste as dependências compartilhadas da camada inferior, não o número de túneis.
• Cronometre uma retirada real e registe o que a aplicação faz.