Introducción a NTP con chrony

per Victor Carceler — darrera modificació 2024-07-12T13:02:57+01:00

Para el buen funcionamiento de la red y de diferentes aplicaciones es muy importante que los equipos tengan sus relojes en hora. El protocolo NTP (Network Time Protocol) permite sincronizar la hora de los equipos en red con buena precisión y de manera automática.

Este protocolo fue diseñado por David L. Mills y se utiliza en Internet desde 1985. Este protocolo utiliza UDP como transporte y tiene asignado el puerto 123. En la actualidad se utiliza la versión NTP v4 descrita en el RFC 5905.

Hay dos variantes del protocolo NTP:

  • SNTP (Simple Network Time Protocol) una variante reducida que se suele utilizar en equipos de red como switches o impresoras. Un cliente SNTP puede sincronizar su reloj utilizando un servidor NTP.
  • NTS (Network Time Security) es la versión segura de NTPv4.
Внимание!

Documentación de chrony:
https://chrony.tuxfamily.org/documentation.html

Contenidos:
  1. Funcionamiento de NTP
  2. Sincronización horaria puntual
    1. Un servidor NTP moderno: chrony
      1. Configuración por defecto de chrony
      2. Control de acceso
      3. El programa de la línea de comandos chronyc
    2. Servidores NTP oficiales
    3. NTS, la versión segura de NTP

    Funcionamiento de NTP

    El protocolo NTP se basa en una jerarquía de ordenadores que a partir de una referencia horaria dan la hora a otros equipos.

    Las capas de esta jerarquía se llaman stratum y su nivel, indicado por un número, se interpreta como la distancia a la referencia horaria.

    Los dispositivos que actúan como referencia horaria son el stratum 0 y no ejecutan NTP.Así los dispositivos que se utilizan como referencia horaria (relojes atómicos, receptores de un sistema de posicionamiento global o radio relojes) forman el stratum 0. A estos dispositivos se encuentran conectados ordenadores que forman el stratum 1 y ejecutan NTP para dar la hora a otros equipos.

    Los equipos que ejecutan NTP y obtienen la hora de un stratum 1 serán stratum 2 y así sucesivamente.

    En Internet existen muchos servidores NTP públicos. Por ejemplo el proyecto pool.ntp.org ofrece muchos servidores NTP agrupados por áreas geográficas.

    Cuando se configura un servidor NTP es importante indicar varias fuentes para que se pueda contrastar la calidad de la información recibida.

    El protocolo NTP transmite la información sobre la hora UTC y cada equipo, dependiendo de la zona horaria que tenga configurada, mostrará la hora local al usuario.

    Sincronización horaria puntual

    Un host puede sincronizar su reloj de manera puntual a partir de un servidor NTP ejecutanto un cliente NTP como sntp, el antiguo ntpdateprogramado por el mismo David L. Millls o systemd-timesyncd, el cliente SNTP de systemd, que es la opción más utilizada hoy en día en GNU/Linux.

    Esto permite que el equipo ponga en hora su reloj pero no permite dar la hora a otros equipos, además para evitar la deriva del reloj local será necesario volver a sincronizar el reloj cada cierto tiempo.

    Precisamente así funciona systemd-timesyncd que intenta sincronizar la hora periódicamente siempre que haya una conexión de red disponible. En este caso se utiliza SNTP que es una versión reducida de NTP.

    Se puede comprobar el estado del equipo con el comando timedatectl

    usuario@energia:~$ timedatectl 
               Local time: sáb 2022-10-15 11:50:05 CEST
           Universal time: sáb 2022-10-15 09:50:05 UTC
                 RTC time: sáb 2022-10-15 09:50:05
                Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
usuario@energia:~$

    Y el estado de la sincronización con el comando timedatectl timesync-status

    usuario@energia:~$ timedatectl timesync-status
       Server: 185.125.190.57 (ntp.ubuntu.com)
Poll interval: 8min 32s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: 30869A3E
    Precision: 1us (-25)
Root distance: 967us (max: 5s)
       Offset: -17.344ms
        Delay: 44.302ms
       Jitter: 7.859ms
 Packet count: 5
    Frequency: +0,866ppm
usuario@energia:~$

    El fichero de configuración, /etc/systemd/timesyncd.conf, contiene comentarios con los valores por defecto.

    #  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the timesyncd.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=ntp.ubuntu.com
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

    Si se desea cambiar estos parámetros (por ejemplo para indicar nuestra lista de servidores NTP) podremos crear un fragmento de configuración como /etc/systemd/timesyncd.conf.d/ntp.conf para redefinir cualquier valor.

    Por ejemplo:

    [Time]
    NTP=192.168.0.10 minuto.roa.es time1.esa.int

    Resulta conveniente observar que systemd-networkd procesa adecuadamente la lista de servidores NTP recibidos con la concesión DHCP pero que NetworkManager no lo hace.

    Un servidor NTP moderno: chrony

    Ejecutar un servidor NTP hará que el host participe en la jerarquía de stratums NTP manteniendo sincronizado de manera permanente el reloj del equipo. Además abre la posibilidad a que nuestro equipo proporcione la hora a otros.

    El servidor NTP chrony implementa NTPv4 y está pensado para funcionar bien en todo tipo de condiciones, incluso cuando se ejecuta en equipos que tienen una conexión de red intermitente o en máquinas virtuales.

    Según nos indica su página web —https://chrony.tuxfamily.org/— permite sincronizar los relojes con muy buena precisión:

    • Unos ms en Internet
    • Decenas de µs en una LAN

    Cuando se instala el paquete chrony se obtiene tanto el demonio chronyd como la herramienta chronyc que permite monitorizar y controlar el funcionamiento del demonio.

    Configuración por defecto de chrony

    Una vez instalado se puede encontrar el fichero de configuración en /etc/chrony/chrony.conf.  En Ubuntu 24.04 este fichero incluye varios servidores NTP con los que sincronizar pero no permite el acceso a clientes.

    En la configuración por defecto se encuentran estas fuentes:

    pool ntp.ubuntu.com        iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2

    La directiva pool se utiliza con nombres de dominio que se resuelven a un conjunto de direcciones IP.

    Así, por ejemplo, se puede comprobar que ntp.ubuntu.com se resuelve a 8 direcciones diferentes (5 IPv4 y 3 IPv6)

    usuario@energia:~$ host ntp.ubuntu.com
ntp.ubuntu.com has address 91.189.94.4
ntp.ubuntu.com has address 185.125.190.57
ntp.ubuntu.com has address 185.125.190.58
ntp.ubuntu.com has address 91.189.91.157
ntp.ubuntu.com has address 185.125.190.56
ntp.ubuntu.com has IPv6 address 2620:2d:4000:1::41
ntp.ubuntu.com has IPv6 address 2620:2d:4000:1::3f
ntp.ubuntu.com has IPv6 address 2620:2d:4000:1::40
usuario@energia:~$

    De estas direcciones, gracias al parámetro maxsources, solo se tomarán 4. El parámetro iburst indica que inicialmente se puede enviar una ráfaga de solicitudes para acelerar el proceso de sincronización.

    Las fuentes se pueden indicar con tres directivas: pool, server y peer.

    • La directiva pool se utiliza con nombres de dominios que se resuelven a varias direcciones.
    • La directiva server se indica para indicar el nombre o dirección de un servidor NTP.
    • La directiva peer se utiliza para establecer una relación mutua entre dos equipos de manera que cada uno es servidor y cliente del otro.

    Control de acceso

    Se puede permitir el acceso a los clientes utilizando la directiva allow. Esta directiva permite especificar una dirección IP, una subred o un prefijo (parte de una dirección).

    Por ejemplo, para permitir el acceso a la subred 192.168.100.0/24 se podría utilizar

    allow 192.168.100.0/24

    Cuando se utiliza allow sin especificar ninguna dirección (o prefijo) se entiende que se permite el acceso desde cualquier dirección IP.

    La directiva deny funciona de manera análoga pero en este caso se deniega el acceso.

    El programa de la línea de comandos chronyc

    En la línea de comandos se podrá utilizar el programa chronyc para obtener información sobre el funcionamiento de chronyd.

    Por ejemplo, para consultar las fuentes se podrá utilizar el comando chronyc sources

    usuario@energia:~$ chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^+ prod-ntp-4.ntp4.ps5.cano>     2   8   377   236  +7785us[+8016us] +/-   35ms
^* prod-ntp-5.ntp1.ps5.cano>     2   8   377   104  -1495us[-1252us] +/-   17ms
^- pugot.canonical.com           2   8   377   168  -1937us[-1700us] +/-   55ms
^+ prod-ntp-3.ntp1.ps5.cano>     2   8   377   236  -3235us[-3005us] +/-   18ms
^+ pingless.com                  2   8   377    44   -709us[ -709us] +/-   18ms
^+ ntp69.kashra-server.com       2   8   377   106  -1325us[-1082us] +/-   33ms
^? time.cloudflare.com           0   9     0     -     +0ns[   +0ns] +/-    0ns
^? 2a05:f480:2400:1b10::123      0   9     0     -     +0ns[   +0ns] +/-    0ns
^? 190.pool90-165-120.dynam>     0   9     0     -     +0ns[   +0ns] +/-    0ns
^? 2600:1f14:d4f:fb01:3ab9:>     0   9     0     -     +0ns[   +0ns] +/-    0ns
usuario@energia:~$

    La fuente escogida para la sincronización es la que tiene un *.

    Si se ha permitido el acceso a los clientes se podrá utilizar chronyc clients para obtener un listado de clientes de nuestro servidor.

    root@energia:/home/usuario# chronyc clients
Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
===============================================================================
192.168.1.170                   2      0   5   -    28       0      0   -     -
localhost                       0      0   -   -     -       1      0   -     8
root@energia:/home/usuario#

    Servidores NTP oficiales

    Medir el tiempo (o cualquier otra magnitud) con precisión es un asunto serio. La metrología es un campo muy amplio pero no es el único aspecto que tiene que ver con la hora en la que vivimos, también hay regulaciones sobre la hora oficial. Y muchos países tienen su propio organismo para mantener la referencia horaria que se utiliza como hora legal en su territorio.

    Por ejemplo, en España, el Real Instituto y Observatorio de la Armada mantiene la hora ROA que es la hora oficial en el país.

    Estas instituciones ofrecen una referencia horaria de gran calidad y son la mejor opción para configurar el servidor NTP, o NTS, de nuestra organización.

    Algunos de los servicios oficiales son:

    País Organización Servidor Protocolo
    Alemania PTB ptbtime1.ptb.de NTP/NTS
    España Real Instituto y Observatorio de la Armada minuto.roa.es NTP
    España Real Instituto y Observatorio de la Armada nts1.roa.es NTS
    Finlandia VTT MIKES time1.mikes.fi NTP
    Francia Observatoire de Paris ntp.obspm.fr NTP
    Internacional Agencia Espacial Europea time1.esa.int NTP
    Rusia VNIIFTRI ntp1.vniiftri.ru NTP
    Suecia Netnod sth1-ts.nts.netnod.se NTP/NTS

    NTS, la versión segura de NTP

    Cualquier protocolo que se utilice en la red acaba siendo víctima de ataques. NTS es la versión segura de NTP que amplía el protocolo con un intercambio automático de claves y autenticación de los mensajes entre el cliente y el servidor para evitar ataques Man-in-the-Middle.

    La versión 3 de NTP ya introdujo un método de autenticación utilizando claves simétricas con el mismo propósito. Pero tener que distribuir claves (una diferente por cliente) hace que este mecanismo sea poco práctico más allá de organizaciones con un mismo administrador o colaboraciones puntuales en las que el administrador de un servidor proporciona una clave para un cliente.

    NTS resuelve el problema del intercambio de claves simétricas permitiendo que los clientes y servidores intercambien claves de manera automática. Su especificación es el RFC 8915 y utiliza NTS-KE sobre TLS para intercambiar las claves (una para el servidor y otra para el cliente). Después los equipos utilizan NTP, con una extensión que permite la autenticación de los mensajes, para sincronizar los relojes.

    El artículo What is Network Time Security and Why is it Important? explica el funcionamiento de NTS con más detalle.

    Afortunadamente chrony soporta NTS y no hay ningún problema en combinar fuentes NTP y NTS en el mismo fichero de configuración. Aunque cuando se hace esto el algoritmo de selección de fuentes prioriza las fuentes NTS.

    Por ejemplo, en estos momentos, el fichero /etc/chrony/chrony.confdel gateway de nuestro centro incluye las siguientes fuentes:

    server nts1.roa.es		nts iburst
    server minuto.roa.es        	iburst
    server ntp.obspm.fr         	iburst
    server time.esa.int         	iburst
    server ntp1.vniiftri.ru     	iburst
    server time1.mikes.fi	    	iburst
    server ptbtime1.ptb.de	    	nts iburst
    server sth1.nts.netnod.se	nts iburst
    server sth2.nts.netnod.se 	nts iburst

    Utilizamos 4 fuentes NTS de 3 organizaciones diferentes. Y, como se puede ver en la siguiente salida, las 5 fuentes NTP no se toman en consideración para la sincronización del tiempo.

    root@cirdan-2204:/etc/chrony# chronyc -N sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^+ nts1.roa.es                   1  10   373   606  +1160us[+1146us] +/-   40ms
^? minuto.roa.es                 1  10   377   558  +1107us[+1093us] +/-   36ms
^? ntp.obspm.fr                  2  10   377    47   +781us[ +767us] +/-   68ms
^? time.esa.int                  1  10   377   23m  +2231us[+2334us] +/-   18ms
^? ntp1.vniiftri.ru              1  10    57   29m  -2345us[-2244us] +/-   36ms
^? time1.mikes.fi                2  10   377  1054  +1431us[+1416us] +/-   29ms
^* ptbtime1.ptb.de               1  10   377    28   +835us[ +821us] +/-   16ms
^+ sth1.nts.netnod.se            1  10   377   485   -104us[ -118us] +/-   25ms
^+ sth2.nts.netnod.se            1  10   377    95    +10us[-2964ns] +/-   24ms
root@cirdan-2204:/etc/chrony#

    Más información: