.png)
У меня есть контейнер Docker на базе Ubuntu 16.04, который запускает службу ntpd 4.2.8. После создания экземпляра контейнера я опубликовал порт 123/udp.
С хоста или другого компьютера в локальной сети я могу использовать ntpq -p <container_host>для получения списка пиров и статуса синхронизации. Но мониторинг с помощью collectd или запуском ntpdc -c kerninfo <container_host>завершается неудачей/таймаутами. И это меня озадачивает!
Я тестировал его внутри контейнера с некоторыми разумными restrictутверждениями и также без них. Но в обоих случаях я выхожу из строя. Запуск tcpdump в контейнере (после повышения его до привилегированного контейнера) показывает, что пакет UDP приходит, но ответа нет. Конечно, используя tcpdump, я вижу и запрос, и ответ при использовании ntpq, который работает.
Если я запускаю сервер ntpd на хосте напрямую, используя тот же файл ntp.conf, то ntpdc -c kerninfo <container_host>и collectd успешно запускаются с хоста и других компьютеров в локальной сети, которые я авторизовал! Однако хост все еще работает под управлением старой версии Ubuntu (14.04), которая поставляется с ntp 4.2.6.
Итак, единственные различия — это сетевое взаимодействие Docker (NAT, насколько я понял) и версия ntp (4.2.6 против 4.2.8). Но в документации ntp.org ничего толком не упоминается ни о NAT, ни об обновлениях 4.2.8. Так что, моя команда истекает по тайм-ауту только потому, что клиент находится в другой подсети, чем сервер (из-за NAT)? Или что-то изменилось в 4.2.8?
Примечание: мой образ контейнера основан на Ubuntu:16.04, на котором запущен ntpd.[email protected](из официальных репозиториев Ubuntu). Хост работает под управлением Ubuntu 14.04, которая работает под управлением 4.2.6p5.
PS: Collectd отправляет команду, эквивалентную ntpdc -c kerninfo <container_host>и таймауту, когда ntpd работает в контейнере, даже если все операторы restrict верны.
Обновлять: Я забыл упомянуть, что я также запустил 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
Обновление2: Найдя решение, я изменил вопрос, надеясь, что другие, столкнувшиеся с той же проблемой, смогут лучше найти вопрос/ответ при поиске. Я также исправил одну ошибку: я думал, что хост работает под управлением Ubuntu 16.04, но на самом деле он все еще работал под управлением 14.04.
решение1
Я решил свою проблему. Ошибка возникла из-за того, что ntp 4.2.8 устарел (и отключил по умолчанию) инструмент ntpdcи используемый им режим связи (он же mode7).
Начиная с версии ntp 4.2.8 и более новых версий, инструмент ntpqдолжен использоваться вместо ntpdc. Теперь он поддерживает те же команды, что и ntpdc. Поэтому я могу ntpq -c kerninfo <container_host>успешно запустить. ntpqКоманда использует другой режим (он же mode6) для связи.
С ntp 4.2.8 все еще возможно повторно включить mode7 для поддержки совместимости с инструментами, которые еще не были перенесены. Необходимо добавить следующую строку в /etc/ntp.conf:
enable mode7
Однако следует быть очень осторожным с ограничением. Похоже, что включение mode7 и оставление сервера ntpd слишком открытым может быть использовано для проведения атак DDoS-усиления. В настоящее время я использую ограничение по умолчанию для IPv4 и IPv6 в Ubuntu, которое -Я думаю- блокирует использование этого режима:
restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
Так как collectd поддерживает только mode7 (см.выпуск №932), я решил снова включить этот режим в моей конфигурации внутри контейнера. Пока ntp поддерживает повторное включение этого режима, это изменение должно исправить проблему, из-за которой collectd не может отслеживать ntpd на Ubuntu 16.04 (или любом дистрибутиве, использующем ntp 4.2.8+).
Примечание: для того, чтобы людям было легче найти решение, если они столкнутся с этой проблемой, я собираюсь отредактировать вопрос, чтобы меньше вводить в заблуждение относительно NAT, который, как я изначально считал, был основной причиной.