collectd не может контролировать ntpd 4.2.8 (Ubuntu 16.04)

У меня есть контейнер Docker на основе Ubuntu 16.04, который запускает службу ntpd 4.2.8. После создания контейнера я опубликовал порт 123 / udp.

С хоста или другого компьютера в локальной сети я могу использовать ntpq -p <container_host> чтобы получить список сверстников и статус синхронизации. Но отслеживать его с помощью collectd или запускать ntpdc -c kerninfo <container_host> сбой / таймауты. И это меня озадачивает!

Я тестировал его внутри контейнера с некоторыми разумными restrict утверждениями, а также без каких-либо restrict . Но в обоих случаях я тайм-аут. Запуск tcpdump в контейнере (после подъема его в привилегированный контейнер) показывает, что пакет UDP прибывает, но ничего не ответил. Конечно, используя tcpdump, я вижу как запрос, так и ответ при использовании ntpq, который работает.

Если я запускаю сервер ntpd на хосте напрямую, используя тот же файл ntp.conf, ntpdc -c kerninfo <container_host> и собирает оба пользователя с хоста и других компьютеров в локальной сети, которые я разрешил! Тем не менее, на хосте все еще запущена более ранняя версия Ubuntu (14.04), которая поставляется с ntp 4.2.6.

Таким образом, единственные отличия – это докеры (NAT, насколько я понял) и версия ntp (4.2.6 против 4.2.8). Но в документации ntp.org ничего не говорится о NAT, а также о обновлениях 4.2.8. Так ли моя команда тайм-аут только потому, что клиент находится в другой подсети, чем сервер (из-за NAT)? Или как-то изменилось в 4.2.8?

Примечание: образ моего контейнера основан на ubuntu: 16.04, который запускает ntpd 4.2.8p4@1.3265-o (из официальных репозиториев Ubuntu). Хост запускает Ubuntu 14.04, который работает 4.2.6p5.

PS: Collectd представляет команду, эквивалентную ntpdc -c kerninfo <container_host> и ntpdc -c kerninfo <container_host> когда ntpd запускается в контейнере, даже это все инструкции ограничения корректны.

Обновление : я забыл упомянуть, что я также запустил ntpd внутри контейнера с параметром -ddd чтобы получить более подробный вывод. Единственными релевантными данными, которые были зарегистрированы, являются:

 read_network_packet: fd=19 length 192 from 192.168.1.3 receive: at 26 172.17.0.2<-192.168.1.3 flags 19 restrict 000 

Update2 : после выяснения решения я изменил вопрос, надеясь, что другое спотыкание по одной и той же проблеме может лучше найти вопрос / ответ при поиске. Я также исправил одну ошибку, я думал, что хост работает Ubuntu 16.04, но на самом деле все еще работает 14.04.

Я решил свою проблему. Ошибка связана с тем, что ntp 4.2.8 обесценивает (и отключает по умолчанию) инструмент ntpdc и режим связи, который он использовал (aka mode7).

Из ntp 4.2.8 и более новой версии инструмент ntpq следует использовать вместо ntpdc. Теперь он поддерживает те же команды, что и ntpdc. Поэтому я могу ntpq -c kerninfo <container_host> запустить ntpq -c kerninfo <container_host> . Команда ntpq использует другой режим (aka mode6) для связи.

С ntp 4.2.8 все еще можно повторно включить режим7, чтобы поддерживать совместимость с инструментами, которые еще не перенесли. В /etc/ntp.conf необходимо добавить следующую строку:

 enable mode7 

Однако с этим нужно быть очень осторожным. Похоже, что включение режима7 и оставление сервера ntpd слишком открытыми, может быть использовано для проведения DDoS-атак усиления. В настоящее время я использую ограничение по умолчанию для IPv4 и IPv6 на Ubuntu, которое, я думаю, блокирует использование этого режима:

 restrict -4 default kod notrap nomodify nopeer noquery limited restrict -6 default kod notrap nomodify nopeer noquery limited 

Поскольку collectd поддерживает только режим7 (см. Вопрос № 932 ), я решил снова включить этот режим в своей конфигурации внутри контейнера. Пока ntp поддерживает повторное включение этого режима, это изменение должно устранить проблему, с которой collectd не может контролировать ntpd на Ubuntu 16.04 (или любой дистрибутив с помощью ntp 4.2.8+).

Обратите внимание: для того, чтобы люди могли лучше найти решение, если они столкнулись с этой проблемой, я собираюсь отредактировать вопрос, чтобы быть менее обманчивым в отношении NAT, который я, поначалу, был первопричиной.