6.3 La Dimensión del Tiempo (NTP)

tutorial.getReady

Comprenderás las catastróficas consecuencias de un servidor desincronizado en entornos de producción.
Diferenciarás con claridad entre el Reloj de Hardware (RTC/BIOS) y el Reloj del Sistema (Software).
Dominarás el uso de timedatectl para la gestión integral de la fecha, hora y zona horaria.
Implementarás y configurarás el protocolo NTP utilizando chrony, el estándar moderno para la sincronización de alta precisión.

1. El Peligro del Tiempo: La Letalidad de la Desincronización

Para un ordenador personal, tener el reloj atrasado 5 minutos es una molestia menor. Para un servidor en producción, especialmente en entornos críticos como finanzas, salud o infraestructura, 5 minutos de desfase horario pueden ser catastróficos.

Criptografía y Autenticación Rotas (Kerberos, TLS, OAuth): Los protocolos de seguridad modernos dependen de marcas de tiempo para prevenir ataques de repetición (Replay Attacks). Si tu servidor intenta autenticarse contra un controlador de dominio (Active Directory) o una pasarela de pago y su reloj está desincronizado por más de 5 minutos, la autenticación fallará. Verás errores como “Clock skew too great”. El banco o el servicio simplemente rechazará la conexión, deteniendo transacciones y servicios críticos.
Logs y Trazabilidad Inservibles: En un ataque de seguridad o una auditoría, los logs son la única evidencia. Si el servidor web registra un ataque a las 11:00, el servidor de base de datos lo registra a las 11:02 y el firewall a las 10:58, es prácticamente imposible reconstruir la línea de tiempo del incidente. La correlación de eventos se vuelve un caos, impidiendo identificar el vector de ataque y la exfiltración de datos.
Inconsistencia en Bases de Datos Replicadas: En entornos de alta disponibilidad con replicación maestro-esclavo (como en PostgreSQL o MySQL), los identificadores de transacción o los vectores de reloj pueden basarse en timestamps. Una desincronización puede causar conflictos de escritura, corrupción lógica y fallos en la replicación.
Problemas con Sistemas de Ficheros y Cachés: Herramientas como make y sistemas de caché como Redis o Varnish utilizan marcas de tiempo para determinar si un archivo o recurso ha sido modificado. Un reloj desincronizado puede causar que las compilaciones fallen o que las cachés no se invaliden correctamente, sirviendo contenido obsoleto a los usuarios.

2. Los Dos Relojes: Hardware vs. Software

Todo sistema Linux maneja dos relojes distintos, y es crucial entender su jerarquía y propósito para una administración efectiva.

Reloj de Hardware (Real Time Clock - RTC):
- Es un chip físico presente en la placa base, alimentado por una pila de botón (CR2032) que le permite mantener la hora incluso cuando el servidor está apagado o desenchufado.
- Su precisión es limitada y tiende a desviarse con el tiempo (deriva).
- El sistema operativo solo lo consulta durante el arranque para establecer una hora inicial.
Reloj del Sistema (System Clock / Software Clock):
- Es el reloj mantenido por el kernel de Linux mientras el sistema está en ejecución. Se almacena en la memoria RAM.
- Es mucho más preciso que el RTC, ya que el kernel utiliza interrupciones de temporizador de alta resolución para mantenerlo.
- Es el reloj que realmente importa para los procesos, los logs y las aplicaciones.

La relación entre ambos se gestiona con el comando hwclock:

# Ver la hora actual del reloj de hardware (BIOS)
sudo hwclock --show
# Salida esperada: 2026-06-16 12:05:34.123456+02:00

# Ver la hora del reloj del sistema (kernel)
date
# Salida esperada: Tue Jun 16 12:05:34 CEST 2026

# Sincronizar el reloj del sistema (más preciso) hacia el reloj de hardware (menos preciso)
# Esto se hace típicamente en el apagado o mediante servicios como 'systemd-timesyncd'
sudo hwclock --systohc

# Sincronizar el reloj de hardware (BIOS) hacia el reloj del sistema.
# Útil si el servidor acaba de arrancar y la hora del S.O. es incorrecta
sudo hwclock --hctosys

3. Configuración Avanzada de la Franja Horaria (Timezone)

Aunque en entornos corporativos el estándar es usar UTC para todos los servidores (evitando así problemas con cambios de hora estacionales y facilitando la correlación de logs globales), puede haber casos justificados para usar una zona horaria local (por ejemplo, servidores de aplicaciones que reportan a usuarios finales en una región específica).

La herramienta moderna y unificada para esta tarea es timedatectl.

# 1. Ver el estado completo de la configuración temporal
timedatectl status
# Muestra: Local time, Universal time (UTC), RTC time, Time zone, y si NTP está activo.

# 2. Listar todas las zonas horarias disponibles (hay más de 400)
timedatectl list-timezones
# Para filtrar, usa grep, por ejemplo:
timedatectl list-timezones | grep -i "madrid"
# Salida: Europe/Madrid

# 3. Establecer la zona horaria deseada
sudo timedatectl set-timezone Europe/Madrid

# 4. Verificar el cambio y el archivo subyacente
timedatectl status
ls -l /etc/localtime
# El comando anterior muestra que /etc/localtime es ahora un enlace simbólico al
# archivo de zona horaria correcto, por ejemplo:
# /usr/share/zoneinfo/Europe/Madrid

4. NTP: El Latido Global con `chrony`

En lugar de ajustar la hora manualmente, los servidores confían en el Network Time Protocol (NTP). Este protocolo distribuye la hora atómica coordinada a través de Internet, calculando y compensando la latencia de la red para ofrecer una precisión de milisegundos o incluso microsegundos.

El cliente NTP tradicional (ntpd) está siendo reemplazado por chrony, que ofrece ventajas clave:

Convergencia más rápida: Ajusta el tiempo de forma más agresiva al inicio.
Mejor rendimiento en redes inestables: Maneja mejor las fluctuaciones de latencia y los cortes de red.
Funciona en entornos sin conexión permanente: Puede actuar como servidor NTP para otras máquinas en una red aislada.

Instalación y Control del Servicio

# Instalación en Debian/Ubuntu
sudo apt update && sudo apt install chrony -y

# Instalación en RHEL/CentOS/Fedora
sudo dnf install chrony -y

# Habilitar e iniciar el servicio
sudo systemctl enable --now chronyd
# Verificar el estado del servicio
sudo systemctl status chronyd

Verificación de la Sincronización

El comando más importante para verificar el estado de la sincronización es chronyc:

# Ver las fuentes de tiempo a las que estamos conectados
chronyc sources -v

# Análisis de la salida:
# 210 Number of sources = 4
# .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
# / .- Source state '*' = current synced, '+' = combined, '-' = not combined, '?' = unreachable.
# | /   'x' = falseticker, '~' = overloaded.
# ||                                                    .- xxxx [ yyyy ] +/- zzzz
# MS Name/IP address         Stratum Poll Reach LastRx Last sample
# ===============================================================================
# ^* ntp1.example.com             2   6   377    41    +23us[  -12us] +/-   17ms
# ^+ ntp2.example.com             2   6   377    43    -53us[  -88us] +/-   21ms
# ^- ntp3.example.com             3   6   377    45   -134us[ -169us] +/-   34ms
# ^? ntp4.example.com             1   6     3    12   -413us[ -413us] +/-   68ms

# Interpretación:
# MS: Indica el estado de la fuente ('*' = fuente sincronizada, '+' = fuente candidata, '-' = fuente descartada, '?' = fuente inalcanzable).
# Name/IP address: El servidor NTP.
# Stratum: Distancia al reloj atómico de referencia (1 es el más cercano).
# LastRx: Tiempo desde la última recepción de paquete.
# Last sample: La diferencia de tiempo medida entre tu servidor y esa fuente.
# El hecho de ver un '*' en la columna MS y un error pequeño en el 'Last sample' (+/- unos ms) indica que tu servidor está perfectamente sincronizado.

Comprobación del estado de NTP y RTC

# Ver el estado de la sincronización NTP y del RTC
timedatectl status
# Busca las líneas:
#      System clock synchronized: yes (Indica que el sistema está sincronizado NTP)
#      NTP service: active         (El servicio chronyd está en ejecución)
#      RTC in local TZ: no         (El RTC está en UTC, que es lo recomendado)

Personalización Avanzada de `chrony`

En entornos aislados o con requisitos de seguridad, deberás apuntar a servidores NTP internos. La configuración se realiza en /etc/chrony/chrony.conf.

# Editar el archivo de configuración
sudo vim /etc/chrony/chrony.conf

# --- Dentro del archivo ---

# 1. Comentar o eliminar las directivas 'pool' o 'server' públicas por defecto.
# pool 2.debian.pool.ntp.org iburst

# 2. Añadir la directiva 'server' con la dirección de tu servidor NTP interno
# La palabra clave 'iburst' acelera la sincronización inicial.
server 10.0.0.9 iburst
server 10.0.0.10 iburst

# 3. (Opcional pero muy recomendado) Permitir que otras máquinas de la red local
# consulten la hora a este servidor si actúa como un "pequeño servidor NTP".
# Descomenta y modifica la línea de permitir:
allow 192.168.1.0/24  # Permite a la subred 192.168.1.0/24 consultar este servidor

# 4. (Opcional) Para una mayor precisión, puedes especificar el archivo de log.
# logdir /var/log/chrony

# --- Guardar el archivo y salir ---

# Después de cualquier cambio en el archivo de configuración, recargar el servicio
sudo systemctl reload chronyd
# O para un reinicio completo (menos común, ya que 'reload' aplica los cambios en caliente)
# sudo systemctl restart chronyd

Monitorización y Solución de Problemas

# Ver el estado del seguimiento de la fuente principal
chronyc tracking
# Muestra: Reference ID (el servidor NTP maestro), Stratum, Offset (diferencia actual),
#         Root delay, Root dispersion, y las frecuencias de ajuste del reloj.

# Ver un resumen de la actividad de las fuentes
chronyc activity
# Muestra cuántas fuentes están online/offline.

# Forzar una comprobación inmediata (útil para pruebas)
sudo chronyc -a makestep
# Forza al sistema a ajustar el reloj de forma brusca si la diferencia es grande.
# Chrony normalmente lo hace de forma gradual (aumentando o disminuyendo la velocidad del reloj),
# pero 'makestep' es útil para correcciones rápidas en entornos de prueba.

Comprueba tus conocimientos

Tras encender cinco nuevos servidores clonados de una plantilla antigua que ha estado apagada 2 años, notas que la base de datos de los 5 equipos arroja el timestamp del año 2022 y las conexiones con el Master fallan. Necesitas reventar y forzar instantáneamente la hora con un estándar sin depender de interfaces gráficas. Identifica el comando fundamental para decirle a la matriz de Systemd que estampe la hora local a Madrid.
1. sudo hwclock --adjust Europe/Madrid
2. La utilidad moderna para dominar la dimensión temporal sin interactuar con ficheros arcaicos es: sudo timedatectl set-timezone Europe/Madrid
3. sudo systemctl restart time
Acabas de alquilar en Hetzner (Alemania) 3 servidores desnudos para montar un cluster bancario el cual va a enviar miles de transacciones cruzadas por segundo. Tu jefe te recalca la extrema e imperativa regla de oro Sysadmin sobre cómo deben estar configurados todos los husos horarios del ecosistema para no corromper la trazabilidad en bases de datos con los cambios de verano/invierno de cada país. ¿Qué Timezone se exige usar en clústeres?
1. El pilar central innamovible: Todos los servidores se rigen y deben dejarse configurados forzosamente en UTC. Jamás sufren adelantos y atrasos gubernamentales por políticas de luz solar, lo que garantiza secuencias lógicas inquebrantables.
2. La hora local del país de la central corporativa del Banco.
3. Europe/Berlin, dado que allí reside el metal.
Tiras el comando chronyc sources -v y adviertes que te estás comunicando por defecto con el gran pool global europeo pool.ntp.org para ajustar tus milisegundos. Sin embargo, tu empresa tiene alta seguridad militar en intranet aislada y te acaban de abrir un puerto hacia su propio servidor “Satelital GPS” situado internamente en la IP 10.0.0.9. ¿Para que Chrony deje de llamar al exterior y use tu IP interna como Dios del tiempo, qué habría que manipular teóricamente?
1. Habría que purgar chrony e instalar systemd-timesyncd
2. Editaríamos /etc/fstab/chrony introduciendo la IP.
3. La configuración sagrada se edita alterando el fichero núcleo /etc/chrony/chrony.conf (o sencillamente /etc/chrony.conf en RHEL), eliminando o comentando las directivas pool vigentes para forzar y sustituirlas por: server 10.0.0.9 iburst procediendo a recargar después el demonio.