Como orzamentar o espazo de enderezos para unha VPN multisede

Que tamaño debe ter a subrede VPN non ten resposta ata que nomee que enderezos está a contar. Nun deseño son os dous extremos dunha ligazón de túnel numerada, noutro é a LAN da oficina detrás dun túnel baseado en políticas, e nun terceiro é a infraestrutura reservada dunha pasarela xestionada. Tres obxectos, tres orzamentos, e a maioría dos erros de dimensionamento veñen de encher unha columna co número doutra.

Catro papeis, catro preguntas distintas

O transporte exterior é o enderezo ao que se conecta un par, así que o seu tamaño segue o seu enderezamento público ou o do provedor, nunca o número de dispositivos detrás. As ligazóns de túnel internas só existen en deseños que numeran unha interface virtual, e alí a conta segue as adxacencias da topoloxía. Os prefixos de LAN protexida seguen as redes reais e o seu plan de crecemento. A infraestrutura reservada polo provedor segue o que documenta o servizo xestionado.

Só o terceiro deles ten relación con cantos portátiles contén a oficina. Ese único erro explica a maioría das discusións.

Escriba os catro papeis como columnas separadas antes de abrir unha calculadora. Cada un recibe a súa propia asignación, propietario e suposición de crecemento, e ningún herda o tamaño doutro. Cando un deseño non ten ligazón interna numerada, esa columna está baleira en lugar de pequena, e unha columna baleira é un feito que merece rexistrarse para o seguinte revisor.

Contar bloques: o que custa realmente un /30

Unha ligazón punto a punto necesita dous enderezos e consume un bloque cuxo tamaño depende da plataforma. Un /30 contén catro enderezos, dous dos cales adoitan ser utilizables, así que doce ligazóns consomen corenta e oito enderezos no plan mentres ofrecen vinte e catro extremos. Un /31 contén dous enderezos e ambos son utilizables, o que reduce a aritmética á metade, pero só onde ambos extremos o aceptan.

RFC 3021 define o modelo de dous enderezos, e o soporte é unha propiedade dos extremos e do servizo, non das boas intencións. Unha API de provedor pode impor o seu propio requisito de máscara nunha opción de túnel interna, e un RFC xeral non anula unha restrición documentada. Comprobe que declara a súa plataforma antes de resumir o orzamento, porque a diferenza entre corenta e oito e vinte e catro enderezos decide se o plan cabe no rango reservado. Faga a aritmética en lugar de confiar nela ao final dun día longo.

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

Multiplique só cando a topoloxía estea decidida. Doce ligazóns separadas e unha superposición multipunto con doce participantes producen totais moi distintos a partir do mesmo reconto de sedes.

A subrede da pasarela xestionada non é unha reserva de clientes

Un servizo xestionado adoita reservar unha subrede para a súa propia infraestrutura de pasarela, e esa subrede consómea o servizo en lugar de entregala aos clientes. Ten un tamaño documentado, ás veces un nome documentado, e ningunha relación con cantos usuarios se conectan. Tratala como a reserva de enderezos para máquinas remotas produce un deseño que se esgota na primeira mañá cargada.

Lea o requisito do provedor como un custo fixo, igual que trataría unha unidade de rack. Non forma parte do orzamento do prefixo protexido.

A mesma lectura aplícase aos nomes. Unha subrede cuxa finalidade documentada é a infraestrutura de pasarela é infraestrutura por convención nese servizo, e renombrarla para encaixar co seu propio esquema rompe o despregamento en lugar de mellorar o diagrama. Conserve os nomes e tamaños do provedor, e gaste o seu propio esquema de numeración nas partes que controla.

Documente o plan para que sobreviva á segunda sede

Un plan que vive na cabeza dun só enxeñeiro falla no primeiro solapamento entre un prefixo de oficina e o rango predeterminado dun router doméstico. Publique as asignacións cos seus propietarios e indique que extremo de cada ligazón asigna que enderezo. As rutas ou os selectores aínda deben anunciarse, porque numerar unha ligazón interna non publica unha LAN por si só.

Rexistre a suposición de crecemento detrás de cada bloque, porque esa é a parte que ningún lector posterior pode reconstruír só a partir dos enderezos.

Despois probe o plan cos casos incómodos: unha sede que chega cun prefixo que xa usa, unha ligazón cuxo extremo remoto xestiona outra persoa, e unha rexión cuxo requisito de provedor difire do primeiro que documentou. Se calquera deles forza un redeseño, o que tiña era un diagrama e non unha política. Un plan que os sobrevive é abondo curto para estar no repositorio xunto á configuración do túnel, que é exactamente onde a seguinte persoa o buscará.