ntpdate работает, но ntpd не может синхронизироваться

В 377 в reach столбец означает, что соединение в порядке; telnet не будет подключаться, потому что NTP - это UDP.

Попробуйте удалить server 127.127.1.0 из вашей конфигурации - * по *LOCAL(0) сообщает нам, что для синхронизации используется локальный сервер со слоем 5, предпочтительнее, чем удаленный сервер со слоем 1; и задержка, и смещение равны 0,000, вероятно, во многом с этим.

У меня такая же проблема:

ntpq -p показывал охват = 0

Тем не менее, 1- ntpd был запущен 2- ntp.conf имеет перечисленные серверы 3- ntpdate работал с этими серверами 4- ntpdate -u работал с этими серверами 5- nc показал, что TCP-порт 123 был открыт на этих серверах 6-nc показал, что UDP-порт 123 был открыть на этом сервере

Таким образом, в основном ntpdate работал, и проблем с брандмауэром не было, и все же ntpq -p показал охват = 0 для каждого из перечисленных серверов.

Оказалось, что это строки ограничения в ntp.conf. Я просто удалил все ограничивающие строки из ntp.conf и перезапустил ntpd, и оттуда все заработало.

Если вы собираетесь включить местные часы, немного измените их уровень. Похоже, у вас установлено значение 5. Обычно я устанавливаю не менее 8 (fudge 127.127.1.0 stratum 8). Если вы не обманываете его, вы можете показаться другим хостам в вашей сети как атомные часы. В одной просканированной мной сети я обнаружил множество низкоуровневых серверов, объявляющих время, которое обычно было неправильным по часам или дням.

Шейн прав насчет reach значение, которое указывает, что у вас есть доступ к серверу. Высота offset и jitter Значения для вашего сервера времени указывают на то, что он может быть не очень надежным. Они могут быть высокими, потому что ваш сервер все еще синхронизируется. Тот факт, что poll Интервал увеличился до 128, это означает, что ваш сервер получает стабильные результаты. Оно должно постепенно увеличиваться до 1024 секунд.

Попробуйте запустить такой цикл:

while sleep 60; do
    ntpq -n -c peers; done

Это даст вам представление о том, насколько хорошо работает ntp. Вы должны увидеть, как со временем он стабилизируется.

Существует ряд ограничений, которые можно установить на ntpd чтобы ограничить объем информации о сервере, к которому можно получить удаленный доступ. Возможно, вы ограничены использованием только вышестоящего сервера в качестве источника времени.

Возможны правила брандмауэра, ограничивающие трафик до порта 123 как для источника, так и для пункта назначения. Это обеспечивает рабочую настройку ntp, но ограничивает доступ для других инструментов. Некоторые инструменты позволяют использовать порт 123 в качестве исходного порта, если он доступен. Я неравнодушен к использованию ntpdate в режиме отладки.

Если вы правы насчет refid если исходящий сервер является вашим IP-адресом, похоже, он использует ваш сервер в качестве предпочтительного источника времени. Попробуйте добавить restrict noquery к вашей конфигурации. Возможно, ваш вышестоящий сервер плохо настроен. Попробуйте добавить свой маршрутизатор и / или серверы имен в качестве источников, я считаю, что они могут быть лучшими источниками, чем официальный корпоративный сервер.

Приношу свои извинения тем из вас, кто ищет грандиозное решение. Это будет глупо.

Да, сервер времени недоступен по причине, которую я никогда не мог определить. Хорошей новостью является то, что один из внешних DNS-серверов, к которым у меня есть доступ, сам обслуживает пакеты NTP, и Это подключается к этому внешнему серверу времени для своих тиков. Это обходной путь, а не исправление. Но я возьму все, что смогу.

Итак, в итоге я теряю только один слой обслуживания.

В качестве примечания я зарегистрировался в базе данных ошибок NTP, чтобы я мог написать улучшение ошибка 2297, запрашивая формальную документацию для одноранговых ссылок .INIT., .LOCL. и LOCAL (0).

Просто хотел добавить свои два цента в верхний результат поиска Google ... Я столкнулся с этой проблемой на хосте, где NTP не был привязан к внешнему интерфейсу хоста. Если у вас есть эта проблема, посмотрите на вывод netstat -tulpn.

Этот экземпляр ntpd не сможет синхронизироваться с известным надежным источником времени.

$ sudo netstat -tulpn | grep ntp
udp        0      0 127.0.0.1:123               0.0.0.0:*                                  31316/ntpd          
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               31316/ntpd          

Это будет.

$ sudo netstat -tulpn | grep ntp
udp        0      0 192.168.1.15:123            0.0.0.0:*                               32294/ntpd          
udp        0      0 127.0.0.1:123               0.0.0.0:*                               32294/ntpd          
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               32294/ntpd   

Это было результатом того, что файл конфигурации пытался ограничить привязку к интерфейсам IPv4 только с помощью подстановочного знака 0.0.0.0.

$ grep ^interface /etc/ntp.conf 
interface listen 0.0.0.0

Правильная (желаемая) конфигурация была следующей.

$ grep ^interface /etc/ntp.conf 
interface listen ipv4
interface ignore ipv6

(Или, чтобы удалить оба варианта конфигурации интерфейса.)

Вы также можете проверить /etc/sysconfig/ntp или эквивалент для любой конфигурации, которая может ограничивать привязку интерфейса.