Cómo presupuestar el espacio de direcciones para una VPN multisitio

Qué tamaño debe tener la subred VPN no tiene respuesta hasta que nombre qué direcciones está contando. En un diseño esas direcciones son los dos extremos de un enlace de túnel numerado, en otro son la LAN de la oficina detrás de un túnel basado en políticas, y en un tercero son la infraestructura reservada de una pasarela gestionada. Tres objetos, tres presupuestos, y la mayoría de los errores de dimensionamiento vienen de rellenar una columna con el número de otra.

Cuatro papeles, cuatro preguntas distintas

El transporte exterior es la dirección a la que se conecta un par, así que su tamaño sigue su direccionamiento público o el del proveedor, nunca el número de dispositivos detrás. Los enlaces de túnel internos solo existen en diseños que numeran una interfaz virtual, y allí el recuento sigue las adyacencias de la topología. Los prefijos de LAN protegida siguen las redes reales y su plan de crecimiento. La infraestructura reservada por el proveedor sigue lo que documenta el servicio gestionado.

Solo el tercero de ellos tiene relación con cuántos portátiles contiene la oficina. Esa única confusión explica la mayoría de las discusiones.

Escriba los cuatro papeles como columnas separadas antes de abrir una calculadora. Cada uno recibe su propia asignación, propietario y supuesto de crecimiento, y ninguno hereda el tamaño de otro. Cuando un diseño no tiene enlace interno numerado, esa columna está vacía en lugar de pequeña, y una columna vacía es un hecho que merece registrarse para el siguiente revisor.

Contar bloques: lo que cuesta realmente un /30

Un enlace punto a punto necesita dos direcciones y consume un bloque cuyo tamaño depende de la plataforma. Un /30 contiene cuatro direcciones, dos de las cuales suelen ser utilizables, así que doce enlaces consumen cuarenta y ocho direcciones en el plan mientras ofrecen veinticuatro extremos. Un /31 contiene dos direcciones y ambas son utilizables, lo que reduce la aritmética a la mitad, pero solo donde ambos extremos lo aceptan.

RFC 3021 define el modelo de dos direcciones, y el soporte es una propiedad de los extremos y del servicio, no de las buenas intenciones. Una API de proveedor puede imponer su propio requisito de máscara en una opción de túnel interno, y un RFC general no anula una restricción documentada. Compruebe qué declara su plataforma antes de resumir el presupuesto, porque la diferencia entre cuarenta y ocho y veinticuatro direcciones decide si el plan cabe en el rango reservado. Haga la aritmética en lugar de confiar en ella al final de un día largo.

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

Multiplique solo cuando la topología esté decidida. Doce enlaces separados y una superposición multipunto con doce participantes producen totales muy distintos a partir del mismo recuento de sedes.

La subred de la pasarela gestionada no es un grupo de clientes

Un servicio gestionado a menudo reserva una subred para su propia infraestructura de pasarela, y esa subred la consume el servicio en lugar de entregarla a los clientes. Tiene un tamaño documentado, a veces un nombre documentado, y ninguna relación con cuántos usuarios se conectan. Tratarla como el grupo de direcciones para máquinas remotas produce un diseño que se agota la primera mañana cargada.

Lea el requisito del proveedor como un coste fijo, igual que trataría una unidad de rack. No forma parte del presupuesto del prefijo protegido.

La misma lectura se aplica a los nombres. Una subred cuya finalidad documentada es la infraestructura de pasarela es infraestructura por convención en ese servicio, y renombrarla para encajar con su propio esquema rompe el despliegue en lugar de mejorar el diagrama. Conserve los nombres y tamaños del proveedor, y gaste su propio esquema de numeración en las partes que controla.

Documente el plan para que sobreviva a la segunda sede

Un plan que vive en la cabeza de un solo ingeniero falla en el primer solapamiento entre un prefijo de oficina y el rango predeterminado de un router doméstico. Publique las asignaciones con sus propietarios e indique qué extremo de cada enlace asigna qué dirección. Las rutas o los selectores todavía deben anunciarse, porque numerar un enlace interno no publica una LAN por sí solo.

Registre el supuesto de crecimiento detrás de cada bloque, porque esa es la parte que ningún lector posterior puede reconstruir solo a partir de las direcciones.

Después pruebe el plan con los casos incómodos: una sede que llega con un prefijo que ya usa, un enlace cuyo extremo remoto gestiona otra persona, y una región cuyo requisito de proveedor difiere del primero que documentó. Si cualquiera de ellos fuerza un rediseño, lo que tenía era un diagrama y no una política. Un plan que los sobrevive es lo bastante corto para estar en el repositorio junto a la configuración del túnel, que es exactamente donde la siguiente persona lo buscará.