Subredes /24, /26 y /27: aprender CIDR con ejemplos prácticos
Publicado el 2026-10-26 por frfrand
Calcular rangos IPv4 y cantidad de direcciones útiles

Una máscara /24 parece un número extraño hasta que necesitás repartir direcciones para VPS, contenedores y redes privadas. Con CIDR podés calcular subredes sin memorizar una tabla de 256 filas.
Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.
Qué significa CIDR /24 /26 /27 y cuándo lo necesitás
En IPv4, un prefijo /n indica cuántos bits identifican la red. /24 deja 8 bits para host (256 direcciones); /26 deja 6 (64 direcciones); /27 deja 5 (32 direcciones). En redes IPv4 convencionales hay direcciones reservadas para red y broadcast, por lo que las utilizables suelen ser dos menos.
Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.
Configuración o comandos de ejemplo
# Ejemplos de rangos IPv4
192.168.10.0/24 -> 192.168.10.0 ... 192.168.10.255
192.168.10.64/26 -> 192.168.10.64 ... 192.168.10.127
192.168.10.128/27 -> 192.168.10.128 ... 192.168.10.159
# En Linux: dirección y prefijo actuales
ip -4 addr show
ip -4 route show
Los dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.
Cómo lo haría paso a paso
- Preparación. Identificá el prefijo de la red, no sólo la dirección de un equipo.
- Paso 2. Calculá el tamaño del bloque como
2^(32-prefijo)para IPv4. - Paso 3. Buscá el inicio del bloque según sus fronteras: /26 avanza de 64 en el último octeto.
- Paso 4. Separá red, broadcast y direcciones asignables en subredes convencionales.
- Verificación. Comprobá las rutas y reglas de firewall antes de conectar dos segmentos.
Cuando termines, comprobá la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecutá una petición de lectura, una escritura en una base de prueba y consultá los logs del proceso.
Ejemplo de un proyecto de verdad
En una infraestructura de laboratorio tenés una red /24 y querés separar un grupo de 50 dispositivos de otro de 25. Podrías planificar una /26 y una /27, siempre que las rutas, gateways y solapamientos estén correctamente definidos.
La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.
El error que evitaría
No asumás que CIDR equivale a seguridad. Dos subredes pueden comunicarse mediante un router o firewall. Tampoco copies los ejemplos de direcciones privadas en una red que ya las tenga asignadas sin comprobar conflictos.
Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.
¿Cómo se relaciona con ArduMaker?
Al administrar varios VPS y servicios, entender CIDR ayuda a planificar acceso privado a bases y proxies. ArduMaker puede administrar los servidores, pero la segmentación debe respetar rutas y permisos.
En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.
Preguntas que aparecen cuando lo probás
¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.
¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.
¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.
Referencias
En resumen: una buena configuración de red o servidor es la que podés explicar, verificar y recuperar cuando algo falla.