Calculadora de subredes IPv4 e IPv6

Escenario

Se va a definir desde cero el espacio de direcciones de la empresa. Hay 150 sedes y 16 plantas, y las redes virtuales en la nube también se ubicarán en el mismo espacio. Las unidades de negocio se reorganizan cada pocos años y las regiones a las que pertenecen las sedes también cambian. Es la fase de decidir, antes que nada, qué va en cada parte de 10/8.

Supuestos

Poder dividir 10/8 libremente dentro de la propia empresa. No tener que considerar, por ahora, que una futura integración mezcle este espacio con el de otra empresa. Poder añadir más tipos de uso más adelante. Poder contar las líneas de filtro que hacen referencia a los límites.

Asignación

Razonamiento

Lo primero que hay que decidir en 10/8 es qué significado tendrá el segundo octeto. Hay tres candidatos: dividir por uso, por organización o por geografía.

En resumen, se divide por uso. La organización y la geografía cambian, pero el uso no. Las unidades de negocio se reorganizan cada pocos años y las responsabilidades regionales también se intercambian. En cambio, una planta nunca se convierte en una sede de oficinas y un entorno de pruebas nunca pasa a ser producción.

Si se divide por organización, cada reorganización obliga a elegir entre mover los límites o dejar nombres que ya no coinciden con la realidad. Casi siempre se elige lo segundo, y a los pocos años hay otro departamento ocupando el bloque de ventas. Llegado ese punto, la división que figura en el documento de diseño y lo que realmente hay en los equipos dejan de coincidir.

Los límites del nivel superior no se pueden mover, porque los filtros están escritos suponiendo que 10.16.0.0/12 corresponde a las plantas. Si un límite se mueve, hay que revisar todas las líneas que lo referencian. Con 150 sedes, 16 plantas y la nube, son cientos de líneas, y si no se cambian todas a la vez, habrá un periodo en el que el tráfico solo pase en un sentido.

Por eso, lo que se decide al principio debe ser lo mínimo. Al dividir 10/8 en /12 se obtienen 16 bloques para asignar a usos. Se empieza con cuatro usos y, cuando falte espacio, se añade un bloque. Los bloques solo se añaden, así que los límites existentes no se mueven. Usar solo 4 de los 16 bloques parece un desperdicio, pero no tener que mover nada vale más.

Margen de crecimiento

Hay 16 bloques /12 en total. Los cuatro usos (común a toda la empresa, sedes, plantas y nube) ocupan cuatro bloques, y quedan doce libres. Para añadir un uso, se le asigna un bloque libre, como 10.64.0.0/12, sin mover los límites existentes. Los usos que surjan más adelante, como pruebas o IoT, también toman un bloque nuevo en lugar de dividir uno existente. Qué bloque se asigna a continuación se decide cuando haga falta.

Errores frecuentes

• Dividir el segundo octeto por organización. Las reorganizaciones se producen cada pocos años, pero los límites no se pueden mover, así que los nombres dejan de coincidir con la realidad y quedan así. Se divide por uso.
• Crear desde el principio muchos tipos de uso detallados. No solo aumentan los bloques sin usar, sino que cada nueva solicitud obliga a decidir a qué uso pertenece. Se empieza con unos cuatro y se añaden más cuando hace falta.
• Tomar prestada parte del bloque vecino para un uso que se ha quedado sin espacio. Aparece un límite a mitad del bloque y, desde entonces, solo ese bloque mezcla dos usos. Si falta espacio, se asigna un bloque entero.
• Dejar solo el resultado de la división, sin los motivos. El siguiente responsable puede ver para qué es cada bloque, pero no por qué se dividió por uso, así que periódicamente surge la propuesta de volver a dividir por organización.
• Tomar al final el rango común a toda la empresa. Los bloques más cómodos se reparten primero y lo común a toda la empresa acaba disperso en bloques alejados. Lo común a toda la empresa se toma en el primer bloque.

Escenario

Una empresa de unas 100 personas tiene sus equipos de campo y de pruebas en el rango 192.168. Cada vez que se plantea conectar sedes con un socio comercial o un contratista, las direcciones entran en conflicto con las de las instalaciones de la otra parte y hay que coordinarlas. Las conexiones de teletrabajo también entran a veces en conflicto con los routers inalámbricos personales de los empleados.

Supuestos

No siempre es posible saber de antemano qué direcciones se usan en las instalaciones de la otra parte. Se pueden separar los equipos que tienen rutas hacia el exterior de los que no. Cambiar después la dirección de un equipo requiere una visita in situ y una reconfiguración. 10/8 también está disponible.

Asignación

Razonamiento

192.168.0.0/16 no es solo de la empresa. Los equipos domésticos, los routers inalámbricos personales y las instalaciones de socios y contratistas usan el mismo espacio. Es bien sabido que los valores predeterminados se concentran en 192.168.0 y 192.168.1, pero el problema no termina ahí. Los valores predeterminados de los equipos pequeños también se reparten por 192.168.10, 192.168.100 y otros, y normalmente no es posible saber de antemano qué usa la otra parte.

Si se esquiva cada bloque que entra en conflicto, el registro de bloques esquivados no deja de crecer. Tras diez años de operación llega a decenas de bloques, y cada nuevo socio obliga a cotejarlo con la lista. El cotejo lo hacen personas, así que se escapan casos.

Por eso se hace al revés. El rango que se usa se fija por el bit de orden superior, y solo se toma como propia la mitad en la que el tercer octeto es 128 o mayor. Se renuncia a la mitad del espacio, pero la decisión se toma una sola vez. Una empresa de unas 100 personas necesita menos de 10 bloques, así que 128 sobran.

También se limita lo que se coloca ahí. En este espacio solo pueden ir equipos que no tengan rutas hacia otras empresas ni hacia otras sedes. Si se sabe que los conflictos en este espacio son inevitables, basta con colocar solo lo que no se ve afectado por un conflicto. Todo lo que sea visible desde el otro extremo de una conexión entre sedes, o que salga a una interconexión, toma sus direcciones de 10.0.0.0/8.

Margen de crecimiento

La empresa usa solo la mitad en la que el tercer octeto es 128 o mayor, y ocupa 4 de esos 128 bloques. La otra mitad, 192.168.0.0/17, se deja libre, y no se coteja bloque por bloque aunque aumenten los socios. La decisión es una sola comprobación: si el tercer octeto es 128 o mayor. Cuando algo necesite rutas hacia el exterior, no se coloca en este espacio, sino que toma sus direcciones de 10.0.0.0/8. Aunque aumenten los equipos, basta con la mitad en uso.

Errores frecuentes

• Dividir el espacio suponiendo que todo 192.168 es de la empresa. Cada interconexión trae un conflicto, cada uno se resuelve esquivando un bloque y los registros de bloques esquivados acaban dispersos. El rango que se usa se fija por el bit de orden superior.
• Mantener una lista de bloques en conflicto para esquivarlos. Cada nuevo socio obliga a cotejarla y, como lo hacen personas, se escapan casos. La decisión se reduce a una sola comprobación del bit de orden superior.
• Colocar en este espacio equipos visibles desde el exterior. Cuando entran en conflicto con las instalaciones de la otra parte, solo se puede mover el lado propio, así que hay que cambiar las direcciones de los equipos. Todo lo que sale al exterior toma sus direcciones de 10.0.0.0/8.
• Empezar a usar la mitad que no se usa porque dejarla vacía parece un desperdicio. Los bloques que se empiezan a usar no se pueden recuperar; no se gana nada y se pierde la sencillez de la decisión. Para unas 100 personas, 128 bloques sobran.

Escenario

Oficina central o sucursal de unos 100 empleados en una o dos plantas. Usa red cableada e inalámbrica, y mantiene un servidor de archivos y un NAS en las propias instalaciones. Es la configuración más típica.

Supuestos

Disponer de al menos un switch de capa 3 o un router compatible con VLAN. El DHCP puede residir tanto en un equipo de red como en un servidor. Prever que la plantilla pueda crecer hasta 1,5 veces en los próximos tres años.

Asignación

Razonamiento

En torno a las 100 personas, la primera duda es si basta con un solo bloque /24 para todo. La respuesta es que, para lo cableado, basta, pero la sede no debe quedar en un único /24 para todo. Un /24 basta por sí solo para los clientes cableados. Sin embargo, al contar los smartphones de empresa y las conexiones inalámbricas de los portátiles, cada persona tiene en realidad dos o tres dispositivos, y las 254 direcciones de un /24 se llenan enseguida.

Por eso se reserva un /22 y se divide en bloques /24 y /26 por dentro. Los clientes cableados y los inalámbricos reciben cada uno su propio /24 para que el agotamiento de un pool DHCP no se extienda al otro. Servidores y gestión se quedan en /26 porque a esta escala casi nunca superan los 60 equipos, y asignarles más haría perder la legibilidad del tercer octeto.

Dar significado al tercer octeto también es deliberado. Si se hace corresponder 0 = cableado, 1 = equipos con IP fija, 2 = inalámbrico y 3 = fase 2, basta un vistazo a una captura de paquetes o a un log para saber de qué segmento se trata. Esta legibilidad se traduce directamente en rapidez al resolver incidencias.

Margen de crecimiento

Como 10.20.3.0/24 queda completamente libre, aunque la plantilla crezca 1,5 veces se puede ampliar el inalámbrico a /23 o añadir un segmento por departamento. Si el /26 de servidores se queda corto, se trasladan las impresoras de 10.20.1.128/27 a 10.20.1.192/27 y la gestión de equipos al 10.20.1.128/26 que queda libre; así los servidores pueden duplicarse como 10.20.1.0/25. Para añadir otra sede se continúa con 10.21.0.0/22, 10.22.0.0/22, etc., y se agregan como 10.20.0.0/14.

Errores frecuentes

• Usar 192.168.1.0/24 o 192.168.0.0/24 en la red corporativa. Entran en conflicto con los valores predeterminados de los routers domésticos, así que el enrutamiento se rompe en las conexiones VPN del teletrabajo. Lo seguro es obtener los bloques de 10/8.
• Juntar los clientes inalámbricos y cableados en el mismo segmento. Cuando más adelante se quiere añadir un SSID para invitados, hay que rehacer el plan de direccionamiento. Separarlos desde el principio no cuesta casi nada.
• Mezclar las direcciones de gestión de los equipos de red en un segmento de clientes. Las ACL ya no pueden restringir por separado el acceso de gestión, y las auditorías lo señalan siempre.
• Usar el /24 de reserva para una necesidad inmediata «porque está libre». La reserva vale precisamente por no usarse, así que conviene llamarla «fase 2» en lugar de «reserva»: así se respeta más.

Escenario

Sede de unos 100 puestos sin asignación fija. Con una plantilla de 120 personas, la tasa de asistencia a la oficina oscila entre el 40 % y el 80 % según el día. Todos llevan portátil, y los puertos cableados solo quedan en las salas de reuniones y en algunos puestos fijos. Siempre hay unas 10 personas de personal temporal, como trabajadores cedidos por agencia o contratistas en sitio.

Supuestos

Que la red inalámbrica cubra toda la sede y que los empleados puedan trabajar con sus dispositivos solo por vía inalámbrica. Poder cambiar el tiempo de concesión DHCP por segmento. Poder obtener después la asistencia real de cada día, por ejemplo a partir de los registros de entrada y salida. Se parte de que no hay un sistema de reserva de puestos.

Asignación

Razonamiento

Al dimensionar el pool, las primeras cifras que aparecen son los 100 puestos y la plantilla de 120. Lo primero es descartar el número de puestos. Después se considera el número de dispositivos en la asistencia máxima: con un 80 % de asistencia son 96 personas y, como cada una lleva un portátil y un smartphone de empresa, 192 dispositivos. Hasta aquí caben en un /24, con sus 254 direcciones.

El error viene después. Con puestos compartidos no se sabe quién vendrá hoy. Con un tiempo de concesión de 24 horas, las direcciones de los dispositivos de quienes vinieron ayer y no hoy siguen vivas. Que la asistencia oscile entre el 40 % y el 80 % significa que hay días en que pocas personas repiten de un día al siguiente. Si a un día del 40 % (48 personas) le sigue uno del 80 % (96 personas) casi sin repetir caras, las personas que vinieron en esos dos días se acercan a la plantilla de 120, y las concesiones vivas llegan a un máximo de 240 dispositivos. Es el 94 % de las 254 direcciones de un /24, y solo quedan 14. El agotamiento no llega el día más concurrido, sino el día en que cambian las caras. Lo que hay que contar no es la asistencia máxima, sino cuántas personas pueden venir dentro de un tiempo de concesión, es decir, una cifra cercana a la plantilla.

¿Basta entonces con acortar la concesión? Tiene un límite inferior. Si los portátiles se cierran durante la comida y las reuniones de la tarde, quedan de tres a cuatro horas sin comunicación, y con una concesión de 2 horas algunos dispositivos obtienen otra dirección al volver. El límite superior lo fija el tamaño del pool, y el inferior, la forma de trabajar. Para cumplir ambos, la única opción es un /23 para el pool. Con 510 direcciones, incluso con 240 dispositivos queda libre el 53 %.

Al tomar un /23 se pierde la correspondencia entre el tercer octeto y el segmento, pero en esta sede se prioriza evitar el agotamiento sobre la legibilidad. Si en el mismo pool se van a incluir dispositivos que se comunican mientras se desplazan constantemente, hace falta una decisión aparte.

Margen de crecimiento

El 10.16.10.0/23 contiguo no se deja libre pensando en el futuro, sino para ampliar el pool como una única subred. Un pool no se puede ampliar añadiendo trozos separados, así que, para convertir el /23 en un /22, el /23 adyacente debe estar libre por completo. El punto de decisión se fija en una plantilla de 210 personas porque, si casi todos vienen en dos días, son 420 dispositivos, el 82 % de las 510 direcciones del /23 actual. En ese momento se fusiona el bloque adyacente para formar 10.16.8.0/22 y se mantiene el tiempo de concesión. Por esta restricción, tanto lo cableado como los servidores se han desplazado a 10.16.12.0/24. Si no se deciden antes las condiciones para liberar ese espacio, siempre acabará ocupado por otro uso.

Errores frecuentes

• Dimensionar el pool por número de puestos. Si se asigna un /25 porque hay 100 puestos, no alcanza en cuanto se cuentan dos dispositivos por persona y el personal temporal, y se agota la primera semana de operación. Se cuentan dispositivos, no puestos.
• Acortar el tiempo de concesión para aumentar la rotación y evitar el agotamiento. Los dispositivos que vuelven tras la comida o una reunión obtienen otra dirección y pierden la conexión, pero como el corte solo ocurre en el momento de volver, no se reproduce y nadie lo reporta.
• Poner los dispositivos del personal temporal en el mismo pool que los de los empleados. El número estimado a partir de la plantilla se desvía continuamente de la realidad, y con cada aumento de personal ya no se puede explicar cuántas direcciones faltaron. Se separa lo que se puede prever de lo que no.
• Mantener la práctica de asignar IP fijas a los puertos cableados. Con puestos compartidos, cada día se sienta una persona distinta en el mismo puerto, así que la correspondencia entre direcciones y usuarios se rompe enseguida y solo queda el registro de direcciones. Lo cableado también se asigna por DHCP.

Escenario

150 sedes en total: 1 oficina central, 8 hubs regionales y 141 oficinas comerciales y almacenes. Cada sede se conecta a la oficina central a través de un hub regional, y las rutas se agregan en los hubs regionales y se pasan al nivel superior. Los números de sede ya se usan en la gestión de activos y en formularios e informes, y se asignaron por orden de apertura. Cada año abren unas pocas sedes y cierran otras pocas.

Supuestos

Cada hub regional puede anunciar sus sedes como una sola ruta. Ya existe un esquema de números de sede y no se puede renumerar por necesidades del plan de direccionamiento. Ninguna sede supera los 1000 dispositivos. La región a la que pertenece cada sede no cambia en plazos de años.

Asignación

Razonamiento

Se agrega para que 150 sedes no suban al nivel superior como 150 rutas. Pero lo que la agregación exige es que los bloques de direcciones sean contiguos, no que lo sean los números de sede. Si se confunde esto, todo el diseño se desperdicia.

Los números de sede ya existen. Se usan en la gestión de activos y en formularios e informes, se asignaron por orden de apertura y no guardan relación con las regiones. Si se copian tal cual en el segundo octeto, el hub de la región 3 acaba con un conjunto disperso, como las sedes 3, 17, 42 y 88. Los bloques dispersos no se agrupan en una sola ruta, así que siguen subiendo 150 rutas. Renumerar para agregar no es posible: los números están incrustados en formularios, informes y en la forma de llamar a cada sede.

Por eso se invierte el orden. Primero se asignan bloques a la unidad de agregación, es decir, al hub regional, y los números de sede se reparten como identificadores dentro de ese bloque. Cada una de las 8 regiones recibe un segundo octeto, y cada sede un bloque /22 propio. Una región admite hasta 64 sedes. Con 150 sedes, incluso la región más grande tiene solo 24, así que todo cabe y suben 8 rutas. Aunque las sedes se dupliquen hasta 300, siguen siendo 8.

El precio es que el número de sede ya no se puede leer en la dirección. Hacerlo legible obliga a renunciar a la contigüidad dentro de cada región. Lo que necesita la atención de incidencias no es una regla de numeración, sino una tabla de correspondencia entre números de sede y bloques.

Margen de crecimiento

Los bloques regionales usan los segundos octetos 1 a 8, y el 0 se reserva para usos comunes a toda la empresa. Los siete bloques del 9 al 15 se dejan libres para añadir regiones y para el segundo bloque regional que se da a una región que supere las 64 sedes. Esos números no son contiguos, así que se consultan en la tabla de correspondencia. De 10.16.0.0/12 en adelante no se toca nada y se reserva para adquisiciones y para incorporar otros negocios.

Errores frecuentes

• Hacer corresponder los números de sede directamente con las direcciones. Los números siguen el orden de apertura y no tienen relación con las regiones, así que las sedes de un mismo hub quedan dispersas y siguen subiendo tantas rutas como sedes. Los números se reparten dentro del bloque regional.
• Tomar las direcciones de los enlaces entre sedes del bloque de la propia sede. Si el otro extremo es una sede de otra región, direcciones del bloque de esta región acaban en esa otra región, y por ellas suben rutas más específicas. Los enlaces se toman de un bloque común fuera de los bloques de sede.
• Añadir segmentos dentro de una sede cruzando el límite de su bloque. La parte que sobresale no queda cubierta por la agregación, y sube una ruta más específica solo para esa sede. Solo se añade dentro del bloque, y al superarlo se entrega un segundo bloque.
• Exigir que el número de sede pueda leerse en la dirección. Hacerlo legible obliga a renunciar a la contigüidad dentro de cada región, y la agregación deja de funcionar. Lo que hace falta no es una regla de numeración, sino una tabla de correspondencia.
• Conectar una sola sede a otro hub regional por conveniencia geográfica. Sus direcciones siguen en el bloque de la región original, así que en el nivel superior aparecen el bloque regional y una ruta aparte solo para esa sede. Si cambia el hub de una sede, se trasladan también sus direcciones.

Escenario

En una red con 300 o más enlaces punto a punto, hay que decidir la longitud de prefijo de los enlaces. Los equipos son de generaciones distintas: conviven equipos antiguos, equipos de propósito específico y equipos virtuales. Se ha propuesto unificar en /31 con el argumento de ahorrar direcciones.

Supuestos

Se puede listar el modelo y la generación de los equipos de ambos extremos de cada enlace. Se puede comprobar de antemano si un equipo admite /31 o no. La asignación se hace en un solo lugar. Cambiar después las direcciones de un enlace obliga a reescribir la configuración y la monitorización.

Asignación

Razonamiento

Un /30 tiene cuatro direcciones y solo dos son utilizables; un /31 aprovecha las dos. El número de direcciones necesarias se reduce a la mitad.

Pero como ahorro no tiene sentido. Con 352 enlaces, /30 ocupa 1408 direcciones y /31 ocupa 704. La diferencia de 704 es apenas un 1 por ciento del bloque /16 reservado para enlaces. Una diferencia tan pequeña no es motivo para cambiar la decisión.

Lo decisivo es si todos los equipos lo admiten. No todos los equipos admiten /31. Puede que algún equipo antiguo, de propósito específico o virtual no lo soporte. Cada enlace tiene un equipo en cada extremo, así que basta con que uno no lo admita para que ese enlace tenga que ser un /30 de todos modos.

Mezclarlos cambia el procedimiento de asignación. En el pool conviven dos tamaños, y en cada asignación hay que comprobar el soporte de los equipos de ambos extremos. A 10 enlaces al mes, son 120 comprobaciones al año. Ahorrar 704 direcciones no vale 120 comprobaciones al año.

Por eso se unifica. Si todos los equipos lo admiten, /31; si queda aunque sea uno que no lo admita, /30 en todos los enlaces. Si no hay más remedio que mezclar, se separan los rangos para que no haga falta comprobar en cada asignación.

Una cosa más. Un enlace cortado como /30 no pasa a /31 aunque se sustituyan sus equipos. Pasarlo implica cambiar sus direcciones, y con ello se reescriben la configuración y los nombres en la monitorización. No se parte de la premisa de migrar más adelante.

Margen de crecimiento

Por defecto se usa /30, y solo los tramos con soporte confirmado se cortan del rango /31 dedicado. Los rangos se separan para no tener que comprobar el soporte de los equipos al asignar. Un tramo se añade al rango /31 solo cuando los equipos de ambos extremos se han sustituido y se ha confirmado su soporte. El crecimiento sale de 10.161.16.0/21. Aunque se sustituyan todos los equipos, los enlaces /30 existentes no se cambian; solo los enlaces que se creen de nuevo se cortan como /31 desde el principio.

Errores frecuentes

• Elegir /31 para ahorrar direcciones. Lo que se ahorra es alrededor del 1 por ciento del bloque de enlaces, y no es motivo para cambiar la decisión. Lo decisivo es si todos los equipos lo admiten.
• Mezclar los dos tamaños en el mismo rango. En cada asignación hay que comprobar el soporte de los equipos de ambos extremos, y a 10 enlaces al mes son 120 tareas más al año. Si hay que mezclar, se separan los rangos.
• Tomar /31 por defecto aunque quede un equipo sin soporte, y dejar solo ese tramo como excepción /30 aparte. Cada sustitución de equipos exige comprobar el soporte, y basta con olvidarlo una vez para que ese enlace quede inutilizable. Se toma /30 por defecto y los /31 se cortan del rango de los tramos con soporte confirmado.
• Elegir /30 contando con pasar a /31 más adelante. Pasar implica cambiar direcciones, y se reescriben la configuración y los nombres en la monitorización. Se decide partiendo de que no habrá migración.

Escenario

Una empresa de unas 100 personas prepara una red inalámbrica para invitados. En días normales hay unos 20 dispositivos de invitados, pero en los días de presentaciones o exposiciones llegan 400 a la vez. El tráfico hacia la red corporativa se bloquea con filtros, pero la resolución de nombres y la asignación de direcciones usan los mismos equipos que la red corporativa.

Supuestos

Se puede ofrecer la red inalámbrica para invitados como un rango separado de la red inalámbrica corporativa. Se puede disponer de una única salida hacia el exterior para los invitados. Se pueden instalar equipos de resolución de nombres y de asignación de direcciones aparte para los invitados. Hay una posición utilizable dentro de 172.16/12.

Asignación

Razonamiento

Se suele pensar que a la red inalámbrica para invitados solo se le pide quedar aislada de la red corporativa: basta con bloquear con filtros el tráfico hacia la red corporativa. Eso no es suficiente.

El rango de invitados también comparte cosas con la red corporativa fuera de los filtros. Si los invitados resuelven nombres con equipos corporativos, sus dispositivos pueden consultar los nombres de los servidores internos. Aunque no se devuelva respuesta, la reacción a la consulta revela qué nombres existen. Si las direcciones se asignan con los mismos equipos que la red corporativa, el día de un evento en que llegan 400 dispositivos a una empresa de 100 personas, también se atasca la asignación de direcciones corporativa. Si se hace que los invitados sincronicen la hora con la red corporativa, hay que abrir una ruta hacia el servidor de hora interno.

Por eso el rango de invitados no comparte nada con la red corporativa. No tiene ruta hacia ningún segmento corporativo y su única salida es una sola hacia el exterior. La resolución de nombres y la asignación de direcciones se mantienen aparte, solo para los invitados. En lugar de bloquear con filtros, se hace que las rutas que habría que bloquear no existan desde el principio. Una ruta bloqueada se abre con una línea; una ruta que no existe no hay forma de abrirla.

La elección de las direcciones también tiene su razón. La mayoría de los dispositivos de invitados establecen conexiones con su propia empresa. Si esa empresa usa 10/8 internamente y el rango de invitados también está en 10/8, las direcciones chocan del otro lado y el invitado no puede conectarse con su empresa. El rango se toma de una posición poco usada dentro de 172.16/12.

Margen de crecimiento

El rango de invitados no tiene ruta hacia ninguna parte de la red corporativa y su única salida es una sola hacia el exterior. La resolución de nombres y la asignación de direcciones también se mantienen aparte para los invitados. Cuando los eventos traen más dispositivos, se añade 172.30.4.0/22 para recibirlos, y lo añadido sale por la misma salida. No se añaden rutas hacia la red corporativa. El rango se toma dentro de 172.16/12 y no se superpone con 10/8, que probablemente usan las empresas de los invitados.

Errores frecuentes

• Conformarse con bloquear con filtros el tráfico hacia la red corporativa. Si la resolución de nombres o la asignación de direcciones se comparten con la red corporativa, la información interna se filtra fuera de los filtros y la carga también se transmite. No se comparte nada.
• Hacer que los dispositivos de invitados usen la resolución de nombres corporativa. Aunque no se devuelva respuesta, la reacción a las consultas revela qué nombres existen. Se mantiene una aparte para los invitados.
• Asignar las direcciones de los invitados con los mismos equipos que la red corporativa. Cuando el número de invitados se dispara el día de un evento, también se atasca la asignación de direcciones corporativa. La asignación se separa para los invitados.
• Tomar el rango de invitados de 10/8. Cuando un invitado se conecta con su propia empresa, las direcciones chocan con la red interna de esa empresa y la conexión falla. Se toma de una posición poco usada dentro de 172.16/12.

Escenario

En una empresa de unas 500 personas, los equipos de la DMZ aumentan año tras año. Un servidor web expuesto a Internet, un servidor para intercambiar archivos con socios comerciales, equipos que reciben correo del exterior, un servidor que solo llama a servicios externos y equipos que envían alertas de monitorización al exterior conviven en un mismo rango.

Supuestos

Se pueden distinguir los equipos que reciben conexiones iniciadas desde el exterior de los que solo envían tráfico hacia fuera. Se puede identificar la contraparte de cada conexión con socios comerciales. Se pueden ofrecer rangos de la DMZ separados por contraparte. El tráfico entre rangos se puede detener en el límite.

Asignación

Razonamiento

El criterio de qué va en la DMZ es uno solo: los equipos que reciben conexiones iniciadas desde el exterior.

Sin criterio, entra todo lo que habla con el exterior: equipos que solo envían tráfico desde dentro hacia fuera, servidores que solo llaman a servicios externos, equipos que envían alertas de monitorización al exterior. Ninguno recibe conexiones iniciadas desde el exterior, así que no hay razón para ponerlos en la DMZ. Si se ponen, la DMZ crece, y cuando uno de ellos es comprometido, todo lo que está a su lado queda a su alcance.

Una vez decidido qué entra, se divide según de quién se recibe. Lo expuesto a Internet y lo destinado a socios comerciales no van en el mismo rango. A lo expuesto a Internet puede llegar cualquiera, así que se diseña dando por hecho que será comprometido. Lo destinado a socios tiene contrapartes conocidas, así que sus permisos son mucho más estrechos. Si están en el mismo rango, cuando un servidor expuesto a Internet es comprometido, los archivos que se intercambian con los socios quedan al alcance desde el servidor de al lado. Restringir las contrapartes pierde su sentido.

El tráfico entre los rangos separados no se permite. No existe ni una sola razón de negocio para ir de lo expuesto a Internet a lo destinado a socios.

Cuando aparece un equipo nuevo que recibe del exterior y no está claro de quién recibe, va al rango expuesto a Internet. Poner en el rango para socios un equipo cuyas contrapartes no se pueden restringir rompe la premisa de ese rango.

Margen de crecimiento

La DMZ se divide según de quién recibe cada rango, y lo expuesto a Internet y lo destinado a socios comerciales van en rangos distintos. El tráfico entre rangos no se permite. Cuando aparece un equipo nuevo que recibe del exterior, su rango se decide según de quién recibe, y si no se puede decidir, va al rango expuesto a Internet. Si faltan rangos, se cortan de 10.170.1.0/24. Los equipos que solo envían tráfico hacia fuera no entran en la DMZ aunque aumenten.

Errores frecuentes

• Meter en la DMZ todo lo que se comunica con el exterior. Si entran también los equipos que solo envían tráfico hacia fuera, la DMZ crece y un solo equipo comprometido alcanza a todo lo que tiene al lado. Solo se ponen los equipos que reciben conexiones iniciadas desde el exterior.
• Poner lo expuesto a Internet y lo destinado a socios comerciales en el mismo rango. Cuando lo expuesto a Internet es comprometido, los archivos que se intercambian con los socios quedan al alcance desde el servidor de al lado. Los rangos se dividen según de quién se recibe.
• Permitir por si acaso el tráfico entre los rangos separados. Un permiso sin razón de negocio solo sirve de camino para un intruso. Entre rangos no se permite nada.
• Poner en el rango para socios un equipo cuya contraparte no está clara. Ese rango restringe sus permisos dando por hecho que las contrapartes son conocidas, y esa premisa se rompe. En caso de duda, se pone en el rango expuesto a Internet.

Escenario

En una red virtual de la nube, se crea en cada zona de fallo una subred pequeña para 10 equipos. Como en la red corporativa, se espera que un /28 admita 14 equipos. En la misma red virtual está prevista también una subred de aplicaciones de unos 200 equipos.

Supuestos

Se sabe que el proveedor que se utiliza toma de antemano algunas direcciones de cada subred. Se puede comprobar cuántas toma y cuál es el tamaño mínimo permitido. El tamaño de una subred no puede cambiarse después de crearla. La red virtual tiene espacio libre.

Asignación

Razonamiento

Al crear una subred en la nube, el proveedor toma de antemano algunas de sus direcciones. Depende del proveedor, pero es habitual que tome las cuatro primeras y la última, cinco en total. En una red corporativa solo la primera y la última dirección no se pueden usar, así que, si se cortan subredes sin conocer esta diferencia, faltan direcciones.

La diferencia pesa más cuanto más pequeña es la subred. En un /24 son 5 de 256, menos del 2 por ciento. En un /26 son 5 de 64, un 8 por ciento. En un /28, el tamaño mínimo que se puede crear, desaparecen 5 de 16, cerca del 30 por ciento. Solo quedan 11 utilizables.

Si se corta un /28 como en la red corporativa, se prevén 14 equipos, pero solo caben 11. Con 10 equipos, el margen es de una sola dirección, y el día que se añaden dos más, la subred se desborda. Como el tamaño de una subred no puede cambiarse después de crearla, un desbordamiento obliga a rehacerla.

Por eso, al cortar subredes pequeñas, se compara el número de equipos con lo que queda después de las reservas. Para 10 equipos, un /28 no basta y se toma un /27 en su lugar. Un /27 deja 27 direcciones utilizables al descontar 5 de 32. Cuanto más pequeña es la subred, mayor es la proporción perdida, así que, como norma, las subredes pequeñas se cortan un escalón más grandes que en la red corporativa.

El número de direcciones reservadas varía según el proveedor, igual que el tamaño mínimo. Al elegir un perfil de reserva en la pestaña Calcular, aparece al instante el número de direcciones utilizables. Las estimaciones se comprueban allí.

Margen de crecimiento

En las subredes pequeñas, se descuentan las 5 direcciones reservadas antes de comparar con el número de equipos. Para 10 equipos, un /28 no basta y se toma un /27 en su lugar. Se alinean con el mismo tamaño, una por zona de fallo. Cuando hagan falta más subredes, se cortan de 10.216.2.0/24. Si hay dudas sobre una estimación, se elige el perfil de reserva en la pestaña Calcular y se comprueba el número de direcciones utilizables.

Errores frecuentes

• Contar las direcciones utilizables como en la red corporativa. Si solo se descuentan la primera y la última, se pasan por alto las otras tres que toma el proveedor, y el número de equipos previsto no cabe. Se compara con lo que queda después de las reservas.
• Tomar el /28, el tamaño mínimo, como estándar. Desaparecen 5 de 16, quedan solo 11 utilizables, y basta añadir unos pocos equipos para desbordar la subred. Para unos 10 equipos, se toma un /27 en su lugar.
• Suponer que una subred se podrá ampliar más adelante. Su tamaño no cambia después de crearla, y un desbordamiento obliga a rehacerla. Se estima desde el principio con las reservas incluidas.
• Suponer que todos los proveedores reservan el mismo número de direcciones. Los proveedores difieren tanto en cuántas toman como en el tamaño mínimo permitido. Se comprueba con el perfil del proveedor que se utiliza.

Escenario

Se conecta la red de una empresa adquirida con la red propia. Ambas usan 10/8 y muchos rangos se solapan. Por necesidades del negocio, las redes tienen que estar conectadas el mes que viene, y no hay tiempo para renumerar ninguno de los dos lados. Se ha propuesto conectarlas traduciendo las direcciones en el límite.

Supuestos

Se puede colocar un único límite capaz de traducir direcciones entre las redes de ambas empresas. Las direcciones traducidas se pueden tomar de un espacio que no pertenezca a ninguna de las dos. Se puede escribir un plazo en las reglas de traducción. El lado que se renumera se puede decidir sin esperar a una decisión de la dirección.

Asignación

Razonamiento

Hay dos maneras de conectar dos redes que se solapan: renumerar una de ellas o traducir las direcciones en el límite. La traducción se implanta en una noche; la renumeración lleva meses. Elegir la traducción al principio de una integración es correcto.

El problema es que la traducción se vuelve permanente. Como el tráfico pasa gracias a la traducción, desaparece el motivo para renumerar. Tres años después, las reglas de traducción se han acumulado y nadie sabe explicar el conjunto. En cada avería hay que comprobar si una dirección que aparece en los logs es anterior o posterior a la traducción.

Por eso, el día en que se implanta la traducción se deciden dos cosas a la vez: el plazo y el lado que se renumera. El plazo se fija como una fecha y se escribe en las propias reglas de traducción. El lado que se renumera se decide ese mismo día, y el periodo de traducción se trata como tiempo de preparación de la renumeración. Una traducción sin decidir qué lado se renumera solo puede prorrogarse cuando llega el plazo.

Las direcciones traducidas se toman de un espacio que no pertenezca a ninguno de los dos lados. Si ambas empresas usan 10/8 y ahí está el solapamiento, las direcciones traducidas se toman de 172.16/12. Si se usa espacio libre del 10/8 de cualquiera de los dos, al incorporar a la siguiente empresa volverá a haber solapamiento.

Hay traducciones que pueden ser permanentes. Cuando el diseño parte de que las mismas direcciones se repiten una junto a otra, como en las líneas de producción construidas copiando la misma configuración, la traducción permanente es correcta. El solapamiento en una integración no es una premisa sino un accidente, y el remedio de un accidente no debe volverse permanente.

Margen de crecimiento

Los rangos traducidos se toman dentro de 172.16/12, y se separa el rango para ver la red de la otra empresa del rango que presenta la red propia a la otra empresa. El plazo se escribe en las reglas de traducción y, antes de que venza, se renumera el lado decidido el día en que se implantó la traducción. Lo que crezca hasta el plazo se corta de 172.18.24.0/22. Una traducción vencida no se prorroga; si hace falta prorrogarla, se vuelve a empezar desde la decisión del lado que se renumera.

Errores frecuentes

• No fijar un plazo al implantar la traducción. Como el tráfico pasa, desaparece el motivo para renumerar, y las reglas de traducción se acumulan hasta que nadie sabe explicarlas.
• Implantar la traducción sin decidir qué lado se renumera. Al llegar el plazo, la discusión vuelve a empezar por decidir qué lado se mueve, así que solo queda prorrogar. Se decide el mismo día que la traducción.
• Tomar las direcciones traducidas del espacio libre del 10/8 propio. La próxima vez que se incorpore otra empresa, volverán a solaparse. Se toman de un espacio que no pertenezca a ninguno de los dos lados.
• Escribir las reglas de traducción equipo por equipo. Los plazos también hay que gestionarlos equipo por equipo, y nadie sabe qué reglas quedan. Se escriben por rangos.

Escenario

Una planta con varias líneas de producción de la misma configuración de equipos, que prevé añadir más. Los controladores entregados por el proveedor de equipos traen IP fijas grabadas de fábrica, y se parte de una situación en la que las mismas direcciones se repiten en varias líneas.

Supuestos

Las direcciones de los controladores de cada línea no se pueden cambiar, o cambiarlas exige que el proveedor de equipos repita la recepción. Las líneas no necesitan comunicarse directamente entre sí; solo con los sistemas de recogida de datos de nivel superior. En el límite de cada línea se puede colocar un equipo de capa 3 o un equipo capaz de hacer NAT.

Asignación

Razonamiento

Lo que separa de forma decisiva una red OT de una red TI es que las direcciones no se eligen libremente. Los proveedores de equipos entregan la misma configuración a muchos clientes, así que las direcciones de los controladores vienen fijadas de fábrica, y la misma 192.168.0.10 existe tanto en la línea 2 como en la línea 3. Si se aplica el reflejo habitual de TI, «se solapan, hay que renumerar», la conversación pasa a la garantía de los equipos y a repetir la recepción, y la planta se para.

Por eso no se renumera. Las direcciones dentro de la línea se dejan tal como las configuró el proveedor de equipos, en el equipo del límite de la línea se aplica una traducción de direcciones 1:1, y solo las direcciones visibles desde fuera se distinguen por número de línea. Un controlador de la línea 1 se ve desde fuera como 172.20.1.x, y el mismo equipo de la línea 2 como 172.20.2.x. Con la regla de que el tercer octeto es el número de línea, quien lea los registros del sistema de recogida sabe al instante de qué línea se trata sin conocer el nombre del equipo.

Lo esencial de este diseño es separar las condiciones del proveedor de equipos y la facilidad de gestión de TI con una sola capa: la traducción. Dentro de la línea manda el proveedor de equipos; del límite hacia arriba, el departamento de sistemas. La mayor ventaja es que añadir una línea no obliga a rehacer el diseño: basta con sumar uno al número y copiar la misma configuración.

Margen de crecimiento

Para las próximas ampliaciones está reservado 172.20.4.0/22 (líneas 4 a 7). Como el bloque base es un /16, la regla de usar el tercer octeto como número de línea llega hasta la línea 255 (el 0 no se usa como número de línea y queda para la recogida y el mantenimiento comunes), y a partir de la línea 8 se continúa con naturalidad con 172.20.8.0/21 y 172.20.16.0/20. Si se añaden plantas, el segundo octeto pasa a ser el número de planta: 172.21.0.0/16 se asigna a la siguiente planta y ambas se agregan como 172.20.0.0/15. Una línea solo se queda corta con su /24 cuando supera los 250 controladores, y a esa escala resulta más fácil de operar si la línea se divide de forma lógica.

Errores frecuentes

• Permitir el tráfico entre líneas «por si acaso». Cuando una línea se infecta con malware, todas las líneas de la misma configuración se paran a la vez. El tráfico entre líneas se bloquea por defecto y el necesario pasa por los sistemas de recogida.
• No preparar un segmento para los portátiles de mantenimiento y conectar los PC traídos de fuera directamente al segmento de control. Es la vía de entrada más frecuente de los incidentes OT, y además no deja registro. Se crea un segmento dedicado y solo desde él se entra al lado de control.
• Guardar la tabla de correspondencia de la traducción de direcciones solo en la configuración del equipo. Cuando la persona que la configuró cambia de puesto, nadie sabe explicar qué dirección externa corresponde a qué equipo. La tabla de correspondencia se mantiene en los documentos de diseño como fuente principal.
• Usar el rango 192.168 para las direcciones de la planta. Entra fácilmente en conflicto con los routers y routers móviles que traen los proveedores de mantenimiento, y el conflicto solo aparece en la propia planta. Las direcciones se toman de 172.16/12 o de 10/8.
• Decidir la correspondencia entre número de línea y direcciones ocupando, en cada ampliación, el número que esté libre. Cuando se retira la línea 7 y después entran otros equipos en su lugar, los números dejan de coincidir con las líneas reales y nadie se fía de ellos. Los números no se reutilizan.

Escenario

Una planta de unos 300 empleados con un edificio de oficinas y un edificio de fabricación en el mismo recinto, gestionados hasta ahora como una sola red. Seguirá haciendo falta enviar instrucciones a los equipos desde el sistema de gestión de la producción y recoger sus resultados, pero se quiere acabar con la situación en la que los PC de oficina llegan directamente a los controladores. En esta etapa no se toca el diseño interior de las líneas y solo se vuelven a trazar primero los límites por encima y por debajo de ellas.

Supuestos

Entre el lado de oficinas y el lado de planta se puede colocar al menos un equipo de capa 3. El tráfico que cruza entre ambos lados se puede inventariar, al menos por servidor de intercambio, con su contraparte y su sentido. Esta vez no se cambian las direcciones de los controladores; el rediseño interior de las líneas se hace aparte. Entre los requisitos está que la producción pueda continuar mientras los equipos del límite estén caídos.

Asignación

Razonamiento

Nadie se opone a separar. Lo que no se llega a decidir es qué tamaño dar a la zona que se coloca en el límite.

Tomar un /24 para el límite siempre sale mal. A esta escala, lo único que de verdad necesita comunicarse con ambos lados son los servidores de intercambio, una docena larga. Las más de 240 direcciones restantes se convierten en solares vacíos, y los solares vacíos siempre se acaban ocupando. Al cabo de seis meses entra un servidor de archivos de los sistemas de gestión; al año siguiente, un servidor de salto unido a la infraestructura de autenticación de la oficina. En ese momento el límite deja de serlo, pero en la tabla de direcciones no cambia nada, así que nadie se da cuenta.

Por eso el intercambio se queda en un /28 y no más. Si solo hay 14 direcciones, quien intente colocar el decimoquinto equipo tendrá que consultarlo con alguien. La idea es que el tamaño funcione como regla de operación. El margen de crecimiento se pone al lado, con otro nombre, como fase 2, y la zona de intercambio en sí no se amplía.

Dividir el /20 en tres áreas, 0 a 3 (TI), 4 a 7 (límite) y 8 a 15 (control), también es intencionado. Los filtros del equipo del límite se escriben en tres líneas, 10.60.0.0/22, 10.60.4.0/22 y 10.60.8.0/21, y esas tres líneas no cambian aunque se añadan segmentos. Un diseño que obliga a tocar los filtros en cada adición acabará algún día con un error que pare la producción.

La zona de servicios compartidos de la red de control, un /25, está en el lado de control por disponibilidad. La producción continúa mientras los equipos del límite están caídos. Si la sincronización horaria y la resolución de nombres dependen del lado de oficinas, una parada del límite se convierte en una parada del lado de control.

Margen de crecimiento

En el límite queda libre 10.60.4.64/26 para la fase 2. No sirve para ampliar el intercambio, sino para añadir más adelante los enlaces de datos con el exterior y los intermediarios de mantenimiento remoto. En el lado de control queda libre 10.60.12.0/22 para las zonas por línea, y ahí va el diseño de cada línea. Si la red inalámbrica se queda corta con su /24, se añade 10.60.10.0/23. Si se añaden plantas, 10.60.16.0/20 se asigna a la siguiente planta y se agregan como 10.60.0.0/16. Como los bordes de las tres áreas están alineados en límites de /22, las tres líneas de filtro tienen la misma forma en todas las plantas.

Errores frecuentes

• Poner un servidor de salto en el límite y unirlo a la infraestructura de autenticación de la oficina. Se abre una vía por la que las credenciales entran desde el lado de oficinas, y el límite pierde su sentido. Si se pone un servidor de salto, su autenticación queda cerrada dentro del límite.
• Dejar que los controladores sincronicen la hora con un servidor del lado de oficinas. En cuanto se detiene el equipo del límite, la hora del lado de control empieza a desviarse, y al investigar una avería después no se pueden cotejar los registros. La sincronización horaria se coloca en el lado de control.
• Definir el requisito de separación solo como «que no se pueda entrar desde la oficina a la red de control». El tráfico del lado de control hacia el de oficinas queda sin control, y un dispositivo colado entre los equipos conserva una vía de salida. Las reglas se fijan en ambos sentidos.
• Hacer que los servidores de intercambio se ocupen también de la recogida y del almacenamiento de archivos. Las necesidades del lado que no se puede parar impiden actualizarlos, y en pocos años nadie se atreve a tocarlos. Se separan por función y su número se mantiene dentro del /28 asignado.

Escenario

Una empresa con 10 sedes ha recibido de su operador un /48 de IPv6. Hasta ahora, en IPv4, ajustaba el tamaño de cada subred al número de dispositivos y cuidaba dónde dejar la reserva y cómo evitar la fragmentación. Está a punto de empezar a asignar IPv6 con la misma mentalidad.

Supuestos

Se ha recibido un /48 del operador. Los equipos de la empresa pueden usar la configuración automática de direcciones de IPv6. Se prevé que el número de sedes y el de usos se mantengan, cada uno, en 15 o menos. Las direcciones están pensadas para que las lean personas y extraigan su significado.

Asignación

Razonamiento

Un /48 contiene 65.536 subredes /64 en total. Buena parte de lo aprendido durante años con IPv4 se invierte aquí.

En IPv4, el tamaño de la subred se decidía por el número de dispositivos: un /28 para 10, un /24 para 200. En IPv6 no se hace así. Toda subred es una subred /64, sea cual sea el número de dispositivos. El mecanismo por el que los dispositivos eligen su propia dirección está construido dando por hecho un prefijo /64 en la subred. Si se corta por debajo de un /64, ese mecanismo deja de funcionar.

Tampoco hace falta ahorrar. Prácticamente ninguna organización agota las 65.536 subredes /64 disponibles. Los problemas que tanto costaron en IPv4, como dónde dejar la reserva o cómo evitar la fragmentación, casi desaparecen.

Queda una sola decisión: cómo dividir los 16 bits del cuarto grupo de 16 bits. Aquí se asignan 4 bits a la sede, 4 al uso y 8 a un número secuencial. Si las divisiones entre significados coinciden con los límites entre dígitos hexadecimales, una dirección se entiende con solo verla. 2001:db8:100:1200::/64, por ejemplo, es la primera subred de servidores de la sede 1.

Las divisiones se alinean con los dígitos hexadecimales. Si se divide en mitad de un dígito, cada lectura de una dirección obliga a pasarla a binario, y se pierde la ventaja de poder leerla. Si se prevé que las sedes puedan superar las 15, se asignan desde el principio 8 bits a la sede y 4 bits cada uno al uso y al número secuencial.

Margen de crecimiento

El primer dígito hexadecimal del cuarto grupo de 16 bits es la sede, numerada desde 1, y el 0 se reserva para lo común a toda la empresa. El segundo dígito es el uso y los dos últimos son el número secuencial. Las subredes son siempre subredes /64 y no se agrandan cuando aumentan los dispositivos. Las subredes /64 de la tabla de segmentos parecen grandes para su número de dispositivos porque el protocolo exige un prefijo /64, no porque se haya dejado margen. Si las sedes superan las 15, se mantienen las divisiones y se obtiene un segundo /48 del operador.

Errores frecuentes

• Dimensionar las subredes por número de dispositivos y hacerlas más pequeñas que un /64 completo. El mecanismo por el que los dispositivos eligen su propia dirección presupone un prefijo /64 y deja de funcionar. Las subredes son siempre /64 completas.
• Ajustar las subredes al máximo por preocupación por la reserva y la fragmentación, como en IPv4. Agotar 65.536 subredes /64 es prácticamente imposible, y apretar no aporta nada. Se da prioridad a la legibilidad.
• Dividir el cuarto grupo de 16 bits en mitad de un dígito hexadecimal. Cada lectura de una dirección obliga a pasarla a binario, y el significado ya no se puede leer en la dirección. Se divide en los límites entre dígitos hexadecimales.
• Numerar el dígito de sede desde 0. No queda sitio para lo común a toda la empresa, y luego hay que encajarlo a la fuerza. El 0 se reserva para lo común a toda la empresa.