NTS и NTP over TLS в chrony: безопасная синхронизация времени на VDS

Инструкции
11 ноя, 2025
Время на чтение: ~12 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Если у вас есть облачный VDS и вы отвечаете за безопасность и наблюдаемость, точное время — это не «приятно иметь», а базовое требование. Несогласованное время ломает цепочки TLS, портит таймстемпы логов, срывает ретраи и искажает метрики. Классический NTP работает по UDP без обязательной криптографической защиты, поэтому уязвим к подмене ответов и атакам по пути следования. Решение — современные механизмы защиты: NTS (Network Time Security) и NTP over TLS. В этой статье показываю, как настроить chrony с NTS на VDS, какие порты открыть и как убедиться, что защита реально работает.

Почему NTP в «чистом виде» больше не устраивает

Исторически NTP задумывался как легковесный UDP-протокол для синхронизации времени. В корпоративных и облачных средах у него есть давние проблемы:

Отсутствие встроенной, общепринятой криптографической защиты трафика между клиентом и сервером.
Возможность атак на путь (on-path), манипуляции задержками и подменами ответов.
Риск зависимостей от публичных пулов без прозрачной политики и географии.

В результате критические сервисы (CI, базы данных, шины сообщений, e-mail MTA, прокси TLS) получают дрейф времени или скачки, а аудит и расследование инцидентов теряют опору.

NTS и NTP over TLS: в чём разница и что выбрать

Сегодня есть два ключевых подхода к защите NTP-трафика:

NTS (Network Time Security): клиент один раз устанавливает защищённую сессию NTS-KE по TLS (TCP, обычно порт 4460), получает криптографические «cookies» и ключи, далее синхронизация идёт обычным NTP по UDP/123, но каждый запрос/ответ аутентифицирован с помощью NTS-расширений. То есть NTS сочетает точность UDP и защиту от подмены.
NTP over TLS: поверх TLS инкапсулируется сам NTP-поток, обычно по TCP. Это даёт шифрование и верификацию, но добавляет накладные расходы и чувствительность к потерям (head-of-line blocking). Распространённость ниже, чем у NTS.

Практический вывод: для продакшена на VDS чаще всего выбирают NTS. Он стандартизован, поддерживается современными реализациями и сохраняет преимущества UDP.

Фрагмент конфигурации chrony с NTS на Linux

Поддержка в chrony

chrony — отличный выбор для VDS благодаря быстрой сходимости и живучести на нестабильных сетях. Актуальные версии поддерживают NTS «из коробки» при наличии системных корневых сертификатов. Важные моменты:

Нужен пакет с поддержкой TLS (обычно через GnuTLS). Проверьте chronyd -v, чтобы увидеть, с чем он собран.
Пакет ca-certificates обязателен: без доверенных корневых сертификатов NTS-KE по TLS не установится.
Откройте исходящие соединения на tcp/4460 (NTS-KE) и udp/123 (сам NTP).

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Подготовка VDS: конфликтующие службы и фаервол

На Debian/Ubuntu часто предустановлен systemd-timesyncd, который конфликтует с chrony. Его нужно отключить, иначе получите «гонку» за системные часы.

sudo systemctl disable --now systemd-timesyncd
sudo systemctl mask systemd-timesyncd

Откройте исходящие порты для NTS и NTP. Если используете nftables, явно разрешите трафик наружу на tcp dport 4460 и udp dport 123. Для UFW это может выглядеть так:

sudo ufw allow out 4460/tcp
sudo ufw allow out 123/udp

В средах с egress-фильтрацией (корпоративные VPC, строгие ACL) эти правила критичны — без них NTS не заработает.

Установка chrony

Debian/Ubuntu

sudo apt update
sudo apt install chrony ca-certificates

RHEL/AlmaLinux/Rocky

sudo dnf install chrony ca-certificates
sudo systemctl enable --now chronyd

Далее проверьте версию:

chronyd -v

Если видите упоминание TLS/NTS, всё готово к настройке.

Базовая конфигурация chrony с NTS

Файл конфигурации:

Debian/Ubuntu: /etc/chrony/chrony.conf
RHEL-подобные: /etc/chrony.conf

Пример минимальной конфигурации, заточенной под VDS с NTS:

# Хранение дрейфа частоты
Driftfile /var/lib/chrony/chrony.drift

# Для корректной обработки високосных секунд
leapsectz right/UTC

# Разрешаем шаговое исправление при старте (если разница > 1 сек) не более трёх раз
makestep 1 3

# Сохраняем NTS-данные (cookies, ключи)
antsdumpdir /var/lib/chrony

# Источники времени с NTS (примерные домены; используйте те, что реально поддерживают NTS)
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
# Добавьте 2–3 разнородных источника из разных автономных систем

# Усиливаем отказоустойчивость и качество
maxsources 4
minsamples 5
maxsamples 10
maxdistance 1.0

# Синхронизация с RTC (на некоторых VDS RTC может отсутствовать — не критично)
rtcsync

# Безопасность командного интерфейса (локально только через сокет)
cmdport 0

# Логи, полезные для отладки
logdir /var/log/chrony
log tracking measurements statistics

Пояснения к ключевым параметрам:

nts указывает chrony использовать NTS для сервера. Если удалённая сторона NTS не поддерживает, источник не будет принят.
ntsdumpdir — где хранить NTS-cookies и состояние. Убедитесь, что каталог существует и принадлежит пользователю chrony.
leapsectz right/UTC позволяет корректно проживать високосные секунды без скачков.
makestep 1 3 нужен для быстрого выхода на точность после старта/миграции.
cmdport 0 отключает UDP-команды извне; админка доступна локально через Unix-сокет, что безопаснее для VDS.

После правок перезапустите службу:

sudo systemctl restart chrony    # Debian/Ubuntu
sudo systemctl restart chronyd   # RHEL-подобные

Как проверить, что именно NTS работает

Проверяем источники и статус аутентификации:

chronyc -N -n sources -v
chronyc -N -n authdata

Сверьте текущую оценку погрешности и смещения:

chronyc tracking
chronyc sourcestats -v

Если источники долго остаются недоступны или не помечены как NTS-аутентифицированные, проверьте фаервол и наличие корневых сертификатов. Подробнее о доверенных корнях и цепочках см. в разборе по доверенным корневым сертификатам TLS в Linux.

Вывод chronyc sources и authdata с пометками NTS

Диагностика типовых проблем

Заблокирован порт 4460/tcp. NTS-KE не устанавливается, а значит нет ключей и cookies. Разрешите исходящие соединения и повторите проверку.
Отсутствует пакет корневых сертификатов. Установите ca-certificates.
Слишком старая версия chrony. Обновите пакет до версии с поддержкой NTS.
Прокси или инспекция TLS на периметре. Некоторые middlebox’ы ломают TLS-хэндшейк. Подтверждения ищите в логах journalctl -u chrony или -u chronyd.
DNS отдаёт «близкий», но сетево далёкий адрес. Добавьте альтернативные NTS-серверы из иных AS, чтобы у chrony был выбор.

Нюансы точности на VDS

Используйте 3–5 NTS-источников из разных провайдеров и географий, но не переборщите — слишком много источников усложняют консенсус.
iburst ускоряет первичную сходимость после старта.
Не зажимайте maxdistance слишком сильно — на VDS джиттер выше, чем на железе.
Следите за chronyc tracking: если Root distance растёт без причины, проверьте сеть/фаервол/потери пакетов.

NTP over TLS: когда он уместен

«NTP over TLS» — подход, где NTP идёт внутри TLS-сессии (обычно TCP). Плюсы: шифрование и проверка подлинности. Минусы: накладные расходы, чувствительность к потерям и меньшая доступность публичных серверов. В реальной эксплуатации на VDS это чаще экспериментальная опция или требование специфической инфраструктуры. Если цель — надёжная защита в открытом Интернете, NTS остаётся более практичным выбором.

Безопасность и политика обновлений

Регулярно обновляйте chrony и системные корневые сертификаты, чтобы не упереться в просроченные цепочки.
Оставляйте включёнными только нужные исходящие порты. Входящий udp/123 не требуется для клиентской роли.
Если вы раздаёте время другим хостам (VDS как NTP-сервер), ограничьте подсети через allow, не открывайте мир. Не используйте устаревшие режимы аутентификации.
Для собственного NTS-сервера нужен корректный TLS-сертификат. При необходимости оформите проверенный сертификат: доступны SSL-сертификаты.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Контроль готовности и наблюдаемость

Простейший healthcheck для init/systemd-юнитов и оркестрации:

chronyc tracking | grep -E "Reference ID|Leap status|System time"

Если Leap status «Normal», а System time стабилен, служба в норме. Для алертов смотрите на монотонный рост Last offset и Root dispersion. Подробный разбор метрик и дашбордов — в статье про мониторинг chrony и NTP на VDS.

Чек-лист внедрения

Отключите конфликтующий systemd-timesyncd.
Установите chrony и ca-certificates.
Откройте исходящие tcp/4460 и udp/123.
Пропишите 3–4 реальных NTS-источника в конфигурации.
Включите ntsdumpdir, логи и базовые ограничители (maxdistance, выборки).
Перезапустите службу, проверьте authdata, sources, tracking.
Настройте мониторинг и алерты на отклонение и потерю источников.

Итоги

NTS делает NTP снова пригодным для продакшена: вы сохраняете точность UDP и получаете защиту от подмены времени. На VDS это особенно важно: секунда-другая расхождения способна спровоцировать каскад сбоев — от сломанных TLS до проблем с кворумами в кластерах. Настройка chrony с NTS занимает считанные минуты: отключите конфликтующие службы, откройте порты, пропишите NTS-серверы, включите логи и проверьте, что аутентификация действительно работает. А «NTP over TLS» оставьте для сценариев, где он прямо необходим: повсеместной замены NTS он пока не предлагает.

Поделиться статьей