Uma VPN na nuvem precisa de BGP: por que os outros protocolos de roteamento falham

A associação de segurança IPsec está ativa, os contadores do túnel se movem e o tráfego para o prefixo da nuvem desaparece. O operador então tenta habilitar OSPF no roteador do cliente, esperando que o vizinho se forme, e nada acontece. O túnel nunca foi a peça que faltava: uma VPN na nuvem gerenciada expõe um contrato de roteamento definido, e nas grandes plataformas esse contrato é BGP. Até que exista uma sessão e um prefixo seja aceito, o túnel é apenas um caminho criptografado sem destinos atrás de si.

O túnel está ativo e a rota está ausente

Concluir a fase 1 e a fase 2 prova que os pares concordam sobre a proteção, não que qualquer lado saiba para onde enviar o tráfego. São máquinas de estado separadas com modos de falha separados.

Faça três perguntas em ordem: o prefixo foi anunciado, foi aceito pelo par e foi instalado para encaminhamento? Um prefixo anunciado e filtrado é um problema de política. Um prefixo que nunca foi anunciado é um problema de sessão ou de configuração. Um prefixo aceito mas não instalado é um problema de seleção de rota, e cada resposta aponta para uma parte diferente da configuração.

O que o provedor realmente entrega

Um gateway VPN gerenciado não é um roteador sem restrições. O provedor entrega um gateway com endereços de par suportados, uma configuração de sistema autônomo, limites de prefixo e um comportamento de falha definido. Essa superfície é o produto.

O Google Cloud documenta o roteamento dinâmico BGP para HA VPN, com o Cloud Router aprendendo rotas dos pares e fornecendo rotas dinâmicas personalizadas elegíveis à VPC. O AWS Site-to-Site VPN documenta uma escolha entre roteamento estático e dinâmico, e descreve as verificações de vitalidade do BGP como úteis para o failover do túnel, enquanto também oferece suporte a verificações de integridade para dispositivos sem BGP. O comportamento de uma plataforma não deve ser inferido a partir do nome do produto da outra.

A consequência prática é que se escolhe primeiro o modo gerenciado e depois se leem os parâmetros suportados. Um projeto que pressupõe um tipo de adjacência que o serviço não oferece não é um problema de configuração a resolver no roteador do cliente.

A proteção do túnel e a alcançabilidade são tarefas separadas

O IPsec protege o tráfego selecionado para o túnel. O BGP fornece as informações de alcançabilidade que tornam um prefixo elegível. Um túnel funcional não prova que o prefixo esperado foi anunciado, aceito ou instalado.

Imagine uma filial que anuncia 10.42.0.0/16 por dois caminhos de túnel elegíveis. Remova um caminho utilizável e a escolha de rota pode mudar sem que ninguém edite a rota de cada carga de trabalho. Detecção, seleção de rota e recuperação da aplicação não são instantâneas e não são idênticas entre implantações, então o teste de failover deve observar toda a sequência e não o primeiro pacote que passa.

Quando um prefixo da nuvem está inalcançável, verifique o estado da sessão e as rotas aprendidas antes de tocar na criptografia. Uma SA ativa sem rota por trás é a forma mais comum deste sintoma.

Onde as suposições sobre OSPF quebram

OSPF, IS-IS ou outro protocolo dentro de um túnel IPsec é perfeitamente possível num appliance autogerenciado, onde você possui as duas pontas e o projeto de encaminhamento. Esse fato não diz nada sobre um serviço gerenciado que só oferece BGP como modo de roteamento dinâmico.

Se um projeto proposto precisa de uma adjacência que o serviço não suporta, mude a arquitetura de forma deliberada. As opções incluem um appliance autogerenciado na VPC, roteamento estático onde o serviço o suporta, ou um produto de conectividade diferente. Configurar o protocolo apenas no roteador do cliente não pode adicionar um par do lado da nuvem que não existe, e não fará o prefixo aparecer.

Não transporte a resposta de um fornecedor para o gateway de outro. As mesmas palavras, como roteamento dinâmico ou failover do túnel, podem descrever mecanismos e limites diferentes.

Leia o requisito do serviço e depois projete

Antes da primeira linha de configuração, anote os endereços dos vizinhos, os números de sistema autônomo, os prefixos que você anunciará e aceitará, os limites de rotas e o comportamento esperado quando um túnel falhar. Esses cinco itens são o contrato contra o qual você projeta.

Depois verifique na mesma ordem: sessão estabelecida, prefixo recebido, rota presente na tabela de rotas da VPC e um fluxo real para um endereço de serviço. Repita após um failover forçado, porque uma sessão que se restabelece pode voltar com um conjunto de rotas diferente. Se o projeto depende de convergência abaixo de um segundo, meça-a em vez de presumi-la.

Mantenha o contrato do serviço junto do registro de mudanças. Quando alguém perguntar mais tarde por que o túnel não pode executar OSPF, a resposta é uma fronteira de produto, não uma limitação do protocolo, e o registro deve dizer isso.