Rotas estáticas ou um protocolo de roteamento sobre uma VPN site a site?

As duas opções transportam pacotes entre sites, então a decisão não é sobre qual protocolo é mais novo, e o tamanho do túnel também não a resolve. Resolvem-na três condições: quantos prefixos mudam e com que frequência, se o projeto precisa de failover automático entre caminhos, e quanta maquinaria de plano de controle a equipe consegue operar às três da manhã. Responda com honestidade e a escolha costuma se fazer sozinha. O resto deste texto é o que custa cada resposta.

Três condições a decidem

A primeira condição é a volatilidade. Um punhado de sub-redes estáveis com propriedade clara pode ser mantido à mão por anos, e cada rota continua sendo uma linha que alguém pode ler e conferir. Dezenas de prefixos que se movem conforme os projetos chegam e vão são outro problema, porque cada movimento precisa alcançar cada dispositivo que ainda lembra o caminho antigo.

A segunda é o comportamento em falha. Quando um caminho de reserva precisa ficar ativo sem que um humano perceba, algo tem de detectar a falha e retirar a rota. O roteamento estático só consegue isso por rastreamento ou instalação condicional, e apenas para as falhas que você previu.

A terceira é o apetite por um segundo plano de controle. Um protocolo de roteamento acrescenta sessões, autenticação, filtros e política de seleção, e cada um disso exige monitoramento e um processo de mudança. É um custo operacional permanente, não uma tarefa de configuração única.

A tabela abaixo do terceiro parágrafo é a versão curta, e as três seções seguintes explicam por que cada linha está onde está. Leia as linhas contra a sua própria contagem de sites antes de escolher, porque uma decisão que ignora o custo operacional é só meia decisão.

O que o roteamento estático realmente custa

Uma rota estática tem de estar correta dos dois lados do túnel. Acrescentar uma sub-rede significa editar o gateway remoto, o gateway local e geralmente o caminho de volta, e esquecer qualquer um deles produz uma falha unidirecional que parece um bug da aplicação. A equipe de aplicação vê timeouts enquanto a de rede vê uma rota que existe e aparentemente está saudável. Nenhuma das equipes está errada, e é por isso que essa falha demora tanto a ser localizada.

Uma entrada estática também continua instalada depois que o caminho abaixo dela desaparece. A menos que a plataforma ofereça rastreamento, a rota segue apontando para um próximo salto que não encaminha mais, e o tráfego desaparece em vez de comutar. Esse silêncio é a despesa que você aceita ao escolher a opção simples.

Escreva o método de rastreamento ao lado de cada rota, anote quais falhas ele cobre e mantenha a lista junto com a configuração do túnel. Caso contrário, a próxima interrupção é descoberta por um usuário e não pela rede, o que é sempre a descoberta mais cara.

O que o roteamento dinâmico realmente custa

Um protocolo anuncia prefixos novos, retira os inalcançáveis e expressa preferência entre caminhos. Isso é genuinamente útil quando vários sites ou túneis redundantes exigiriam, de outro modo, edições coordenadas a cada mudança. Também é o motivo pelo qual o protocolo pode surpreendê-lo no pior momento. Cada uma dessas ações é uma mudança de estado que você não fez pessoalmente.

Ele cria dois estados que podem discordar. O túnel pode estar no ar enquanto a sessão de roteamento está caída, e a sessão pode estar no ar enquanto os anúncios dela omitem a sub-rede de que a aplicação precisa. Os dois parecem uma rede funcionando pela metade, e nenhum é visível numa página de status do túnel.

Filtros e política tornam-se, portanto, parte do projeto em vez de um pensamento posterior. Um protocolo que anuncia tudo vai acabar anunciando algo errado, e o prefixo errado viaja mais rápido do que a pessoa capaz de corrigi-lo. Escreva os filtros antes de a primeira sessão ser habilitada, para que o primeiro anúncio já seja deliberado.

Controle o que a sessão de roteamento pode dizer

Defina a lista de prefixos permitidos por par e aplique-a na entrada, porque um filtro de saída não consegue impedir um par de enviar uma rota default para você. Rotas default e agregados são os erros caros aqui: podem substituir em silêncio caminhos não relacionados por uma única entrada aprendida que parece legítima. Rejeite-os explicitamente, a menos que o projeto realmente os queira.

Escreva o site proprietário ao lado de cada rede antes de a primeira sessão subir, porque esse mapeamento é a fonte da lista de filtros e não um enfeite de documentação. Sem ele, quem edita um filtro tem de adivinhar qual site deveria anunciar o prefixo.

A redistribuição entre dois protocolos é onde os laços começam e onde o mesmo prefixo chega duas vezes com atributos que não se comparam de forma limpa. Mantenha a redistribuição fora do projeto até que um requisito específico a imponha, e se ela tiver de existir, marque e filtre as rotas na fronteira.

Interfaces de túnel baseadas em rotas tornam o roteamento dinâmico mais fácil de representar, porque o túnel passa a ser uma interface com rotas em vez de uma política que casa seletores. Isso não elimina a questão do escopo do par: os seletores IPsec ainda têm de permitir o tráfego que você pretende rotear.

Teste o caminho de falha, não o caminho feliz

Escolha o que escolher, derrube um uplink e confirme que o tráfego se move, ou que falha do modo como você documentou. Um projeto testado apenas com os dois caminhos saudáveis é um projeto que não foi testado de forma alguma. Meça a detecção enquanto estiver ali, porque o número que você mediu é o número que os usuários vão viver.

Depois confirme o caminho de volta de forma independente, porque o roteamento assimétrico sobre uma VPN é comum e invisível até um dispositivo com estado descartar as respostas. Um fluxo que funciona num sentido prova apenas metade do caminho.

Ordem de trabalho: conte os prefixos, decida como as falhas devem ser detectadas, verifique quem consegue operar o protocolo, controle o que é anunciado e então teste uma interrupção de ponta a ponta. Cada passo produz um fato de que o seguinte precisa.