Publicado en

IPv4 sin dolor: cómo diseñar tu direccionamiento para Windows Server

Windows Sever

IPv4 sin dolor: cómo diseñar tu direccionamiento para Windows Server

Si administras servidores Windows, tarde o temprano te vas a topar con un problema que no se arregla con más RAM ni con reiniciar: un mal diseño de red.
Antes de hablar de DHCP, VLANs o firewalls, necesitas una base sólida: un direccionamiento IPv4 bien pensado.

En este artículo veremos, paso a paso, cómo diseñar un plan de direcciones IPv4 para tu entorno con Windows Server, pensando en pymes y entornos on-prem o híbridos. Nada de fórmulas rebuscadas: solo lo que realmente necesitas para que tu red sea clara, escalable y fácil de administrar.

Por qué IPv4 sigue importando (aunque todos hablen de la nube)

Es cierto: cada vez usamos más servicios en la nube, y el futuro es IPv6.
Pero en la mayoría de las empresas, tu red interna sigue funcionando con IPv4, y ahí viven tus controladores de dominio, servidores de archivos, impresoras de red, cámaras, etc.

Un mal diseño de direccionamiento se traduce en:

  • Dificultad para segmentar la red (usuarios, servidores, invitados, etc.).
  • Problemas intermitentes de conectividad “misteriosos”.
  • Dolor de cabeza al crecer: más sedes, más VLANs, más equipos.

La buena noticia: con unas cuantas decisiones claras, puedes dejar tu direccionamiento IPv4 preparado para crecer sin caos.

Conceptos básicos que debes tener muy claros

Antes de diseñar tu esquema de direcciones, asegúrate de que estos conceptos están bien entendidos. No necesitas ser ingeniero de telecomunicaciones, pero sí tener claro qué significa cada cosa.

Dirección IP

Es el “número” que identifica a cada dispositivo en la red.
Un ejemplo típico de IPv4 es 192.168.10.25.

Máscara de subred

La máscara indica qué parte de la IP identifica a la red y qué parte identifica al host (equipo). Ejemplo clásico:
255.255.255.0 (también expresado como /24).

Gateway predeterminado

Es la IP del equipo (generalmente tu router o firewall perimetral) que sabe cómo sacar el tráfico fuera de tu red local (hacia otras redes o hacia Internet).

Servidor DNS

Es el servicio que traduce nombres (por ejemplo fileserver.contoso.local) a direcciones IP. En entornos con Active Directory es fundamental que los clientes apunten a los DNS internos, normalmente tus controladores de dominio.

Elegir rangos privados correctos

En redes internas se usan rangos privados (no se enrutan en Internet).
Los más comunes son:

  • 10.0.0.0/8 — enorme espacio, muy flexible.
  • 172.16.0.0/12 — tamaño intermedio.
  • 192.168.0.0/16 — el más usado en redes pequeñas.

Algunas recomendaciones prácticas:

  • Evita usar 192.168.0.0/24 o 192.168.1.0/24 si puedes, porque son los rangos típicos de routers caseros.
    Si tus usuarios se conectan con VPN o llevan equipos de casa, las coincidencias de red pueden causar problemas.
  • Piensa en el crecimiento. Si ya tienes varias sedes o planeas crecer, elegir un esquema basado en 10.x.x.x te da más flexibilidad para segmentar.
  • Mantén un patrón lógico. Si cada sede o cada “bloque” de red tiene un rango bien definido, te costará menos hacer troubleshooting.

Diseñar tu plan de direccionamiento paso a paso

Paso 1: dibuja tu mapa de red

Antes de hablar de números, dibuja (aunque sea en un papel) cómo es tu red:

  • ¿Tienes una sola sede o varias?
  • ¿Separarás usuarios, servidores, WiFi invitados, cámaras, etc. en VLANs?
  • ¿Tienes enlaces VPN entre sedes?

De este mapa saldrán las “porciones” de red que debes definir: una por VLAN, por sede o por tipo de dispositivo.

Paso 2: define bloques por sede o ámbito

Un enfoque muy cómodo para pymes es usar un esquema basado en
10.sede.red.host, donde:

  • sede identifica la sucursal o ciudad.
  • red identifica el segmento (usuarios, servidores, invitados, etc.).

Por ejemplo, para una empresa con una sola sede:

  • Usuarios: 10.10.10.0/24
  • Servidores: 10.10.20.0/24
  • WiFi invitados: 10.10.30.0/24
  • Impresoras y dispositivos: 10.10.40.0/24

Para una empresa con tres sedes, podrías usar algo así:

  • Sede 1 (Matriz): 10.1.10.0/24 usuarios, 10.1.20.0/24 servidores.
  • Sede 2: 10.2.10.0/24 usuarios, 10.2.20.0/24 servidores.
  • Sede 3: 10.3.10.0/24 usuarios, 10.3.20.0/24 servidores.

Lo importante no es el número exacto, sino la coherencia del patrón.
Cuando veas una IP como 10.3.20.15, deberías poder intuir de inmediato que es el servidor de la sede 3.

Paso 3: decide tamaños de subred (máscaras)

La máscara depende de cuántos equipos esperas en esa red.
Algunos ejemplos típicos:

  • /24 (255.255.255.0): hasta 254 hosts aprox. Bien para redes de usuarios.
  • /25 (255.255.255.128): hasta 126 hosts aprox.
  • /26 (255.255.255.192): hasta 62 hosts aprox.

No uses una subred enorme “por si acaso”. Es mejor usar varias subredes más pequeñas y segmentar por función o área. Te dará más control:
seguridad, rendimiento y troubleshooting más sencillo.

Paso 4: reserva rangos para servidores y equipos críticos

En cada subred define:

  • Rango para equipos con IP fija (servidores, firewall, impresoras).
  • Rango para clientes DHCP.

Por ejemplo, en 10.10.20.0/24 (servidores):

  • 10.10.20.1 — gateway (firewall o router).
  • 10.10.20.10 - 10.10.20.50 — controladores de dominio, servidores de archivos, etc.
  • 10.10.20.200 - 10.10.20.220 — otros equipos especiales.

En redes de usuarios, el rango DHCP podría ser, por ejemplo,
10.10.10.50 - 10.10.10.200, dejando el resto para
direcciones estáticas si las necesitas.

Buenas prácticas específicas para Windows Server

1. Controladores de dominio con IP fija y DNS interno

Asegúrate de que tus controladores de dominio:

  • Usan siempre IP fija (jamás por DHCP).
  • Tienen configurado como DNS principal otro DC interno, o a sí mismos si procede.
  • No apuntan directamente a DNS públicos (Google, ISP, etc.).

Los equipos cliente deben apuntar como DNS a tus controladores de dominio, no al router. Esto es clave para que Active Directory funcione correctamente.

2. Documenta tu direccionamiento desde el día uno

No confíes en tu memoria. Usa una hoja de cálculo, un documento en
SharePoint o una herramienta de IPAM, pero documenta:

  • Rangos de cada subred (red, máscara, gateway, DNS).
  • Dispositivos con IP fija y a quién pertenecen.
  • Fecha de alta y comentarios (servidor nuevo, equipo crítico, etc.).

3. Piensa en DHCP desde el diseño

Aunque este primer artículo se centra en el direccionamiento, el siguiente paso natural será configurar DHCP en Windows Server.
Si ya tienes claro cómo se estructura tu red y qué rangos usará cada segmento, crear scopes coherentes será mucho más fácil.

Errores comunes que deberías evitar

  • Usar el mismo rango (por ejemplo 192.168.1.0/24) en varias sedes conectadas por VPN.
  • No separar servidores, usuarios e invitados en subredes distintas.
  • Dejar IPs “fijas” sin documentar, y luego pisarlas con DHCP.
  • Permitir que el router haga de DNS principal para tus clientes de dominio.
  • No dejar espacio para crecer (subredes saturadas al poco tiempo).

Conclusión y siguientes pasos

Diseñar un buen direccionamiento IPv4 no es solo elegir “un rango que funcione”.
Es tomar decisiones que afectarán a la estabilidad, seguridad y escalabilidad de tu infraestructura durante años.

En los próximos artículos de esta serie vamos a construir sobre esta base: veremos cómo llevar este diseño a DHCP en Windows Server, cómo aplicar subneteo de forma práctica y cómo usar herramientas de diagnóstico para entender realmente qué pasa en tu red.

Si hoy mismo estás pensando en migrar servidores, añadir una nueva sede o simplemente ordenar el caos de IPs que heredaste, este es el mejor momento para rediseñar tu direccionamiento IPv4 con calma y dejarlo listo para crecer.

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.