Sincronización horaria con NTP - Cómo las redes alcanzan precisión de milisegundos

Por qué importa la sincronización horaria

Los sistemas distribuidos asumen que sus nodos comparten una visión coherente del tiempo. El análisis de logs, el orden de transacciones en bases de datos distribuidas, la validación de expiración de certificados TLS y las verificaciones de tiempo de vida de tickets Kerberos se rompen cuando los relojes se desvían más allá de su tolerancia. El coste de la desalineación es lo suficientemente alto como para que la sincronización horaria se trate como infraestructura fundamental en lugar de una consideración secundaria.

Las tolerancias concretas varían según el servicio. Kerberos rechaza la autenticación si los relojes difieren en más de 5 minutos por defecto. Los certificados TLS rechazan el uso fuera de su ventana de validez. AWS Signature Version 4 (SigV4) descarta solicitudes con marcas temporales desviadas 15 minutos o más. Estos umbrales parecen generosos hasta que un servidor deja de sincronizarse durante unas horas, momento en que cada umbral está repentinamente cerca de ser violado.

La jerarquía de NTP - El concepto de Stratum

NTP organiza la distribución del tiempo como un árbol. El Stratum 0 es una referencia física como un reloj atómico o un receptor GPS y no es directamente accesible en la red. Los servidores Stratum 1 están conectados directamente al Stratum 0; los servidores Stratum 2 se sincronizan con el Stratum 1, y así sucesivamente hasta el Stratum 15. El Stratum 16 es el valor especial que significa «no sincronizado».

Esta jerarquía permite que un pequeño número de referencias de alta precisión sirva a millones de clientes de forma eficiente. Cada cliente consulta múltiples servidores superiores y selecciona estadísticamente el resultado más fiable. El fallo de un servidor superior no rompe la sincronización, porque los clientes recurren automáticamente a alternativas. La estructura de árbol también limita la propagación de la desviación del reloj: unos segundos de desfase en el Stratum 5 no deberían propagarse peor al Stratum 6.

Compensación de ida y vuelta - La matemática central de NTP

La latencia de red es el desafío central en la sincronización remota del tiempo. NTP intercambia cuatro marcas temporales: T1 cuando el cliente envía una solicitud, T2 cuando el servidor la recibe, T3 cuando el servidor envía la respuesta, y T4 cuando el cliente la recibe. A partir de estos cuatro valores, el protocolo estima tanto el retraso de ida y vuelta como el desfase entre los relojes.

El desfase se calcula como ((T2 - T1) + (T3 - T4)) / 2, lo cual asume igual latencia en ambas direcciones. Las redes reales a menudo son asimétricas, por lo que NTP realiza muchas mediciones y aplica filtros estadísticos que descartan valores atípicos. En una LAN, la precisión submilisegundo es habitual; a través del internet público, decenas de milisegundos es lo típico y generalmente más que suficiente para las necesidades de las aplicaciones.

Implementaciones modernas - ntpd, chrony, systemd-timesyncd

El ntpd original de ntp.org tiene una larga historia y amplia compatibilidad pero un código fuente extenso y una convergencia inicial lenta. chrony, desarrollado en Red Hat, funciona mejor en dispositivos con conectividad intermitente (portátiles, máquinas virtuales) y alcanza una sincronización precisa en segundos desde el arranque. Las distribuciones Linux modernas incluyendo RHEL 8+ y Ubuntu 20.04+ incluyen chrony como cliente NTP predeterminado.

systemd-timesyncd es un cliente SNTP mínimo incluido en la mayoría de las distribuciones basadas en systemd. Proporciona sincronización solo como cliente sin funcionalidad de servidor, adecuado para escritorios y contenedores ligeros donde la simplicidad importa más que la precisión. En entornos cloud, las fuentes gestionadas por el proveedor como Amazon Time Sync Service (169.254.169.123) o los servidores NTP con «smearing» de Google eliminan el trabajo de configuración y proporcionan sincronización fiable sin ajustes adicionales.

Preocupaciones de seguridad y NTS

El NTP clásico tiene autenticación débil y es vulnerable a ataques de intermediario y amplificación DDoS por reflexión. Desplazar deliberadamente el reloj de un objetivo puede eludir las verificaciones de expiración de certificados TLS, anular la validación de tokens o reescribir marcas temporales de logs para ocultar actividad maliciosa. El tiempo en sí se convierte en una superficie de ataque, y los sistemas de alto valor tratan la integridad de NTP como un control de seguridad.

Network Time Security (NTS), estandarizado como RFC 8915 en 2020, añade autenticación basada en TLS 1.3 y verificación de integridad al NTP. chrony 4.0 y versiones posteriores soportan NTS, y time.cloudflare.com de Cloudflare es un servidor público con NTS habilitado ampliamente usado en producción. Para sistemas donde el tiempo es crítico para la seguridad, configurar NTS en lugar de NTP simple cierra una clase de ataques que se ha conocido teóricamente durante décadas pero que rara vez se ha abordado en la práctica.