Todos los cursos > Informática ( TI ) > Servidores Web y Redes ::

Servicios de red esenciales para servidores: DHCP, NTP y directorio

Capítulo 8

Tiempo estimado de lectura: 9 minutos

DHCP: asignación automática de red

Qué resuelve

DHCP evita la configuración manual de parámetros de red en cada equipo. En una infraestructura de servidores, reduce errores (IP duplicadas, gateway incorrecto, DNS mal configurado) y permite cambios centralizados: si cambias el DNS corporativo o la puerta de enlace, lo actualizas en el servidor DHCP y los clientes lo reciben al renovar su concesión (lease).

Cómo funciona

DHCP opera típicamente sobre UDP y se basa en un intercambio de mensajes entre cliente y servidor. El flujo más común es:

Discover: el cliente busca un servidor DHCP.
Offer: el servidor ofrece una IP y parámetros.
Request: el cliente solicita esa oferta.
Ack: el servidor confirma y entrega la concesión (lease).

Conceptos clave que debes dominar en servidores:

Scope/Pool: rango de IPs que el servidor puede asignar.
Lease: tiempo durante el cual el cliente “posee” la IP. Antes de expirar, el cliente intenta renovar.
Reservas: asignación fija basada en MAC (útil para impresoras, equipos de gestión, servidores que deben mantener IP estable sin configurar estático).
Opciones DHCP: parámetros adicionales. Las más críticas en operación diaria son router/gateway, DNS servers, domain search (sufijo de búsqueda), y en algunos entornos NTP servers.
DHCP Relay: cuando el servidor DHCP está en otra red/VLAN, un relay (normalmente en el router o switch L3) reenvía las solicitudes. Sin relay, el broadcast del cliente no cruza redes.

Guía práctica paso a paso (puesta en marcha mínima)

Define el pool: elige un rango que no se solape con IPs estáticas (por ejemplo, deja un bloque para servidores/infra).
Configura el lease: en redes estables, un lease más largo reduce tráfico; en redes con alta rotación (laboratorios, Wi-Fi invitados), un lease más corto evita agotamiento de IPs.
Configura opciones esenciales: gateway, DNS, sufijo de búsqueda; opcionalmente NTP.
Configura reservas para equipos que deben mantener IP constante sin estático.
Si hay múltiples VLANs, valida el DHCP relay en el equipo de capa 3 (y que apunte al servidor correcto).
Documenta: pool, exclusiones, reservas, opciones y ubicación del relay. Esto acelera el diagnóstico.

Qué revisar cuando falla

Síntomas típicos y su lectura:

Cliente sin IP (queda en “configurando red” o toma una IP automática local): suele indicar que no llega a un servidor DHCP o que el pool está agotado.
Cliente con IP pero sin salida: a menudo es opción de gateway incorrecta o falta de ruta en la red.
Cliente con IP pero no resuelve nombres: opciones de DNS incorrectas, o el cliente no recibió/renovó opciones.
Intermitencia: leases muy cortos, conflictos de IP, o dos servidores DHCP respondiendo en la misma red (rogue DHCP).

Checklist de diagnóstico:

Continúa en nuestra aplicación.

Escuche el audio con la pantalla apagada.
Obtenga un certificado al finalizar.
¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Pool agotado: revisa cuántas concesiones activas hay y si el rango es suficiente.
Relé DHCP: confirma que existe en la VLAN/red del cliente y que apunta a la IP correcta del servidor.
Firewall/ACL: verifica que el tráfico DHCP no esté bloqueado entre relay y servidor.
Rogue DHCP: si los clientes reciben gateway/DNS “raros”, busca otro servidor DHCP no autorizado.
Conflictos de IP: IPs estáticas dentro del pool o reservas mal definidas.

Pruebas rápidas

En un cliente Linux:

# Ver IP y parámetros recibidos (incluye gateway/DNS según el sistema) ip addr show ip route show cat /etc/resolv.conf  # Renovar DHCP (según distro/gestor) sudo dhclient -r sudo dhclient -v

En un cliente Windows:

ipconfig /all ipconfig /release ipconfig /renew

Prueba de “sanidad” del lado servidor (ideas generales):

Revisa concesiones activas y eventos de asignación/errores en logs del servicio.
Confirma que las opciones entregadas coinciden con lo esperado (gateway/DNS/sufijo).

NTP: sincronización de tiempo para estabilidad y seguridad

Qué resuelve

NTP mantiene la hora consistente entre servidores, equipos de red y clientes. Esto no es un “detalle”: una hora desfasada rompe o degrada servicios críticos. Tres impactos típicos en administración de servidores:

Certificados y TLS: si el reloj está adelantado/atrasado, los certificados pueden aparecer como “aún no válidos” o “expirados”.
Logs y auditoría: correlacionar eventos entre sistemas se vuelve confuso; investigar incidentes se complica.
Autenticación: mecanismos como Kerberos dependen fuertemente de la sincronización; un desfase puede impedir inicios de sesión.

Cómo funciona

NTP sincroniza el reloj consultando una o varias fuentes de tiempo. En infraestructuras, es común un diseño jerárquico:

Servidores NTP internos (para clientes y servidores): centralizan la sincronización y reducen dependencia externa.
Fuentes upstream: pueden ser servidores externos confiables o un reloj de referencia interno (según políticas).

Buenas prácticas operativas:

Redundancia: configura más de una fuente para evitar “single point of failure”.
Consistencia: todos los sistemas deben apuntar al mismo conjunto de servidores NTP internos.
Control de acceso: limita quién puede consultar/usar tu NTP si aplica a tu entorno.

Guía práctica paso a paso (puesta en marcha mínima)

Define servidores NTP internos: al menos dos, idealmente en hosts confiables y estables.
Configura upstream en esos NTP internos (múltiples fuentes).
Apunta clientes y servidores a los NTP internos (por política de configuración o automatización).
Valida deriva y estado: confirma que el servicio está sincronizado y que el desfase es pequeño.
Si usas directorio/autenticación, prioriza que controladores/servidores de autenticación estén perfectamente sincronizados.

Qué revisar cuando falla

Síntomas típicos:

Errores de certificado en navegadores, APIs o agentes: “not yet valid”, “expired” inesperado.
Logs con timestamps incoherentes: eventos “en el futuro” o saltos grandes de tiempo.
Fallos de login (especialmente en dominios/SSO): mensajes de “clock skew” o autenticación rechazada.

Checklist de diagnóstico:

Conectividad: el cliente llega a los servidores NTP (rutas, ACL/firewall).
Servicio activo: demonio NTP/servicio de tiempo corriendo en servidor y cliente.
Fuente válida: el servidor NTP interno está sincronizado con upstream (no “free-running” sin referencia).
Desfase extremo: si el reloj está muy mal, algunos clientes no “ajustan” suavemente y requieren corrección inicial.
Virtualización: revisa si hay conflictos entre sincronización del hipervisor y NTP del guest (doble corrección).

Pruebas rápidas

En Linux (según servicio):

# Estado general (systemd-timesyncd/chrony) timedatectl  # Chrony (muy común en servidores) chronyc tracking chronyc sources -v  # ntpd clásico (si aplica) ntpq -p

Señales rápidas a observar:

Offset pequeño y estable.
Fuentes alcanzables y seleccionadas.
Stratum razonable (no es “mejor” por sí mismo, pero valores extremos pueden indicar mala referencia).

Directorio y autenticación: LDAP y Kerberos como dependencias de red

Qué resuelve

Los servicios de directorio y autenticación centralizan identidades, grupos y políticas de acceso. En lugar de gestionar usuarios localmente en cada servidor, un directorio permite:

Inicio de sesión centralizado (SSO o credenciales unificadas).
Autorización basada en grupos (quién puede acceder a qué).
Inventario de identidades (usuarios, equipos, servicios).

Dos piezas típicas:

LDAP: directorio para consultar objetos (usuarios, grupos, atributos). Muchas aplicaciones lo usan para “buscar” y validar credenciales (directamente o vía un servicio intermedio).
Kerberos: autenticación basada en tickets; reduce envío repetido de contraseñas y habilita SSO. Es muy sensible a la hora.

Cómo funciona (en términos operativos)

Piensa en dependencias encadenadas. Un login “centralizado” suele requerir:

Resolución de nombres correcta hacia los servidores de directorio/autenticación.
Conectividad a puertos del servicio (LDAP/LDAPS, Kerberos, y a veces servicios auxiliares).
Hora sincronizada (crítico para Kerberos).
Certificados si usas LDAP sobre TLS (LDAPS) o StartTLS.

En la práctica, cuando un usuario intenta autenticarse en un servidor o aplicación:

La aplicación/host localiza el servidor de directorio/autenticación (por nombre).
Establece conexión a los servicios necesarios.
Valida credenciales (LDAP bind o flujo Kerberos) y luego consulta grupos/atributos para autorizar.

Guía práctica paso a paso (validación de dependencias antes de integrar)

Verifica hora en el servidor que integrará autenticación: confirma sincronización NTP estable.
Verifica resolución de los nombres del/los servidores de directorio y, si aplica, del dominio/realm.
Verifica conectividad a los puertos requeridos desde el servidor hacia los controladores/servidores LDAP/Kerberos.
Valida TLS si usarás LDAPS/StartTLS: cadena de confianza, CN/SAN del certificado y fechas válidas (otra vez: hora).
Prueba consultas LDAP con una cuenta de lectura (si aplica) antes de tocar la aplicación.
Prueba obtención de ticket Kerberos (si aplica) para confirmar que el realm y KDC responden y que no hay skew de tiempo.

Qué revisar cuando falla

Síntomas típicos y causas frecuentes:

Fallos de login “de repente” tras cambios: a menudo es hora desfasada (NTP caído) o expiración/rotación de certificados.
“No se puede contactar al servidor”: problema de resolución de nombres o conectividad/puertos bloqueados.
Login funciona pero autorización no (no aplica grupos): búsquedas LDAP fallan, base DN incorrecta, filtros equivocados o permisos insuficientes de la cuenta de consulta.
Errores TLS al usar LDAPS: CA no confiable, hostname no coincide, certificado expirado o reloj incorrecto.
Kerberos: “clock skew too great”: desfase de tiempo entre cliente y KDC.

Checklist de diagnóstico (orden recomendado):

Hora: confirma sincronización en cliente/servidor y en el servidor de autenticación.
Nombre: confirma que el host resuelve el FQDN correcto del servidor LDAP/KDC.
Red: prueba conectividad a puertos (si falla, revisa firewall/ACL/rutas).
Credenciales y permisos: cuenta de bind/servicio, expiración, bloqueo, permisos para leer atributos/grupos.
TLS: valida cadena de certificados y fechas.

Pruebas rápidas

Pruebas de conectividad a puertos (útiles para distinguir “red” vs “aplicación”):

# Linux: probar que el puerto responde (ejemplos) nc -vz ldap.ejemplo.local 389 nc -vz ldap.ejemplo.local 636 nc -vz kdc.ejemplo.local 88

Pruebas LDAP (si tienes herramientas instaladas):

# Consulta simple (ajusta DN/base/host) ldapsearch -H ldap://ldap.ejemplo.local:389 -D "cn=lector,dc=ejemplo,dc=local" -W -b "dc=ejemplo,dc=local" "(uid=usuario)" dn

Pruebas Kerberos (si aplica):

# Obtener ticket y listar caché kinit usuario@EJEMPLO.LOCAL klist

Lectura de síntomas para acelerar el diagnóstico:

Si falla nc al puerto: es red/ACL/firewall/ruta.
Si el puerto responde pero falla LDAP: revisa DN, credenciales, permisos, TLS.
Si Kerberos falla con skew: revisa NTP antes que cualquier otra cosa.

Ahora responde el ejercicio sobre el contenido:

En un entorno con varias VLANs, un cliente no obtiene IP por DHCP porque su solicitud broadcast no cruza redes. ¿Qué componente permite reenviar esas solicitudes hacia un servidor DHCP ubicado en otra red/VLAN?

¡Tienes razón! Felicitaciones, ahora pasa a la página siguiente.

¡Tú error! Inténtalo de nuevo.

El broadcast DHCP del cliente no cruza entre redes/VLANs. Un DHCP Relay, normalmente en un router o switch L3, reenvía esas solicitudes al servidor DHCP en otra red.