Точное время — не косметика. Рассинхронизация ломает TLS-сессии, порядок событий в журналах, Kerberos, репликацию баз данных и проверку резервных копий. В Linux за синхронизацию чаще всего отвечает chrony: он быстро сходится после загрузки, устойчив к нестабильным каналам и умеет одновременно быть клиентом и сервером для локальной сети. Разберём проверку, настройку и диагностику.
Кто уже управляет временем
В Fedora и RHEL chrony приходит по умолчанию, а в Debian и Ubuntu его часто нужно установить: в минимальных образах работает systemd-timesyncd. Два демона одновременно не нужны, они конфликтуют за системные часы. Сначала выясните, что запущено.
timedatectl
systemctl status chrony --no-pager
systemctl status systemd-timesyncd --no-pager
ss -lunp | grep ':123'Строка NTP service: active и System clock synchronized: yes означают, что синхронизация работает. Если активен systemd-timesyncd, его отключают перед установкой chrony. Порт UDP 123 должен быть открыт на сервере; клиенту нужен исходящий трафик к нему.
Установка и базовая конфигурация
В Debian и Ubuntu конфигурация лежит в /etc/chrony/chrony.conf, в RHEL и Fedora — в /etc/chrony.conf. Не копируйте чужие файлы целиком: набор директив зависит от дистрибутива. Для клиента достаточно нескольких строк, которые задают источники, файл дрейфа и поведение при большом отклонении.
sudo systemctl disable --now systemd-timesyncd
sudo apt install chrony
sudo systemctl enable --now chrony
chronyc trackingРабочий пример для клиента с выходом в интернет:
pool pool.ntp.org iburst maxsources 4
driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsync
logdir /var/log/chronyiburst ускоряет первые измерения, maxsources ограничивает число серверов из пула. makestep 1.0 3 разрешает шаг, если смещение больше секунды, но только в первых трёх обновлениях: дальше время будет плавно подстраиваться. rtcsync периодически переносит системное время в аппаратные часы. В виртуальной машине синхронизацию с гипервизором лучше отключить, иначе два механизма начнут бороться за один счётчик.
Чтение chronyc tracking
Команда chronyc tracking показывает текущее состояние выбранного источника. Поле Reference ID — сервер, Stratum — удалённость от первичных часов, System time — смещение системных часов. Last offset и RMS offset полезны для оценки стабильности: первый показывает последнее измерение, второй — среднюю ошибку.
chronyc tracking
chronyc sources -v
chronyc sourcestats -v
chronyc activityВ выводе sources -v статус источника обозначается символом:
*— выбранный источник;+— пригодный для объединения;-— исключённый;?— недоступный.
Колонки Reach и LastRx показывают, доходят ли ответы. Если у всех источников Reach равен нулю, проблема в сети или фаерволе, а не в самом chrony. Frequency измеряется в ppm: большое значение после долгой работы говорит о проблемах с кварцем или виртуализацией.
chrony как локальный сервер
В офисной сети достаточно одного хоста с доступом к внешним источникам, который раздаёт время остальным. Это снижает нагрузку на внешние пулы и работает, даже если интернет пропал. Серверу нужны allow для своей подсети и local на случай потери внешней синхронизации.
allow 192.168.10.0/24
local stratum 10
bindaddress 192.168.10.1
logdir /var/log/chronylocal stratum 10 заставляет сервер объявлять себя источником десятого уровня, когда нормальных источников нет. Это лучше, чем отдавать клиентам заведомо неверное время, но не заменяет настоящую синхронизацию. На клиентах пропишите server 192.168.10.1 iburst и оставьте один-два внешних источника для контроля. Откройте UDP-порт 123 только для нужной подсети:
sudo ufw allow from 192.168.10.0/24 to any port 123 proto udp
sudo ufw reload
sudo ss -lunp | grep ':123'Не открывайте NTP в интернет без необходимости. Публичный сервер без ограничений становится участником amplification-атак, а неверная конфигурация раздаёт ложное время всей сети.
Диагностика рассинхронизации
После перезапуска не ждите мгновенного результата: chrony должен накопить несколько измерений. waitsync блокируется до достижения заданной точности и удобен в скриптах и cloud-init. Если время ушло далеко, проверьте, не запрещён ли шаг, и выполните его вручную. Для глубокой проверки одного источника служит chronyc ntpdata: он показывает задержку, смещение и состояние каждого пакета.
chronyc waitsync 30 0.1
chronyc makestep
chronyc burst 4/4
chronyc ntpdata 192.168.10.1
journalctl -u chrony -n 50 --no-pagerКоманда makestep без аргументов делает шаг немедленно. burst 4/4 просит отправить серию пакетов, чтобы быстрее получить ответ от медленного сервера. Если в журнале видны NTP source is unreachable или no selectable sources, проверьте DNS, маршрут и chronyc -n sources. Для быстрой проверки одного сервера без изменения системы используется разовый режим:
sudo chronyd -Q 'server 192.168.10.1 iburst'
date -u
timedatectl show -p NTPSynchronizedВ контейнерах и на роутерах время часто «замирает» после приостановки хоста. Проверяйте System clock synchronized после каждого пробуждения, а не только при загрузке. На ноутбуках с плохим RTC помогает makestep при старте и корректная работа rtcsync.
Безопасность и NTS
Обычный NTP не защищает от подмены пакетов. В сетях, где время критично, используйте аутентификацию: chrony поддерживает симметричные ключи и Network Time Security. NTS требует поддержки на стороне сервера и доверенного сертификата, поэтому подойдёт не любой публичный источник. Для домашней сети достаточно изолировать NTP-трафик и не принимать время с неизвестных адресов.
Ограничьте доступ к файлам конфигурации и журналам, не запускайте chronyd от имени обычного пользователя и проверяйте, что allow не шире нужной подсети. После изменений всегда перезапускайте службу и смотрите chronyc tracking, а не только код возврата systemctl.
Итог
chrony решает задачу точного времени без ручных правок часов. Проверьте, кто управляет синхронизацией, настройте пул источников с iburst и makestep, научитесь читать tracking и sources. Для локальной сети добавьте allow и local stratum, закройте UDP 123 по периметру и регулярно проверяйте NTPSynchronized после перезагрузок и пробуждений.