Planeie as sub-redes antes de uma VPN entre sites: renumere ou traduza

Dois escritórios usam ambos 192.168.1.0/24 porque ninguém planeou de outra forma, e espera-se que o túnel resolva isso. Não pode: um router não consegue fazer com que o mesmo endereço privado signifique dois locais diferentes. O trabalho que evita isso acontece antes de o primeiro parâmetro do túnel ser escrito.

Inventarie cada intervalo, incluindo os que esqueceu

Reúna as LAN, os segmentos de servidores, os pools de clientes de acesso remoto, os intervalos de VPC na nuvem e quaisquer redes de contentores ou sobrepostas que os anfitriões tenham de alcançar. Os pools de clientes são os que as pessoas esquecem, e sobrepõem-se a um intervalo de escritório com uma frequência surpreendente porque ambos foram escolhidos do mesmo valor predefinido. Inclua a rede de gestão e qualquer segmento fora de banda.

Registe o proprietário, o gateway, o objetivo e se o prefixo tem de ser alcançável a partir do outro site. Um prefixo que nunca precisa de atravessar o túnel não tem de ser único, e saber isso reduz o trabalho de renumeração.

Faça o IPv6 à parte, porque o plano e as sobreposições são independentes.

Compare prefixos, não endereços familiares

Duas redes com endereços de anfitrião diferentes podem ainda sobrepor-se, porque a sobreposição é uma propriedade das máscaras e não dos números que as pessoas memorizam. 10.20.0.0/16 contém 10.20.30.0/24, quer alguém o diga em voz alta ou não. Compare pares de prefixos completos e verifique os agregados contra as redes mais pequenas lá dentro. É por isso que a verificação pertence a uma folha de cálculo e não à cabeça de alguém.

A mesma verificação aplica-se ao próprio pool de clientes da VPN e a qualquer intervalo traduzido que planeie introduzir, porque um intervalo traduzido que colide é pior do que a sobreposição original.

Basta uma tabela de prefixos com máscaras; um diagrama sem máscaras não.

Decida o que tem realmente de atravessar

Um site pode conter trinta sub-redes enquanto uma rede de serviço precisa de acesso remoto. Parta desse requisito e anuncie apenas o que ele precisa, porque anúncios mais pequenos e regras de acesso correspondentes são mais fáceis de rever e mais difíceis de alargar por acidente. Anunciar todos os intervalos privados em uso é um hábito que transforma um túnel numa ponte. Quanto mais estreito o anúncio, menor o raio de impacto de um erro futuro.

O DNS privado tem de devolver endereços que os clientes previstos consigam alcançar, por isso um nome que aponta para um intervalo não anunciado ou sobreposto continua quebrado mesmo quando a consulta tem sucesso.

Escreva a lista de acesso antes da configuração do túnel, não depois de falhar.

Renumere ou traduza, e conheça o custo

Renumerar uma rede é normalmente o remédio mais claro a longo prazo, e toca reservas, dispositivos, DNS, regras de firewall e tudo o que tenha um endereço incrustado numa configuração. Traduzir um intervalo de acesso é a alternativa quando renumerar não é prático, e custa a identidade de origem mais uma classe de protocolos que incorporam endereços na carga útil. Escolha uma e termine-a, porque uma rede a meio renumerar é pior do que qualquer das opções.

Escolha o que escolher, documente tanto o endereço original como o apresentado, porque cada conversa posterior de resolução de problemas precisa dos dois.

Uma solução alternativa sem caminho de retorno não é uma solução.

Use uma matriz de rotas como teste de aceitação

Termine com uma matriz: prefixo local, prefixo remoto, serviço permitido e gateway de retorno. Essa tabela é o teste de aceitação quando o túnel sobe, e é também o documento que o próximo engenheiro vai ler. Teste a partir de anfitriões reais nas sub-redes escolhidas e não dos gateways.

Um ping entre endereços do túnel prova que o túnel existe e nada sobre o plano de endereços por trás.

Guarde a matriz com a configuração do túnel, e a próxima adição de site começa a partir de dados e não de memória. O guia de encaminhamento do strongSwan cobre o lado do gateway assim que o plano existe.