Вопрос синхронизации времени требует отдельного рассмотрения, так как для работы протокола проверки подлинности Kerberos необходимо, чтобы время на клиенте и на сервере расходилось не более, чем на 5 минут.
Протокол NTP и типы серверов
Протокол NTP - (Network Time Protocol — протокол сетевого времени) - сетевой протокол для синхронизации внутренних часов компьютера с использованием сетей с переменной латентностью.
Латентность - это в данном случае задержка передачи пакета по сети (время, требующееся пакету данных, чтобы преодолеть путь от одного компьютера в сети до другого).
NTP использует иерархическую сеть, где каждый уровень имеет свой номер, называемый слой (stratum):
- Слой 1 (stratum 1) - первичные серверы, которые непосредственно синхронизируются с национальными службами времени через спутник, радио или телефонный модем. Такие сервера чаще всего получают точное время непосредственно от источника точного времени: атомных часов (например time-a.nist.gov, точность — триллионные доли секунды) или GPS приемника (ntpx.imvp.ru точность — миллиардные доли секунды). Есть сервера получающие точное время через сотовую сеть CDMA (миллионные доли секунды). Подключаться к таким серверам или запрещено (закрыта такая возможность) или крайне нежелательно.
- Слой 2 (stratum 2) - вторичные серверы, которые получают точное время от Stratum-1 серверов. При правильной настройке и выборе серверов-источников точного времени имеют погрешность менее 1 миллисекунды. Подключатся, обычно, можно всем, но многие сервера регулярно недоступны из-за очень высокой нагрузки (например time.windows.com).
- Слой 3 (stratum 3) - получают время от Stratum 2 серверов, и т.д.
Всего стратумов 16 штук, и их нумерация начинается с нуля. Нулю соответствуют хосты, которые получают время не по сети, а от локального источника точно времени.
Проект www.pool.ntp.org поддерживает списки публичных stratum 2 NTP серверов. Таким образом обеспечивается балансировка нагрузки, и они практически всегда доступны. Подключиться к российским серверам этого проекта можно по адресам ниже:
- 0.ru.pool.ntp.org
- 1.ru.pool.ntp.org
- 2.ru.pool.ntp.org
- 3.ru.pool.ntp.org
Также в РФ есть проект ФГУП "ВНИИФТРИ" (https://www.vniiftri.ru/) - эталонного времени Российской Федерации. В рамках данного проекта предоставляются 4 NTP-сервера точного времени (stratum 1). Все NTP сервера этого проекта работают от сигналов рабочих шкал Государственного первичного эталона времени, частоты и национальной шкалы времени РФ и вторичных эталонов в Иркутске, Хабаровске и Новосибирске.
Их доменные адреса в Интернете:
- Москва:
ntp1.vniiftri.ru
ntp2.vniiftri.ru
ntp3.vniiftri.ru
ntp4.vniiftri.ru - Иркутск:
ntp1.niiftri.irkutsk.ru
ntp2.niiftri.irkutsk.ru - Хабаровск:
vniiftri.khv.ru
vniiftri2.khv.ru - Новосибирск:
ntp.sstf.nsk.ru
Примерная точность синхронизации времени по протоколу NTPv4 при взаимодействии через интернет - десятки миллисекунд.
Примерная точность синхронизации времени по протоколу NTPv4 при взаимодействии по локальной сети - единицы миллисекунд.
-------------------------------------------------------------------------------------
Пакет chrony. Служба chronyd.
Общая информация
В составе дистрибутива ОС Astra Linux SE начиная с версии 1.7 входит пакет chrony. В более ранних версиях - пакет ntp.
Пакет chrony предназначен для поддержания системного времени в синхронизации с NTP-серверами, а также для управления ручным и автоматическим изменением системного времени.
В состав пакета chrony входят:
- служба chronyd (эта служба может обеспечивать работу ОС в режиме как сервера точного времени, так и клиента)
- консольная утилита chronyc. В названии cronyc буква "c" на конце означает control.
- до версии 4.0 - скрипт chrony-helper (/usr/lib/chrony/chrony-helper)
С момента включения в состав Astra Linux служба chronyd является рекомендованной серверной службой времени. Является штатной службой времени для использования с контроллерами домена FreeIPA начиная с версии FreeIPA 4.8.5.
ВАЖНО! Службы ntp, chronyd и timesyncd, несовместимы между собой и их одновременная работа невозможна!!!
При установке ОС Astra Linux 1.7 пакет chrony по умолчанию не устанавливается и может быть установлен командой sudo apt install chrony.
После установки служба chronyd запускается с настройками "по умолчанию" без конфигурационного файла, однако будет при этом работать только как клиент синхронизации времени.
Конфигурация службы chronyd находится в файле с именем /etc/chrony/chrony.conf. В этом файле содержатся подробные комментарии о назначении параметров настройки.
Чтобы служба начала работать как сервер времени, нужно в конфигурацию добавить строчку с разрешениями ("allow" - разрешить всем подключаться) и перезапустить службу chronyd.
При инициализации контроллера домена FreeIPA служба chronyd будет автоматически переведена в режим сервера времени.
Для корректной работы служб домена необходимо настроить chronyd так, чтобы он периодически синхронизировал часы с надежным источником (например, сервером NTP).
Для быстрой ПРИНУДИТЕЛЬНОЙ синхронизации времени на клиенте:
sudo systemctl stop chrony
sudo chronyd -q 'server <NTP-server_IP-address> iburst'
sudo systemctl start chrony
Требуемая пропускная полоса для работы подсистемы NTP крайне мала. Каждый клиент отправляет по одному небольшому UDP-пакету каждые ~20 минут. 1 кбит на пакет.
Алгоритм и особенности работы службы chronyd.
Алгоритм работы службы chrony:
- Загрузка операционной системы: Когда операционная система загружается, chronyd (демон chrony) также запускается.
- Запрос времени: Служба chronyd затем начинает отправлять запросы на NTP-серверы, перечисленные в файле конфигурации (/etc/chrony/chrony.conf)
- Получение времени: После получения ответа от NTP-сервера, chronyd обновляет системное время.
- Синхронизация: Процесс запроса-ответа продолжается на протяжении всего времени работы системы. Chronyd автоматически определяет оптимальную частоту запросов, обычно делая их каждые несколько минут.
Таким образом, для корректной работы пакета chrony его файл конфигурации должен указывать на один или несколько рабочих NTP-серверов при старте системы.
Служба chronyd увеличивает или уменьшает скорость системных часов, изменяя их тик-рейт, или скорость, с которой системные часы "тикают" вперед (это делается из-за того, что изменяется скорость системного часового генератора). Это делается постоянно, даже когда системное время уже синхронизировано.
Если системные часы работают быстрее, чем время, предоставляемое серверами NTP (из файла конфигурации службы), chronyd будет уменьшать тик-рейт, чтобы замедлить часы. Если системные часы отстают, chronyd увеличивает тик-рейт, чтобы ускорить часы. Это изменение тик-рейта производится постепенно. Маленькие шажки нужны для того, чтобы приложения, чувствительные к времени, не сошли с ума. Если время убежало вперёд, то оно не прыгнет назад, а как бы замедлится, и будет так тянуться до тех пор, пока не придет в норму.
Существует также функция makestep, которая позволяет chronyd сделать "большой шаг", т.е. мгновенное изменение системного времени, если ошибка времени превышает заданный порог. Это полезно при первом запуске, если системное время отличается от реального. Чтобы chronyd автоматически исправил большую разницу в времени при старте, вы можете использовать настройку makestep в файле chrony.conf. Например, строка:
makestep 0.1 -1
разрешит chronyd делать "большие шаги" любого размера при старте или при обнаружении значительного отклонения времени.
При настройке службы chronyd в параметрах конфигурационного файла можно указать один или несколько серверов NTP или один или несколько пулов серверов. Есть источники-сервера и источники-пулы. По умолчанию, при настройке нескольких серверов, chronyd будет оценивать все указанные серверы NTP и выбирать один или несколько наиболее надежных и точных для синхронизации времени. Величина и частота коррекции времени будут определены на основе этих измерений.
Важно понимать, что chronyd не просто берет время с одного "лучшего" сервера. Вместо этого он использует алгоритм выбора, который позволяет использовать данные от многих серверов для увеличения точности и устойчивости. Например, служба может отказаться от "выбросов" (ответов, которые сильно отличаются от большинства других ответов), чтобы уменьшить влияние сетевых задержек или неправильно работающих серверов.
Таким образом, chronyd оптимизирует использование доступных серверов NTP для обеспечения наибольшей возможной точности и надежности синхронизации времени (то есть служба функционирует таким образом, чтобы минимизировать влияние отдельного 'плохого' сервера, и чтобы использовать 'совокупное знание' от многих серверов для достижения точности и стабильности).
---------------------------------------------------------------------------------------------
Алгоритм работы подсистемы синхронизации времени в ALD Pro 2.2.1
Первый контроллер домена с корневым NTP сервером всегда берет время с пула внешних NTP серверов. Последующие контроллеры домена (без корневого NTP сервера) берут время с первого контроллера домена, где есть корневой NTP сервер или с других корневых серверов (не на каждом котроллере домена устанавливается корневой сервер NTP). Обычные клиенты домена берут время с любого контроллера домена. В домене MS AD только один корневой сервер времени, его функцию выполняет эмулятор PDC.
1. При установке первого контроллера домена у него устанавливается пул внешних NTP-серверов по умолчанию для синхронизации: в chrony.conf записывается директива pool 2.debian.pool.ntp.org iburst.
2. Также первый установленный контроллер домена становится корневым NTP-сервером домена: в chrony.conf записывается директива allow 0/0 (разрешает всем доступ к NTP).
3. При установке второго и последующего контроллера домена, а также других компьютеров домена происходит запись в chrony.conf ПРАКТИЧЕСКИ одной и той же информации (конфигурации по умолчанию):
- добавляется первый КД
- добавляется внешний пул
- добавляется ряд параметров
Единственное отличие, что строка allow 0/0 добавляется только для контроллера домена работающего в режиме NTP сервера. Ниже приведено содержимое /etc/chrony/chrony.conf для резервного контроллера домена и рабочей станции.
4. Дальнейшее изменение конфигурации NTP предусматривается с помощью групповой политики (ГП), в которой администраторы домена могут задать свою конфигурацию. Данная ГП находится в папке /srv/salt/standalone/roots/states/policies/host-policies/rbta_ldap_date_time_h. В ней используется следующий алгоритм работы скрипта /srv/salt/standalone/roots/states/policies/host-policies/rbta_ldap_date_time_h/init.sls:
- Если ГП назначена явно, то применяются настойки, заданные администратором.
- Независимо от того, назначена ГП или нет - если не назначены "Параметры сервера или пула сетевого времени" (переменная chrony_servers_policy) - удаляются все сервера и пулы из файла конфигурации chrony.conf.
- Если политика применяется на любом хосте, НЕ выполняющем роль контроллера домена (КД), то запрашиваются "ближайшие" КД с помощью команды: dig +short _ldap._tcp.domain_name SRV
- Из полученного результата формируется список для назначения в качестве NTP-серверов на компьютере (набор строк вида: server <fqdn> iburst).
- К полученному массиву строк с записями о серверах дописывается строка pool 2.debian.pool.ntp.org iburst как fallback.
- Если политика применяется на КД, то добавляется директива allow 0/0 (в режиме append_if_not_found: True);
- Если политика применяется на "первом КД", то получается значение параметра "Внешний пул NTP-серверов" и записывается в chrony.conf, НО если параметр внешнего пула не заполнен, то записывается строка pool 2.debian.pool.ntp.org iburst.
- Если политика применяется НЕ на "первом КД", то записывается в chrony.conf "первый КД" и 2.debian.pool.ntp.org в формате:
server <fqdn_первого_КД> iburst
pool 2.debian.pool.ntp.org iburst
- Для всех случаев сравниваются текущие рассчитанные настройки для NTP-серверов и пулов с последним примененным значением из конфигурации chrony.conf, сохраненным в grains (сущность SaltStack). Если есть изменения, то перезаписываются текущие настройки в grains и перезапускается служба chronyd.
- При рестарте (если он был нужен) происходит синхронизация компьютера с набором NTP-серверов и пулов из конфигурации.
ВАЖНО! В версии ALD Pro 2.2.0 и 2.2.1 на доменных машинах групповая политика NTP не срабатывает! В следующих версиях ALD Pro это исправлено.
Если добавить на портале управления новый сервер во внешний пул NTP серверов, и потом вызвать обновление политики командой ниже:
sudo salt-call state.apply gpupdate.gp -c /srv/salt/standalone/config
то обновление не произойдет, в этом можно убедиться открыв файл /etc/chrony/chrony.conf.
--------------------------------------------------------------------------------------------
Настройка Службы синхронизации времени через портал управления
В разделе «Служба синхронизации времени» ( Роли и службы сайта - Служба синхронизации времени ) доступны две вкладки:
- Внешний пул NTP-серверов:
- Корневые NTP-серверы домена:
В этот список можно добавить другие контроллеры домена и тогда они, как и первый контроллер, станут корневыми NTP серверами.
---------------------------------------------------------------------------------------------
Проверка синхронизации времени
ВАЖНО! По умолчанию в Astra Linux синхронизация времени отключена!
При установке «ALD Pro» (как клиентской, так и серверной части) в системе появляется служба chrony, содержание конфигурационного файла которой автоматически редактируется через механизм групповых политик в соответствии с текущими настройками домена «Роли и службы сайта \ Служба синхронизации времени». Пользовательские компьютеры синхронизируют время с контроллером, а контроллер берет его у публичных серверов, как показано на рисунках ниже:
Текущие настройки службы синхронизации времени на хосте можно посмотреть в файле /etc/chrony/chrony.conf:
В настройках chrony, которые использует «ALD Pro», указан параметр rtcsync, поэтому клиенты сверяют часы каждые 11 минут. Параметр rtcsync так же необходим для того, чтобы служба chrony при синхронизации времени сбрасывала флаг STA_UNSYNC, иначе в приложении «Дата и время» на контроллере домена будет оставаться предупреждение об отсутствии синхронизации.
Принудительно обновить содержание конфигурационного файла через механизм групповых политик можно перезапуском службы salt-minion:
sudo systemctl restart salt-minion
Принудительно запустить синхронизацию времени можно перезапуском службы:
sudo systemctl restart chrony
Текущее состояние синхронизации можно узнать в приложении «Дата и Время» или командой timedatectl:
timedatectl
Для взаимодействия со службой chronyd во время ее работы предназначен интерфейс командной строки chronyc. В названии cronyc буква "c" на конце означает control. Чтобы увидеть, с какими серверами служба устанавливает соединение, можно отправить через него команду sources. Посмотрим вывод этой команды на клиенте host1.ald.local:
sudo chronyc sources -v
Cимволом звездочки "^*" отмечен сервер, время которого установлено в системе (dc1.ald.local).
Сравним, вывод этой же команды на котроллере домена dc1.ald.local:
sudo chronyc sources -v
В настройках chrony, которые использует «ALD Pro», указан параметр makestep, поэтому при выполнении синхронизации компьютер сразу устанавливает требуемое значение. Если у вас будет отсутствовать параметр makestep, то служба будет крайне медленно «подтягивать» время к требуемом значению (по несколько секунд в минуту), и вам будет казаться, что синхронизация времени не работает.
Форсировать переход к целевому значению в этом случае вы можете вызовом команды makestep через chornyc:
sudo chronyc makestep
Если требуется проверить работу NTP-сервера, вы можете воспользоваться командой ntpdate с ключом q (query only, отправить только запрос без изменения времени). Крайне полезными являются также ключи v и d, включающие подробный вывод (verbose) и отладку (debugging) соответственно.
sudo ntpdate -qvd dc1.ald.local
После синхронизации времени указанная выше команда timedatectl может показать расхождение между системным временем ALSE (Universal time) и значением времени в BIOS (RTC time, real time clock), так как запись в BIOS происходит только при выключении компьютера. Записать текущее время системы в BIOS можно утилитой hwclock с параметром systohc:
sudo hwclock --systohc
При значительном изменении времени ранее выданные билеты Kerberos могут оказаться недействительными, поэтому может потребоваться повторно пройти аутентификацию в домене командой kinit:
kdestroy && kinit
Информацию о выданных билетах можно увидеть командой klist:
klist
--------------------------------------------------------
Список (пополняемый) других вышедших материалов об ALD Pro:
1. Установка первого контроллера домена ALD Pro 2.2.1:
2. Ввод клиента в домен ALD Pro
3. Установка резервного контроллера домена ALD PRO 2.2.1:
4. Механизм репликации в ALD Pro 2.2.1
5. Служба синхронизации времени Chrony