Estrela ou malha completa: qual topologia de VPN serve aos seus sites
Dois túneis funcionando não são uma topologia. Antes de escolher um hub, uma malha ou um hub com alguns links diretos, compare trânsito, comportamento em falha e custo de mudança.
Dois escritórios de filial conversam o dia inteiro, e o túnel entre eles desvia por um datacenter em outra região. Toda requisição paga duas vezes por esse desvio, e ninguém percebe até a sincronização de arquivos começar a parecer errada. É aí que a pergunta de topologia realmente começa: não em qual diagrama parece mais resiliente, mas em qual padrão de tráfego você está pagando. Os dois desenhos funcionam, e falham de maneiras diferentes, com custos diferentes.
Conte as relações entre pares antes de qualquer coisa
Com N sites, uma malha completa precisa de N vezes N menos um, dividido por dois, túneis; um hub precisa de N. Em cinco sites isso é dez contra cinco, o que ainda parece administrável. Em quinze é 105 contra quinze, e a diferença já não é aritmética, e sim de pessoal.
Cada uma dessas relações carrega estado que você precisa manter. No IPsec isso significa uma associação de segurança, uma identidade, uma chave ou certificado, detecção de peer morto e pelo menos uma rota por prefixo remoto. No WireGuard significa uma chave pública e um bloco AllowedIPs por peer; mais barato por peer, mas sem descoberta nenhuma: um site novo é mudança de configuração em todos os existentes de qualquer forma.
Deixe a mistura de tráfego decidir, não o desenho
Se o tráfego das filiais é principalmente requisições a um ERP central ou a um cluster de arquivos, um hub não é concessão, é a forma correta: o tráfego já queria ir para lá, e um ponto de política é mais fácil de auditar do que uma malha de regras par a par. A malha justifica a complexidade quando as filiais trocam dados entre si: replicação entre dois escritórios, voz entre sites, um compartilhamento CAD que uma dúzia de engenheiros abre o dia inteiro.
Os casos incômodos ficam no meio, e são a maioria. Meça antes de discutir, em vez de adivinhar a partir de um organograma.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
Leia a tabela como desempate, não como regra. Três de quatro linhas apontando para um lado costuma resolver o desenho, e um empate significa híbrido, que é o que a maioria das redes maduras acaba operando.
É preciso dizer ao hub que ele deve encaminhar
Dois túneis spoke-hub funcionando não criam acesso entre spokes. O hub precisa de encaminhamento IP habilitado, uma rota para cada rede de spoke, uma regra de firewall que permita o trânsito e o caminho de volta resolvido; cada spoke precisa de rota para os prefixos do outro site. Num hub Linux isso é net.ipv4.ip_forward=1 mais uma cadeia FORWARD que não descarta o par em silêncio, e no IPsec baseado em políticas são seletores de tráfego listando a sub-rede do spoke remoto nas duas pontas. strongSwan notas de encaminhamento cobrem o lado do kernel e do firewall quando é essa a camada que falta. Um teste barato é enviar tráfego de um spoke para um serviço no outro enquanto observa os contadores do hub; uma regra que nunca incrementa significa que a ordem está errada, não a rota.
A política central também é a parte útil. As filiais podem ser autorizadas a alcançar serviços compartilhados sem alcançar umas às outras, e vale escrever essa matriz de acesso explicitamente. Rotas ausentes são um substituto ruim para uma regra que alguém pode ler.
Cuidado com a versão pela metade: o spoke A roteia para o spoke B pelo hub, o hub roteia nos dois sentidos, e o firewall do hub permite conexões novas de A mas não de B. A primeira direção testa bem e a segunda trava, o que parece falha de roteamento e não é.
Projete a falha, depois o caminho normal
Um hub único é dependência compartilhada e gargalo de trânsito, e redundância é onde projetos de hub costumam errar. Dois hubs significam que cada spoke mantém dois túneis, e o caminho de volta precisa concordar com o de ida; quando não concorda, um firewall com estado descarta as respostas e o sintoma é uma conexão que abre e depois morre. Implantações maiores resolvem isso com um protocolo de roteamento sobre os túneis em vez de prefixos estáticos, o que é mais maquinário, mas elimina o chute. Escolha o que escolher, escreva o caminho de volta ao lado do de ida, porque a metade de volta é a que ninguém testa.
Uma malha espalha esse risco: o link de um site cair não isola os outros. Ela também multiplica os lugares em que a seleção de caminho pode surpreender, e sessões de aplicação ainda não sobrevivem a uma troca de caminho sem ajuda.
Nenhum dos desenhos mantém uma sessão TCP viva durante um failover por conta própria. Se a aplicação não consegue reconectar, topologia não é o seu problema.
Escolha pelo custo de mudança e depois verifique as rotas
Comece pelo hub, porque é a coisa mais barata de errar, e adicione túneis diretos para os pares cujo tráfego justifica. Esse híbrido não é falha em decidir; é o desenho em que a maioria das organizações converge dentro de um ano. O que importa é que cada link direto tenha um motivo declarado e um responsável.
Depois verifique os dois desenhos, e não um. Para o caminho normal, rode traceroute de cada site para cada prefixo de serviço e confirme que os saltos batem com o diagrama. Para o caminho de falha, derrube um túnel e repita, porque uma rota que só funciona com tudo no ar não foi projetada, apenas configurada.
Guarde os dois desenhos com a matriz de acesso e revise-os quando um site for adicionado; o custo que você administra é o da próxima mudança, não a elegância da imagem atual.