Publicado en

Subneteo aplicado: de la teoría al DHCP en Windows Server

Windows Sever

Subneteo aplicado: de la teoría al DHCP en Windows Server

Entender qué es una subred está bien; pero donde de verdad se nota si dominas el tema es cuando diseñas una red real y configuras DHCP en Windows Server.
Ahí es donde el subneteo deja de ser un ejercicio de examen y se convierte en algo que impacta directamente la estabilidad y seguridad de tu infraestructura.

En este artículo vamos a ver cómo aplicar el subneteo en un entorno típico de empresa y cómo traducir ese diseño en scopes DHCP coherentes.
La idea es que, al terminar, puedas mirar tus rangos IPv4 y decir: “esto tiene sentido y está listo para crecer”.

Por qué el subneteo sigue siendo clave en 2025

Aunque muchos servicios ya viven en la nube y el futuro apunte a IPv6, la realidad en la mayoría de las pymes y entornos híbridos es clara: tu red interna sigue siendo IPv4, con switches, VLANs, servidores Windows y montones de equipos conectados.

Un buen subneteo te ayuda a:

  • Separar usuarios, servidores, invitados y equipos especiales.
  • Reducir el impacto de fallos o ataques en una parte de la red.
  • Controlar mejor el tráfico (calidad de servicio, seguridad, VPN).
  • Evitar el clásico “se nos acabaron las IPs” en plena operación.

Recordatorio rápido: qué es subnetear

Subnetear es tomar una red IP más grande y dividirla en redes más pequeñas (subredes), cada una con su propio rango de hosts. El objetivo es organizar y segmentar mejor tu infraestructura.

Por ejemplo, si tienes la red 192.168.10.0/24, puedes dividirla en varias subredes más pequeñas usando máscaras más “estrictas” como /25, /26, etc.

A nivel práctico, lo que importa es:

  • Cuántos hosts necesitas en cada subred.
  • Cuántas subredes quieres crear.

El truco está en encontrar el equilibrio: subredes lo bastante grandes para soportar el crecimiento, pero no tan enormes que pierdan sentido desde el punto de vista de seguridad y gestión.

Ejemplo 1: partir una /24 en redes más pequeñas

Escenario base

Imagina que tienes una red 192.168.10.0/24 y quieres separarla en varias VLANs:

  • Usuarios de oficina.
  • Servidores.
  • WiFi invitados.
  • Dispositivos (impresoras, cámaras, etc.).

Una red /24 te da unos 254 hosts útiles. Puedes dividirla en cuatro subredes de tamaño similar usando /26 (aprox. 62 hosts útiles cada una).

El resultado sería algo como esto:

UsoRedRango de hostsBroadcastMáscara
Usuarios192.168.10.0192.168.10.1 – 192.168.10.62192.168.10.63255.255.255.192 (/26)
Servidores192.168.10.64192.168.10.65 – 192.168.10.126192.168.10.127255.255.255.192 (/26)
WiFi invitados192.168.10.128192.168.10.129 – 192.168.10.190192.168.10.191255.255.255.192 (/26)
Dispositivos192.168.10.192192.168.10.193 – 192.168.10.254192.168.10.255255.255.255.192 (/26)

No tienes que usar exactamente estos rangos; lo importante es el criterio:
cada tipo de dispositivo o función tiene su propia subred.

Subneteo pensando en Windows Server y Active Directory

En entornos Windows con Active Directory, el subneteo no es solo un tema de “orden bonito”. Afecta directamente a:

  • Cómo los clientes encuentran sus controladores de dominio.
  • Cóm se aplican las Directivas de Grupo (GPO) por sitio.
  • Cómo se enruta el tráfico entre sedes y servicios.

Algunas recomendaciones prácticas:

  • Separa servidores de usuarios en subredes distintas.
  • Crea una subred independiente para WiFi invitados, sin acceso a AD.
  • Considera una subred para dispositivos (impresoras, cámaras, IoT) con reglas claras de acceso.
  • No reutilices el mismo rango en dos sedes unidas por VPN: tendrás conflictos de rutas.

Si tus subredes están bien definidas, te resultará más sencillo configurar DHCP, firewalls, políticas de acceso y cualquier integración con la nube (por ejemplo, túneles hacia servicios externos).

Llevar el diseño a DHCP en Windows Server

Una vez que tienes claro tu esquema de subredes, es momento de reflejarlo en scopes DHCP en Windows Server. Cada subred debería tener su propio scope con:

  • Red y máscara correctas.
  • Gateway (router) adecuado.
  • Servidores DNS correctos (normalmente tus controladores de dominio).
  • Rango de direcciones para asignar a clientes.
  • Exclusiones y reservas bien pensadas.

Definir scopes por subred

Siguiendo el ejemplo anterior, podrías definir scopes como:

  • Scope Usuarios:
    192.168.10.0/26
    Gateway: 192.168.10.1
    DNS: controladores de dominio
    Rango DHCP: 192.168.10.10 – 192.168.10.60
    Exclusiones: 192.168.10.1 – 192.168.10.9 (equipos estáticos)
  • Scope Servidores:
    192.168.10.64/26
    Gateway: 192.168.10.65 (o la IP que asignes al router en esta subred)
    DNS: controladores de dominio
    Rango DHCP (si lo usas): un segmento pequeño, o incluso sin DHCP si todo es estático
  • Scope WiFi invitados:
    192.168.10.128/26
    Gateway: tu firewall, con reglas limitadas hacia la LAN
    DNS: los que decidas (internos, externos o filtrados)
    Rango DHCP amplio para dispositivos móviles
  • Scope Dispositivos:
    192.168.10.192/26
    Gateway: router o core de la red
    DNS: internos si necesitan resolver nombres de AD, o externos según el caso

Fíjate en que cada scope está alineado con una subred y un propósito.
Esto reduce sorpresas a largo plazo.

Rangos, exclusiones y reservas

A la hora de definir tu rango DHCP dentro de cada subred:

  • Deja un bloque inicial para IPs fijas (servidores, routers, impresoras, APs).
  • Define el rango DHCP en la parte “media” para minimizar solapamientos y uso futuro de IPs fijas.
  • Usa reservas DHCP cuando quieres controlar la IP de un equipo, pero seguir gestionándola desde DHCP (según MAC address).

Ejemplo en la subred de usuarios 192.168.10.0/26:

  • Reservado para infraestructura: 192.168.10.1 – 192.168.10.9
  • Rango DHCP: 192.168.10.10 – 192.168.10.60
  • Libre para futuras IP fijas: 192.168.10.61 – 192.168.10.62

Aunque parezca poco espacio “libre”, en la práctica suele ser suficiente
si documentas bien y no regalas IPs fijas sin motivo.

Buenas prácticas de subneteo para pymes

  • No mezcles todo en una sola red /24 solo porque “funciona”.
    Separa servidores, usuarios, invitados y dispositivos.
  • Alínea tus subredes con tu diseño lógico (sedes, VLANs, funciones).
    Así será más fácil entender la red años después.
  • Deja margen de crecimiento en cada subred.
    No crees redes al límite de hosts desde el primer día.
  • Documenta cada subred: finalidad, máscara, gateway, rango DHCP,
    exclusiones, dispositivos críticos.
  • Evita solapamientos de rangos entre sedes conectadas por VPN.
    Si ya estás atrapado en ese problema, planifica una migración ordenada.

Errores típicos que deberías evitar

  • Usar una sola red plana para toda la empresa, incluyendo servidores e invitados.
  • Crear subredes minúsculas sin margen y tener que “parchar” después.
  • No actualizar DHCP cuando cambias el diseño de VLANs.
  • Hacer cambios de máscara sin entender el impacto en rutas y gateways.
  • Dejar scopes DHCP sin documentar, con IPs fijas repartidas al azar.

Conclusión y siguiente paso

El subneteo deja de ser un tema abstracto cuando lo conectas con la realidad:
VLANs, sedes, servidores, WiFi, invitados, impresoras y cualquier otro componente
que vive en tu red.

Si diseñas subredes con intención y luego creas scopes DHCP alineados con ese
diseño, ganas control, seguridad y capacidad de crecimiento. Dejas de “apagar incendios”
con IPs sueltas y pasas a tener una infraestructura ordenada.

En el siguiente artículo de esta serie nos enfocaremos en el
diagnóstico de red con herramientas modernas
(incluyendo Test-NetConnection y otros cmdlets de PowerShell),
para que puedas validar que tus subredes y scopes funcionan como esperas.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Tiempo excedido. Por favor completa el captcha nuevamente

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.