Введение: Почему время — это не просто цифры на часах?
Представьте себе оркестр. Если скрипка начнёт играть на долю секунды позже, а флейта — раньше, вместо симфонии получится какофония. В мире IT то же самое. Логи, синхронизация баз данных, протоколы аутентификации (вспомните Kerberos!), кластерные решения, планировщики задач — всё это буквально молится на точное время.
Один сервер «отстал» на минуту — и вы уже час ищете, почему не работают резервные копии. Два маршрутизатора показывают разное время — и вы не можете понять, какое событие в логах произошло раньше.
Именно здесь на сцену выходит NTP (Network Time Protocol), а в современных дистрибутивах Linux — его элегантная имплементация под названием Chrony.
Важно: В отличие от старого добрного ntpd, Chrony умеет работать в условиях нестабильного канала, плохо предсказуемых задержек (например, в WiFi или 4G) и значительно быстрее синхронизируется после включения.
Сегодня мы пройдём путь от «времени нет» до полностью синхронизированной инфраструктуры: вышестоящий сервер, маршрутизаторы провайдера и клиенты.
Часть 1. Где брать эталонное время? Вышестоящий NTP-сервер
В любой иерархии нужен главный. Тот, кто знает «который час» точно. В мире NTP это — стратум. Стратум 1 — это сервера, синхронизированные напрямую с атомными часами или GPS-приёмниками. Стратум 2 — получают время от стратума 1, и так далее.
По заданию наш сервер должен иметь стратум 5. Это вполне респектабельно для уровня ISP (провайдера).
Пафосная фраза для отчёта: «В качестве источника времени мы выбрали общедоступный пул ntp.msk-ix.ru — сервер Московской точки обмена трафиком, который зарекомендовал себя как надёжный и высокоточный.»
Шаг 1. Редактируем конфигурацию на ISP
Заходим на наш маршрутизатор/сервер ISP (предположим, это машина под управлением Linux с Chrony). Открываем святая святых — конфигурационный файл:
vim /etc/chrony.conf
Перед нами — белый лист (или уже с какими-то настройками). Нам нужно добавить четыре магические строки.
Шаг 2. Что пишем в /etc/chrony.conf
# Указываем вышестоящий сервер NTP.
# iburst — ускоряет начальную синхронизацию (вместо 5 минут — 5 секунд)
server ntp.msk-ix.ru iburst prefer minstratum 4
# Разрешаем всем и каждому обращаться к нашему серверу времени.
# Да, allow 0.0.0.0/0 — это очень доверчиво. В боевой среде лучше указывать подсети.
allow 0.0.0.0/0
# Указываем, что мы хотим быть сервером стратума 5.
# local stratum 10 — обычно для резерва, но мы уточним:
# Фактически наш стратум будет на 1 больше, чем у ntp.msk-ix.ru.
# Если там стратум 2-3, мы станем 3-4, но принудительно мы не пишем stratum.
# Чтобы гарантировать 5 (по заданию), можно добавить, но в реальности он будет "истинным".
# Добавим директиву, чтобы сервер работал как источник даже при потере связи:
allow 0.0.0.0/0
local stratum 5
Шаг 3. Запускаем и проверяем
Перезагружаем службу, чтобы настройки вступили в силу:
systemctl restart chronyd
Теперь — проверим, что наш сервер времени жив, здоров и доволен жизнью:
chronyc sources -v
Вы должны увидеть что-то вроде:
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp.msk-ix.ru 2 6 17 43 -12us[ -10us] +/- 15ms
А если выполнить:
chronyc tracking
То обратить внимание на строчку Stratum. Она должна показать честное число (обычно на 1 больше, чем у вышестоящего). Если вы добавили local stratum 5, то при потере связи сервер будет говорить, что он 5.
Поздравляю! Вы только что создали островок хронологической стабильности в океане цифрового хаоса.
Часть 2. Маршрутизаторы (HQ-RTR и BR-RTR) — первые клиенты
Теперь время пойдёт по сети дальше. Маршрутизаторы Cisco (или другие, в задании они похожи на Cisco-like CLI) будут выступать в роли клиентов NTP.
Здесь синтаксис лаконичен, как команда в армии.
Настраиваем HQ-RTR
Входим в режим конфигурации:
hq-rtr(config)#ntp server 172.16.1.1
Пояснение: 172.16.1.1 — это адрес нашего вышестоящего ISP-сервера. Маршрутизатор будет слать запросы именно туда.
Команда мгновенна, но чтобы настройки не пропали после перезагрузки (а они пропадут, потому что оперативная память не вечна), сохраняем конфигурацию:
hq-rtr(config)#write memory
Building configuration...
[OK]
Настраиваем BR-RTR
Всё аналогично, только адрес сервера может быть другим (в задании — 172.16.2.1 это другой интерфейс ):
br-rtr(config)#ntp server 172.16.2.1
br-rtr(config)#write memory
Проверяем на маршрутизаторах
Хотите убедиться, что время действительно синхронизируется? Выполните:
show ntp status
Или:
show ntp associations
Если всё хорошо, вы увидите что-то про synchronized, clock offset и звёздочку * рядом с сервером — это символ того, что маршрутизатор выбрал этот сервер основным.
Часть 3. Клиенты (HQ-CLI, HQ-SRV, BR-SRV) — завершаем картину
Итак, время уже есть на сервере ISP и на маршрутизаторах. Но наши рабочие станции и серверы (HQ-CLI, HQ-SRV, BR-SRV) пока живут в своём временно́м измерении. Исправляем.
Настройка HQ-CLI и HQ-SRV
Эти два товарища находятся в одной локальной сети с HQ-RTR? Скорее всего. Но по заданию они смотрят напрямую на ISP-сервер (172.16.1.1). Так надёжнее и меньше прыжков.
Заходим на каждую машину (а мы помним, что это Linux с Chrony):
vim /etc/chrony.conf
Стираем лишнее (или комментируем) и пишем:
# Указываем сервер времени ISP
server 172.16.1.1 iburst
# Можно для красоты добавить локальный fallback, но не обязательно
# local stratum 10
Что такое iburst?
Это волшебная опция, которая говорит Chrony: «Не жди вежливо, а долби сервер пакетами при старте, чтобы синхронизироваться быстрее». Вместо 10 минут — 10 секунд.
Сохраняем, выходим. Перезагружаем службу:
systemctl restart chronyd
Проверяем на HQ-CLI:
chronyc sources -v
Ожидаемый вывод:
210 Number of sources = 1
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 172.16.1.1 5 6 17 12 +23us[ +25us] +/- 12ms
И на HQ-SRV — ровно то же самое, но с чувством глубокого удовлетворения.
Настройка BR-SRV
Аналогично, но сервер времени указываем другой, потому что BR-SRV,
vim /etc/chrony.conf
Пишем:
server 172.16.2.1 iburst
Перезагружаем:
systemctl restart chronyd
Проверяем:
chronyc tracking
Обратите внимание на поле System time — оно должно быть близко к нулю (например, 0.000123 seconds fast), а Leap status — Normal.
Финальная проверка: смотрим на всю картину целиком
Вы — архитектор времени. Ваша сеть теперь синхронизирована, как швейцарские часы (ладно, как корейские электронные, но тоже неплохо).
Полезные команды для диагностики (запомните их, они спасут вас в час ночи в понедельник):
- Посмотреть все источники:
chronyc sources -v - Посмотреть статистику синхронизации:
chronyc tracking - Увидеть, кто обращается к вашему NTP-серверу:
chronyc clients - Проверить статус Chrony в системе:
systemctl status chronyd - В реальном времени следить за синхронизацией:
chronyc activity
Заключение (с долей философии)
Время — самый ценный ресурс. В IT оно ещё и самый коварный враг. Мы настроили Chrony от начала до конца: от вышестоящего сервера на ntp.msk-ix.ru до конечных клиентов HQ-SRV и BR-SRV.
Что мы узнали?
- allow 0.0.0.0/0 — опасно, но удобно для лабораторки.
- iburst — ваш друг при холодном старте.
- chronyc sources — глаза администратора.
- Маршрутизаторы тоже умеют быть клиентами NTP, не хуже крутых серверов.
- Стратум 5 — это не позор, а рабочая лошадка корпоративной сети.
Теперь ваши логи не будут врать, задачи Cron будут запускаться вовремя, а аутентификация по времени перестанет быть головной болью. Вы — повелитель времени. Ну, по крайней мере, его синхронизации.
Да пребудет с вами точное время!