диагностика источников chronyc неработоспособны – время не синхронизируется

Пытаюсь настроить chrony в локальной сети на RHEL-8.10. Служба на моем сервере chrony или клиенте, похоже, работает, как сообщается командой service chronyd status -l. Однако я не могу синхронизировать время между двумя, они разошлись на пару минут.

# эта команда выполняется на сервере клиента, имеющем IP 192.168.1.4, например

chronyc> sources -a -v

  .-- Режим источника  '^' = сервер, '=' = пир, '#' = локальные часы.
 / .- Состояние источника '*' = текущий лучший, '+' = комбинированный, '-' = не комбинированный,
"https://unix.stackexchange.com/"x' = может быть ошибочным, '~' = слишком изменчивый, '?' = непригодный.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Регистр доступности (восьмеричный) -.     |  xxxx = скорректированный сдвиг,
||      Log2(интервал опроса) --.      |          |  yyyy = измеренный сдвиг,
||                                \     |          |  zzzz = оценочная ошибка.
||                                 |    |           \
MS Имя/адрес IP          Стратум Опрос ПоследнийRx Последний образец
===============================================================================
^? 192.168.1.1                   3   6   377     5  -1500мкс[-1705мкс] +/-  500мс

# Я отредактировал имя/IP здесь для публикации, оно разрешается в имя хоста через DNS в нашей маленькой локальной сети

Команда chronyc tracking показывает нули, в то время как на другом сервере, который подключен к сети [интранет], синхронизируется с выделенным временным сервером, и здесь время совпадает с временем с time.gov до секунды, а chronyc tracking сообщает такие данные, как Системное время : 0.000830548 секунды опережает NTP время, а не все нули.

На моих системах локальной сети я пытался использовать setenforce 0 и service firewalld stop, и ни одно из этих действий не помогло.

Что вызывает '?' = непригодный в chronyc sources? Это кажется самой очевидной проблемой при сравнении работающей и неработающей настройки.

Я чувствую, что моя ошибка в том, что на моем сервере RHEL-8.10, который я пытаюсь сделать сервером времени для синхронизации других, есть что-то особенное в /etc/chrony.conf, что необходимо, но не было явно задокументировано в этом стандартном файле, предоставленном Red Hat? Ниже представлен мой /etc/chrony.conf с сервера, который я хочу сделать сервером времени в своей локальной сети с IP 192.168.1.1, который не синхронизируется ни с чем другим. Не хватает ли чего-то ниже, что могло бы вызвать '?' = непригодный при выполнении chronyc sources -a -v с временного клиента в моей локальной сети?

# Записать скорость, с которой системные часы накапливают/теряют время.
driftfile /var/lib/chrony/drift

# Разрешить шаг часов системы в первых трех обновлениях
# если их сдвиг больше 1 секунды.
makestep 1.0 3

# Включить синхронизацию ядра с часами реального времени (RTC).
rtcsync

# Включить аппаратную временную метку на всех интерфейсах, которые поддерживают это.
#hwtimestamp *

# Увеличить минимальное количество источников, которые можно выбрать, необходимых для корректировки
# системных часов.
#minsources 2

# Разрешить доступ NTP-клиента из локальной сети.
allow 192.168.1.0/24

# Обслуживать время, даже если не синхронизировано с источником времени.
local stratum 10

# Указать файл, содержащий ключи для аутентификации NTP.
keyfile /etc/chrony.keys

# Получить сдвиг TAI-UTC и дополнительные секунды из системной базы данных tz.
leapsectz right/UTC

# Указать директорию для журнальных файлов.
logdir /var/log/chrony

# Выбрать, какая информация будет записываться.
#log measurements statistics tracking

На моих клиентах их chrony.conf просто содержит server 192.168.1.1 iburst в начале.

В моем случае причиной ? = непригодный, как сообщалось командой chronyc sources -a -v, было отсутствие открытого порта 123 UDP в брандмауэре на моем временном сервере.

Мой файл /etc/firewalld/zones/custom.xml имел строку для открытия 123/udp, однако команда firewall-cmd --list-all не отображала этот номер порта. Решением в моем случае было:

• переотредактировать XML-файл брандмауэра, выполнить firewall-cmd --complete-reload и убедиться, что 123/udp отображается при выполнении firewall-cmd --list-all.
  • конечно, можно было бы также выполнить systemctl stop firewalld
• однако даже при отключении брандмауэра как на сервере, так и на клиенте я заметил, что служба chronyd должна быть перезапущена на клиенте, и затем следует подождать как минимум 30 секунд перед выполнением chronyc sources -a -v, чтобы увидеть, получите ли вы ответ ^* вместо ^?. Когда я в первый раз выполнил все, печатая быстро, я всегда получал ^? от chronyc sources, что вызывало недовольство.
• Я обнаружил, что службу chrony также нужно было перезапустить на клиенте, только после этого chrony sources -a -v примерно через 30 секунд сообщала с * = лучший вместо непригодного. И chronyc tracking затем не показывала все нули.