Asegurar la consistencia NTP: configuración, problemas de stratum y corrección de deriva

Una hora precisa es un requisito básico en las infraestructuras de TI: los tokens de autenticación caducan, los protocolos distribuidos requieren orden, las copias de seguridad y la replicación dependen de marcas temporales coherentes. En este artículo describo de forma práctica cómo asegurar la consistencia NTP —desde la configuración correcta, pasando por problemas de Stratum, hasta la identificación y corrección del drift. El público objetivo son administradores, ingenieros de sistemas, operadores y proveedores técnicos de servicios TI; las secciones están organizadas para que incluso administradores con menos especialización puedan seguirlas con seguridad.

¿Por qué sincronizar el tiempo? Relevancia operativa en breve

Sin una base temporal fiable surgen riesgos operativos concretos: fallos en la validación de certificados, intervalos de logs inconsistentes en análisis forense, problemas con bases de datos distribuidas e series temporales incorrectas en datos de monitorización. NTP (Network Time Protocol) es el protocolo estándar para la sincronización en red. Un «Stratum» designa la capa lógica en la jerarquía de fuentes de tiempo: Stratum 0 son relojes de referencia (p. ej. GPS), Stratum 1 son servidores conectados directamente y los Strata superiores se sincronizan de forma indirecta.

Conceptos NTP que debe conocer

Antes de entrar en configuración y resolución de problemas, una breve definición de los términos relevantes:

• NTP (Network Time Protocol): protocolo para la distribución de la hora UTC a través de redes IP.
• chrony / ntpd / systemd‑timesyncd: implementaciones/daemons que proporcionan la funcionalidad NTP; chrony es robusto en entornos virtualizados y ante latencias, ntpd es la implementación clásica y establecida, systemd‑timesyncd es un cliente ligero para entornos Desktop/Server con systemd.
• Stratum: distancia lógica al reloj de referencia; un Stratum más bajo está más cerca de la referencia y es más confiable.
• Drift: desviación de frecuencia de un reloj de hardware (RTC = Real Time Clock, en la placa base) respecto a UTC; se mide en segundos por día y es corregida por el daemon NTP.
• Peer vs Server vs Pool: Server es la fuente, Peer es una relación de sincronización entre iguales, Pool referencia varios servidores públicos (p. ej. pool.ntp.org) para redundancia.

Asegurar la consistencia NTP: reglas básicas y arquitectura

El camino hacia una consistencia NTP estable está guiado por la arquitectura: necesita fuentes de tiempo confiables, redundancia, software fiable y rutas de red sin pérdida de paquetes. Reglas básicas concretas:

• Configure al menos tres fuentes de tiempo independientes por sitio, idealmente en redes/AS (Autonomous Systems) diferentes, para evitar fallos comunes.
• Para servidores en entornos de virtualización, utilice preferentemente chrony, porque compensa mejor el drift en máquinas virtuales.
• Segmente los servidores de tiempo en una jerarquía: Stratum‑1/2 internos para clientes locales; referencias externas solo como respaldo (backstop) o para comparaciones Inter‑DC.
• Asegure las rutas de red: NTP usa UDP/Port 123; firewalls, NATs y load balancers deben permitir que este tráfico pase de forma regular y fiable.

¿Por qué un mínimo de tres fuentes?

Los algoritmos para seleccionar la mejor fuente de tiempo (consenso) necesitan varios candidatos para detectar valores atípicos. Con solo dos servidores y un equipo defectuoso existe riesgo de Split‑Brain en la selección de la hora.

Causas comunes de inconsistencias NTP

En la práctica se repiten ciertos patrones de fallo. A continuación, las causas más comunes y su efecto:

• Bloqueo de firewall/ACL: UDP/123 se filtra o la inspección con estado termina el mapeo NAT, de modo que no llegan las respuestas. Consecuencia: los clientes solo ven solicitudes unidireccionales o tiempos de espera.
• Enrutamiento asimétrico: los paquetes hacia un servidor regresan por una ruta distinta, un balanceador de carga modifica la IP de origen o el puerto – falla la autenticidad y el emparejamiento de respuestas.
• Configuración errónea de Stratum: un servidor fue declarado erróneamente como Stratum‑1 (p. ej., por asignación manual) y se prefiere, aunque su referencia no sea fiable.
• Deriva del RTC de hardware: placas antiguas o relojes económicos derivan considerablemente; las máquinas virtuales comparten el reloj del host o tienen osciladores inestables.
• Tratamiento del segundo intercalar / salto temporal: distintos daemons implementan los segundos intercalares de forma diferente, lo que puede provocar breves inconsistencias.

Prüfung: Erste Diagnoseschritte (Linux und Windows)

Comience con comprobaciones sencillas: ¿está activo el servicio, qué servidores se están usando y cuál es la desviación actual?

Linux: chrony

chrony proporciona salidas de estado claras. chrony suele ser la primera opción en VMs y en redes inestables.

# Status der Quellen anzeigen
chronyc sources --verbose

# Allgemeiner Status und Abweichung
chronyc tracking

Importantes son los campos Offset (diferencia actual con la referencia en segundos) y Stratum. Un offset en el rango de milisegundos es normal; en segundos es crítico.

Linux: ntpd

# Synchronisationsquellen anzeigen
ntpq -p

# Status (Scriptfreundlich)
ntpstat || true

En ntpq -p preste atención al carácter al inicio de la línea: un asterisco (*) marca el servidor actualmente utilizado, un signo más (+) otras fuentes aceptadas. Un guion (-) indica fuentes rechazadas.

Windows

Windows usa w32time; para comprobaciones más detalladas se recomienda PowerShell.

# Anzeigen des NTP-Status
w32tm /query /status

# Konfigurierte Zeitquelle
w32tm /query /configuration

Windows muestra Offset e intervalo de sondeo; desviaciones superiores a 1 segundo son críticas en entornos de dominio, ya que Kerberos es estricto con las desviaciones temporales.

Firewall und Netzwerk: typische Stolperfallen und Prüfungen

Como categoría «Firewall» esto es especialmente relevante: NTP usa UDP/123. Firewalls con estado y NAT pueden afectar el tráfico. Compruebe:

• ¿Está permitido el tráfico saliente UDP/123 y puede el tráfico de retorno llegar a través del firewall/ACL?
• ¿Modifica un balanceador de carga la IP de origen o el puerto? NTP espera combinaciones consistentes de origen/puerto para las respuestas.
• ¿Existe Deep Packet Inspection o timeouts de sesión UDP que cierren prematuramente las sesiones NTP?

El diagnóstico de red con tcpdump/wireshark ayuda a demostrar enrutamiento asimétrico o respuestas descartadas:

# Auf dem Client: Pakete zu Server x.y.z.w beobachten
sudo tcpdump -n -i any host x.y.z.w and port 123 -vv

Busque paquetes de solicitud sin la respuesta correspondiente o mensajes ICMP de puerto inalcanzable.

Firewall‑Praxis: Regeln, NAT, Conntrack und Timeouts

En entornos productivos, con frecuencia las configuraciones de firewall o NAT son el cuello de botella. Aquí comprobaciones y reglas concretas que ayudan:

• Permita UDP/123 saliente desde subredes de clientes hacia servidores de tiempo definidos y permita el tráfico de retorno en puertos de origen dinámicos.
• Compruebe el comportamiento de NAT: un NAT/puerta de enlace que cambia el puerto de origen interrumpe la correspondencia de respuestas con solicitudes abiertas.
• Controle los timeouts de conntrack para UDP: timeouts demasiado cortos (p. ej. < 30s) pueden descartar respuestas si los intervalos de sondeo son más largos.

Ejemplo: reglas sencillas de nftables que permiten solicitudes NTP salientes y solo admiten el tráfico de retorno para sesiones establecidas:

# nftables Beispiel (IPv4)
table inet filter {
    chain output {
        type filter hook output priority 0;
        ip daddr ntp-server.example accept
        udp dport 123 accept
        # Default: REST blocken
    }

    chain input {
        type filter hook input priority 0;
        ct state established,related udp dport 123 accept
        # Weitere Regeln...
    }
}

De forma análoga con iptables (Legacy) para firewalls sin soporte de nftables:

# iptables Beispiel
iptables -A OUTPUT -p udp --dport 123 -d ntp-server.example -j ACCEPT
iptables -A INPUT -p udp --sport 123 -m conntrack --ctstate ESTABLISHED -j ACCEPT

La inspección de conntrack ayuda a verificar los timeouts en tiempo de ejecución:

# Conntrack Einträge filtern
sudo conntrack -L | grep udp | grep 123

# Sysctl: UDP conntrack Timeout (Beispiel lesen)
sysctl net.netfilter.nf_conntrack_udp_timeout

Si utiliza balanceadores de carga, asegure la persistencia de sesión (IP de origen o 5‑Tuple) o evite el LB para el tráfico NTP con rutas estáticas o excepciones NAT.

Problemas de Stratum: detección y corrección

Un Stratum incorrecto o un servidor con referencia inestable provoca que muchos clientes adopten la misma hora errónea:

• Compruebe si los servidores maestros internos están realmente vinculados a una fuente Stratum‑0/1 (p. ej. GPS, PPS). Si no lo están, deben configurarse como Stratum‑2.
• Evite reducir manualmente el valor de Stratum: eso manipula la lógica de confianza del protocolo y conlleva decisiones erróneas por parte de los clientes.

Si un servidor interno es inestable, debería:

1. Quitar temporalmente ese servidor de la lista de pool/servidores de todos los clientes.
2. Replicar el problema en un entorno de pruebas aislado para descartar errores de configuración.
3. Reemplace o repare la fuente de referencia (p. ej. antena GPS, entrada PPS serial).

Análisis de drift: hardware vs. virtualización

El drift se produce por las propiedades físicas del oscilador de cristal de una RTC o por relojes virtuales. Reglas prácticas:

• En Bare‑Metal mida el drift de la RTC e introduzca una corrección en la configuración del demonio; chrony aprende el drift de forma dinámica y almacena la tasa.
• En máquinas virtuales no se deben confiar únicamente en el reloj virtual de la máquina invitada; la sincronización con el hipervisor suele ser adecuada, pero a largo plazo chrony es más resistente.

Un ejemplo: chrony guarda los valores de drift en un archivo (p. ej. /var/lib/chrony/chrony.drift). Puede visualizar el drift actual:

# chrony zeigt Learnings und Rate an
chronyc tracking

# Drift-Datei lesen (Pfad kann variieren)
sudo cat /var/lib/chrony/chrony.drift

Valores de drift extremadamente altos indican fallos de hardware o una alimentación/variaciones de temperatura muy deficientes.

Runbook práctico: resolución de problemas paso a paso

Este runbook está pensado para un emplazamiento típico con servidores de tiempo internos y clientes.

1. Verificar la línea base: estado del servicio, offsets actuales, fuentes configuradas.
   ShellCode kopieren

   # Beispielbefehle für Linux (chrony)
   systemctl status chronyd --no-pager
   chronyc sources --verbose
   chronyc tracking

2. Comprobar la red: tcpdump desde el cliente, registros de firewall, configuración de NAT/balanceador de carga.
   ShellCode kopieren

   sudo tcpdump -n -i any host ntpserver.example.net and port 123 -vv
   # Auf Firewall prüfen: gibt es UDP/123 denies für Clients?
   # Beispiel: iptables-Logs oder zentrale Firewall-Logs

3. Comprobar estado del servidor: carga de CPU, I/O, estado GPS/PPS (si está disponible).
   ShellCode kopieren

   # GPS/PPS Tools (Beispiel für Linux mit gpsd/ppsd)
   # Status prüfen
   sudo systemctl status gpsd
   # Unter /dev/pps0 auf PPS-Signale prüfen (je nach System)

4. Comprobar el stratum: salidas de ntpq/chronyc; retirar temporalmente servidores de los clientes si el stratum es incorrecto.
5. Endurecer la configuración: ACLs RESTrictivas, autenticación (claves simétricas o Autokey, pero tenga en cuenta la complejidad) y ajustar los intervalos de sondeo.
6. Monitorización/alertas: integrar métricas de offset, stratum y reachability en su sistema de monitorización.
7. Plan de reversión: antes de realizar cambios, crear un snapshot (VM) o copia de seguridad de la configuración; si los nuevos ajustes agravan los problemas, revertir inmediatamente y proseguir con la triage.

Ejemplos de configuración y buenas prácticas

Fragmentos concretos y probados de configuración para chrony y ntpd. Ajuste rutas y servidores a su entorno.

chrony (recomendado para VMs y redes inestables)

# /etc/chrony/chrony.conf (Auszug)
# Interne zuverlässige Zeitserver
server ntp1.internal.example iburst
server ntp2.internal.example iburst
# Externe Backups
pool 2.pool.ntp.org iburst

# Drift-Datei
driftfile /var/lib/chrony/chrony.drift

# Zugriffsrechte: nur Clients aus Netz 10.0.0.0/24 erlauben
allow 10.0.0.0/24

# Log-Datei für Troubleshooting
log tracking measurements statistics
logdir /var/log/chrony

Explicación de parámetros: iburst garantiza una sincronización inicial más rápida; allow limita el acceso de clientes; driftfile almacena la tasa de deriva aprendida.

ntpd (clásico)

# /etc/ntp.conf (Auszug)
server ntp1.internal.example iburst
server ntp2.internal.example iburst
driftfile /var/lib/ntp/ntp.drift
RESTrict default ignore
RESTrict 127.0.0.1
RESTrict 10.0.0.0 mask 255.255.255.0 nomodify notrap
broadcast 10.0.0.255
logfile /var/log/ntp.log

Importante: las líneas RESTrict RESTrictivas impiden que los clientes modifiquen la configuración o introduzcan datos falsos.

Monitorización: métricas, alertas e integración

Un buen sistema de monitorización detecta la deriva gradual y las interrupciones de red de forma temprana. Puntos clave:

• Recoja offset, stratum y reachability como series temporales (p. ej., mediante chrony‑Exporter para Prometheus o con un script en node_exporter textfile).
• Configure alertas adecuadas: aviso para offset > 100 ms, crítico para > 1 s o si la reachability hacia todas las fuentes internas falla.
• Visualice las tendencias de deriva a lo largo de días; saltos repentinos indican eventos externos (Snapshots, migraciones de hosts).

Ejemplo de una regla de alerta de Prometheus (YAML):

# prometheus alert rule: NTP offset critical
groups:
- name: ntp.rules
  rules:
  - alert: NTPOffsetHigh
    expr: ntp_offset_seconds{job="chrony"} > 1
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "NTP Offset höher als 1s auf {{ $labels.instance }}"

Windows Dominio y Kerberos: atención especial

En entornos de Active Directory la precisión temporal es crítica: Kerberos a menudo acepta solo unos minutos de tolerancia. Los controladores de dominio deben usar los mismos servidores de tiempo internos y no desviarse por su cuenta hacia servidores públicos. Medidas inmediatas recomendadas ante deriva de DC:

# Auf dem DC: Zeitquelle prüfen
w32tm /query /status

# Sofortige Resynchronisation erzwingen
w32tm /resync /nowait

# Konfiguration prüfen
w32tm /query /configuration

Documente cada paso y realice los cambios primero en un RODC o en un DC de prueba antes de ajustar varios controladores de dominio.

Automatización: desplegar cambios de forma controlada

Utilice gestión de configuración para garantizar la consistencia y permitir rollbacks. Ejemplo: tarea de Ansible que distribuye la configuración de chrony y reinicia el servicio (idempotente):

- name: Deploy chrony config and RESTart
  hosts: ntp_clients
  become: yes
  tasks:
    - name: Upload chrony.conf
      copy:
        src: files/chrony.conf
        dest: /etc/chrony/chrony.conf
        owner: root
        group: root
        mode: '0644'
      notify: RESTart chrony

  handlers:
    - name: RESTart chrony
      systemd:
        name: chronyd
        state: RESTarted
        enabled: yes

Pruebe en „check mode“ y realice un Canary‑Rollout para un pequeño grupo de hosts antes de distribuir los cambios globalmente.

Seguridad: NTP autenticado y endurecimiento

El NTP autenticado reduce el riesgo de manipulación de la señal horaria. Las opciones son NTP‑symmetric keys o Autokey (más complejo). Tenga en cuenta:

• Gestión de claves: utilice herramientas de CM para la distribución segura; evite configuraciones en texto claro en repositorios no protegidos.
• RESTrinja quién puede consultar su servidor (ACLs en chrony/ntpd) para reducir el abuso.
• Audite los logs regularmente; offsets inusuales o nuevas fuentes pueden ser indicadores de manipulación.

Medidas de emergencia avanzadas

Si la referencia temporal parece perderse por completo (p. ej., todas las fuentes internas fallan), proceda de forma gradual:

1. Cambie los clientes a servidores de pool externos conocidos si las reglas de red lo permiten, pero solo como medida temporal.
2. Aísle los servidores afectados si están propagando tiempos inconsistentes.
3. Utilice stepping manual (solo de forma controlada) para corregir desviaciones muy grandes. Con chrony:
ShellCode kopieren

# Sofortiges Steppen der Zeit (vorsichtig einsetzen)
chronyc makestep

4. Compruebe las aplicaciones respecto a su tolerancia a desincronizaciones temporales (p. ej., replicación de bases de datos, tareas de renovación de certificados) y planifique, si procede, repeticiones o conciliaciones.

Lista de comprobación: consistencia NTP de un vistazo

• El servicio (chrony/ntpd) se ejecuta en todos los hosts relevantes.
• Al menos tres fuentes de tiempo independientes configuradas por sitio.
• UDP/123 está abierto para los clientes; los firewalls permiten el tráfico de retorno.
• No establecer manualmente el Stratum; deje que el Stratum lo determinen las referencias.
• Supervise los valores de drift y compruebe aumentos anormales.
• Monitorización configurada con alertas de offset.
• Plan de rollback y copias de seguridad de configuración disponibles.

Ejemplos prácticos: trampas típicas

Algunos escenarios de fallo reales que encontrará con frecuencia y cómo resolverlos:

• Problema: Los clientes muestran buena Reachability, pero el Offset sigue siendo alto.

Causa: Las firewalls permiten las solicitudes, pero bloquean paquetes de respuesta UDP grandes (fragmentación) o establecen tiempos de espera NAT demasiado cortos.

Medida: Aumentar los timeouts del firewall, comprobar la fragmentación UDP y probar NTP sobre IPv4/UDP. Alternativa: NTP sobre TCP no por defecto; en su lugar comprobar protocolos de tiempo vinculados a TLS (p. ej. Roughtime) solo cuando sea necesario.

• Problema: Los hosts de VM experimentan saltos temporales de varios segundos.

  Causa: La migración del host, las pausas de CPU o los snapshots provocan picos temporales en la hora del sistema.

  Medida: Configurar chrony (preferir Slew en lugar de Step, para una corrección más suave), comprobar los relojes del hipervisor y diseñar las marcas de tiempo a nivel de aplicación con tolerancia.

Conclusión: la infraestructura de tiempo como componente operativo estable

Garantizar la consistencia de NTP no es una tarea puntual, sino un asunto operativo: se requieren arquitectura, red, selección del daemon, monitorización y una estrategia de rollback clara. Mantenga especialmente bajo control las políticas de firewall, la configuración de stratum y las métricas de deriva — son las tres palancas con las que podrá resolver la mayoría de problemas de forma duradera. Si aplica de forma sistemática las rutas de comprobación propuestas, las reglas de firewall, las alertas de monitorización y los flujos de automatización, reducirá las inconsistencias, mejorará la estabilidad de las autenticaciones y simplificará notablemente los análisis forenses.

Para este tema también son importantes las derivas de NTP. El artículo contextualiza estos aspectos de forma comprensible y muestra qué es importante en la operativa diaria.