Клиент Windows NTP не синхронизируется с сервером Linux

Пытаюсь синхронизировать время трех компов в локальной сети. Хотя иметь наименьший возможный дрейф/ошибку в мире/интернете было бы здорово, это не мой концерт. Моей главной заботой является наилучшая возможная синхронизация между тремя компьютерами.

Для этого я настроил одну из двух машин Ubuntu (192.168.1.50) в качестве ntp-сервера. Я сделал это, отредактировав файл конфигурации сервера Ubuntu NTP в /etc/ntp.conf и добавить:

сервер 127.127.1.0 iburst
выдумка 127.127.1.0 слой 10

Затем я проверил, что другой компьютер с Ubuntu (192.168.1.71) синхронизирован с ним. Сначала я добавил серверная станция управления предпочитает iburst до конца /etc/ntp.conf и перезапустил службу времени с помощью перезапустить службу sudo ntp. После этого я могу проверить правильность синхронизации времени этих двух компьютеров, запустив ntpdate -q 192.168.1.50:

сервер 192.168.1.50, уровень 2, смещение 0,001271, задержка 0,02599
 8 марта, 11:06:36 ntpdate[17648]: настроить сервер времени 192.168.1.50, смещение 0,001271 сек.

Кажется, это работает правильно, и смещение 0,001271 приемлемо для моей цели. Далее нужно сделать то же самое с окнами (192.168.1.201). Сначала я проверяю, что компьютеры действительно не синхронизированы:

w32tm/ленточная диаграмма/компьютер:192.168.1.50
12:10:01, д:+00.0010124с о:-00.4908814с [ *| ]
12:10:03, д:+00.0005757с о:-00.4907188с [ *| ]

Что имеет смысл, так как клиент Windows до сих пор синхронизирован с time.windows.com:

w32tm/запрос/статус
Индикатор скачка: 0 (без предупреждения)
Слой: 4 (вторичная ссылка - синхронизировано (S)NTP)
Точность: -23 (119,209 нс на тик)
Корневая задержка: 0,0386977 с
Корневая дисперсия: 8,2445365 с
ReferenceId: 0x33917B1D (исходный IP-адрес: 51.145.123.29)
Время последней успешной синхронизации: 08.03.2022, 12:13:23.
Источник: time.windows.com,9
Интервал опроса: 10 (1024 с)

Я изменил сервер времени с помощью w32tm/config/update/manualpeerlist:192.168.1.50,0x8/syncfromflags:MANUAL и принудительная повторная синхронизация w32tm/повторная синхронизация:

Отправка команды повторной синхронизации на локальный компьютер
Команда выполнена успешно.

Затем снова проверил разницу во времени между сервером Ubuntu ntp и этой машиной Windows:

w32tm/ленточная диаграмма/компьютер:192.168.1.50
Отслеживание 192.168.1.50 [192.168.1.50:123].
Текущее время: 08.03.2022 12:22:01.
12:22:01, д:+00.0005075с о:-00.4568042с [ *| ]
12:22:03, д:+00.0010415с о:-00.4566323с [ *| ]
12:22:05, д:+00.0009737с о:-00.4569219с [ *| ]

Что показывает, что ntp-клиент Windows явно не синхронизирован с ntp-сервером ubuntu. Однако, если я проверю статус:

w32tm/запрос/статус
Индикатор скачка: 0 (без предупреждения)
Слой: 3 (вторичная ссылка - синхронизировано (S)NTP)
Точность: -23 (119,209 нс на тик)
Корневая задержка: 0,0314761 с
Корневая дисперсия: 8,2468633 с
ReferenceId: 0xC0A80132 (исходный IP-адрес: 192.168.1.50)
Время последней успешной синхронизации: 08.03.2022, 12:20:37.
Источник: 192.168.1.50,8
Интервал опроса: 10 (1024 с)

Очевидно, что источник правильный (192.168.1.50) и что он был синхронизирован непосредственно перед запросом.

Присоединены ли эти машины Windows к домену Active Directory?

если это так, конфигурация групповой политики по умолчанию будет переопределять любую ручную настройку NTP, которую вы пытаетесь выполнить.

Вы можете настроить в групповой политике пользовательскую конфигурацию NTP для клиентских машин, но совершенно не рекомендуется использовать пользовательский NTP для клиентских рабочих станций AD, так как это может довольно легко привести к дрейфу между вашими клиентами и вашими контроллерами домена, и если это выходит за рамки волшебных 5 минут mark Kerberos взрывается, и ваши входы в систему начнутся со сбоями

Лучше всего, если ваш контроллер домена с ролью PDC выполняет NTP в Интернете, а затем все ваши клиенты подключаются через PDC и другие контроллеры домена.

Вывод состояния конфигурации на самом деле не показывает никаких ошибок или причин думать, что он не синхронизируется с сервером NTP — что заставляет вас думать, что он не синхронизируется?

Важно отметить, что NTP не будет постоянно повторно синхронизироваться, он опрашивает в определенном окне, которое постепенно замедляется с течением времени для поддержания нагрузки, в настоящее время говорится, что он будет опрашивать/синхронизировать свое время каждые 1024 секунды, что составляет чуть более 16 минут. интервалы.

Также важно отметить, что тактовые частоты ЦП и тактовые частоты/кристаллы CMOS на материнских платах будут иметь очень небольшие отклонения по частоте, что в первую очередь способствует тому, почему вы получаете временной дрейф, 456 мс отклонения, хотя и не кажутся блестящими, но все же хорошо в пределах очень приемлемого, если вы не имеете дело с очень чувствительным ко времени (например, с точностью менее 1 с) или на основе ядра в реальном времени - для чего вы, вероятно, не будете использовать окна в первую очередь;)

Также обратите внимание, что большинство реализаций NTP изо всех сил стараются не переключать часы машины, на которой они работают. Вместо этого они пытаются ускорить часы, чтобы в конечном итоге догнать источник времени.Это делается для того, чтобы часы не прыгали вперед или назад во времени, поскольку некоторым приложениям это не очень нравится. И менее 0,5 секунды определенно ниже порога для шага часов, поэтому я готов поспорить, что машина догонит сервер NTP в течение дня или около того. Также имейте в виду, что NTP (и не PTP, если на то пошло) не предлагает абсолютную синхронизацию двух машин, она всегда находится в пределах допуска. Я не могу вспомнить достижимые допуски в моей голове, но это около миллисекунд с NTP и микро/наносекунд с PTP.