Planeje os intervalos privados de endereços VPN antes de os sites colidirem

Dois sites que usam ambos 192.168.1.0/24 podem cada um alcançar a internet e ainda assim não se alcançarem. O gateway não acusa erro; instala uma única rota para esse prefixo e envia cada pacote ao peer que o reivindicou primeiro. Nada no handshake, na lista de cifras ou na métrica da interface diz qual peer está errado. O planejamento de endereços é a parte do projeto que resolve isso antes de alguém se conectar.

Inventarie cada espaço que precisa ser alcançável

Anote os intervalos que precisam ser roteados, não apenas os que você está configurando. Isso inclui as LANs dos sites, pools de clientes VPN, sub-redes na nuvem, redes de gestão e fora de banda, segmentos de laboratório e as redes de onde os usuários costumam se conectar em casa. Um roteador doméstico fornecido como 192.168.1.0/24 não é hipotético, e o mesmo prefixo aparece em hotéis e centros de conferência. O inventário é uma tabela de prefixo, proprietário e finalidade, e é o único artefato que impede o mesmo intervalo de ser distribuído duas vezes.

Acrescente os prefixos que você espera no próximo ano, porque um plano que cobre só hoje falha no primeiro site novo. Marque cada linha com quem pode alterá-la, não apenas com quem a possui.

É o reúso que torna isso difícil: o espaço privado é finito e cada organização considera 10.0.0.0/8 como seu. Um plano não pode prometer que nenhuma LAN de convidados futura caia em um dos seus prefixos, então o projeto precisa dizer o que acontece quando cair. Duas regras fazem a maior parte do trabalho. Coloque os pools de clientes em um bloco contíguo que você consiga resumir, e nunca aloque um intervalo que outra equipe já roteia. Todo o resto é um registro que alguém mantém atualizado.

Por que uma sobreposição derrota a tabela de roteamento

Uma rota é um prefixo mais um próximo salto, e o encaminhamento escolhe o prefixo coincidente mais longo. Quando dois peers reivindicam ambos 192.168.1.0/24, a tabela mantém uma única entrada para ele, então o tráfego dos dois sites sai pelo mesmo túnel. O segundo site não está mal configurado; é inalcançável porque o primeiro responde pelos mesmos endereços. Nenhuma métrica pode separá-los, porque a coincidência ocorre antes de as métricas serem consultadas.

A falha é assimétrica e fácil de ler errado. Os hosts do site A alcançam o gateway e alguns serviços, enquanto os do site B não respondem a nada, e o log mostra um túnel saudável nas duas direções. Esse padrão é uma colisão de endereços e não uma falha de autenticação ou firewall, e confirmá-lo exige um dump da tabela comparado ao inventário.

Dimensione deliberadamente o pool de clientes e os intervalos dos sites

Um pool de clientes VPN é um intervalo do qual o gateway entrega um endereço por vez, então seu tamanho limita a concorrência. Um /24 abriga 254 endereços utilizáveis, o que é generoso para uma equipe pequena e apertado para uma filial que executa contêineres; um /22 não custa nada extra dentro do espaço privado e elimina a discussão. Mantenha o pool contíguo e longe de cada LAN de site, para que a rota resumida para os clientes nunca engula um site. Reserve o intervalo mesmo enquanto o pool está vazio, porque um intervalo não escrito é o que o próximo engenheiro vai alocar.

Os sites recebem intervalos dimensionados para os hosts esperados mais o crescimento, alinhados em uma fronteira que se resume de forma limpa. As lacunas deliberadas entre alocações não custam nada e compram espaço para agregar depois.

Depois verifique a direção que as pessoas esquecem: o caminho de volta. Cada roteador de site precisa de uma rota para o pool de clientes, e o concentrador precisa de uma rota para cada prefixo de site que atende. Uma tabela de prefixos organizada sem caminho de volta ao pool continua sendo um projeto quebrado, e o sintoma é uma conexão unidirecional que não responde a nada. Mantenha as duas direções na mesma tabela e revise-a sempre que um site for adicionado.

Tradução e renumeração resolvem problemas diferentes

Quando já existe uma sobreposição, há duas opções honestas e uma desonesta. A renumeração remove a colisão permanentemente e custa uma janela de manutenção mais cada endereço codificado que você esqueceu. A tradução de endereços mapeia o intervalo privado de um lado para outro intervalo na borda do túnel, o que deixa os dois sites intactos mas acrescenta estado, quebra protocolos que embutem endereços e torna os logs mais difíceis de ler. A opção desonesta é uma rota de host para um único servidor, que passa em um teste e falha em todo o resto.

Escolha por controle e vida útil. Um site que você possui e pode programar pertence ao caminho da renumeração; uma rede de parceiro que você não pode tocar, usada para uma única aplicação, é candidata à tradução com um mapeamento documentado. Escreva esse mapeamento, porque uma tradução que só existe dentro de um arquivo de configuração desaparece no momento em que o arquivo é substituído.

Teste do lado remoto antes de implantar

Teste a partir de uma rede que não hospeda o gateway, porque a LAN do próprio gateway esconde a maioria dos erros de roteamento. Conecte um cliente atrás de um roteador doméstico comum e depois alcance um serviço em cada site e um dentro do pool de clientes. Teste também a direção inversa, de um host de site para o cliente, porque os caminhos de volta falham de forma independente. Um teste que só faz ping no gateway prova que o túnel está no ar e nada mais.

Mantenha intervalos, proprietários e mapeamentos de tradução em um único registro compartilhado que o próximo site leia antes de alocar qualquer coisa. Revise-o quando um site for adicionado e trate um intervalo não documentado como defeito e não como surpresa.

O registro é a entrega. Um plano que vive na memória de três pessoas falha na primeira vez que uma delas está de férias, e uma sobreposição encontrada em produção custa mais do que a tabela teria custado.