Como orçar o espaço de endereços para uma VPN multissítio

Qual deve ser o tamanho da sub-rede VPN não tem resposta enquanto não nomear quais endereços está a contar. Num projeto são as duas extremidades de uma ligação de túnel numerada, noutro é a LAN do escritório atrás de um túnel baseado em políticas, e num terceiro é a infraestrutura reservada de um gateway gerido. Três objetos, três orçamentos, e a maioria dos erros de dimensionamento vem de preencher uma coluna com o número de outra.

Quatro papéis, quatro perguntas diferentes

O transporte externo é o endereço a que um par se liga, pelo que o seu tamanho segue o seu endereçamento público ou o do fornecedor, nunca o número de dispositivos atrás dele. As ligações de túnel internas só existem em projetos que numeram uma interface virtual, e aí a contagem segue as adjacências da topologia. Os prefixos de LAN protegida seguem as redes reais e o seu plano de crescimento. A infraestrutura reservada pelo fornecedor segue o que o serviço gerido documenta.

Só o terceiro deles tem relação com quantos portáteis o escritório contém. É essa única confusão que explica a maioria das discussões.

Escreva os quatro papéis como colunas separadas antes de abrir uma calculadora. Cada um recebe a sua própria alocação, proprietário e pressuposto de crescimento, e nenhum herda o tamanho de outro. Quando um projeto não tem ligação interna numerada, essa coluna fica vazia em vez de pequena, e uma coluna vazia é um facto que vale a pena registar para o próximo revisor.

Contar blocos: o que custa realmente um /30

Uma ligação ponto a ponto precisa de dois endereços e consome um bloco cujo tamanho depende da plataforma. Um /30 contém quatro endereços, dois dos quais normalmente utilizáveis, pelo que doze ligações consomem quarenta e oito endereços no plano enquanto oferecem vinte e quatro extremidades. Um /31 contém dois endereços e ambos são utilizáveis, o que reduz a aritmética para metade, mas apenas onde ambas as extremidades o aceitam.

RFC 3021 define o modelo de dois endereços, e o suporte é uma propriedade das extremidades e do serviço, não das boas intenções. Uma API de fornecedor pode impor o seu próprio requisito de máscara numa opção de túnel interno, e um RFC geral não anula uma restrição documentada. Verifique o que a sua plataforma declara antes de resumir o orçamento, porque a diferença entre quarenta e oito e vinte e quatro endereços decide se o plano cabe no intervalo reservado. Faça a aritmética em vez de confiar nela no fim de um dia longo.

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

Multiplique apenas depois de a topologia estar definida. Doze ligações separadas e uma sobreposição multiponto com doze participantes produzem totais muito diferentes a partir do mesmo número de locais.

A sub-rede do gateway gerido não é um conjunto de clientes

Um serviço gerido reserva frequentemente uma sub-rede para a sua própria infraestrutura de gateway, e essa sub-rede é consumida pelo serviço em vez de ser entregue aos clientes. Tem um tamanho documentado, por vezes um nome documentado, e nenhuma relação com quantos utilizadores se ligam. Tratá-la como o conjunto de endereços para máquinas remotas produz um projeto que se esgota na primeira manhã movimentada.

Leia o requisito do fornecedor como um custo fixo, tal como trataria uma unidade de rack. Não faz parte do orçamento do prefixo protegido.

A mesma leitura aplica-se aos nomes. Uma sub-rede cuja finalidade documentada é a infraestrutura de gateway é infraestrutura por convenção nesse serviço, e renomeá-la para encaixar no seu próprio esquema quebra a implantação em vez de melhorar o diagrama. Mantenha os nomes e tamanhos do fornecedor, e gaste o seu próprio esquema de numeração nas partes que controla.

Documente o plano para que sobreviva ao segundo local

Um plano que vive na cabeça de um único engenheiro falha na primeira sobreposição entre um prefixo de escritório e o intervalo predefinido de um router doméstico. Publique as alocações com os seus proprietários, e indique qual extremidade de cada ligação atribui qual endereço. As rotas ou os seletores têm ainda de ser anunciados, porque numerar uma ligação interna não publica uma LAN por si só.

Registe o pressuposto de crescimento por trás de cada bloco, porque é essa a parte que nenhum leitor posterior consegue reconstruir apenas a partir dos endereços.

Depois teste o plano com os casos incómodos: um local que chega com um prefixo que já usa, uma ligação cuja extremidade remota é gerida por outra pessoa, e uma região cujo requisito do fornecedor difere do primeiro que documentou. Se qualquer deles forçar um redesenho, o que tinha era um diagrama e não uma política. Um plano que lhes sobrevive é suficientemente curto para ficar no repositório ao lado da configuração do túnel, e é exatamente aí que a próxima pessoa o vai procurar.