collectd kann ntpd 4.2.8 (Ubuntu 16.04) nicht überwachen

Question

Ich habe einen Docker-Container basierend auf Ubuntu 16.04, der den Dienst ntpd 4.2.8 ausführt. Beim Instanziieren des Containers habe ich den Port 123/udp veröffentlicht.

Vom Host oder einem anderen Computer im LAN kann ich ntpq -p <container_host>die Liste der Peers und den Synchronisierungsstatus abrufen. Aber die Überwachung mit collectd oder das Ausführen von ntpdc -c kerninfo <container_host>Fehlern/Timeouts. Und das verwirrt mich!

Ich habe es im Container mit einigen vernünftigen restrictAnweisungen und auch ohne getestet. Aber in beiden Fällen kam es zu einer Zeitüberschreitung. Das Ausführen von tcpdump im Container (nachdem es zu einem privilegierten Container erhoben wurde) zeigt, dass das UDP-Paket ankommt, aber nichts beantwortet wird. Natürlich sehe ich bei Verwendung von tcpdump sowohl die Anfrage als auch die Antwort, wenn ich ntpq verwende, was funktioniert.

Wenn ich den ntpd-Server direkt auf dem Host ausführe und dabei dieselbe ntp.conf-Datei verwende, ntpdc -c kerninfo <container_host>sind sowohl ntpd als auch collectd vom Host und anderen Computern im von mir autorisierten LAN erfolgreich! Auf dem Host läuft jedoch immer noch eine ältere Version von Ubuntu (14.04), die mit ntp 4.2.6 ausgeliefert wird.

Die einzigen Unterschiede sind also das Docker-Netzwerk (NAT, soweit ich verstanden habe) und die NTP-Version (4.2.6 vs. 4.2.8). Aber die Dokumentation von ntp.org erwähnt weder NAT noch 4.2.8-Updates. Wird mein Befehl also nur deshalb abgebrochen, weil sich der Client in einem anderen Subnetz als der Server befindet (aufgrund von NAT)? Oder weil sich in 4.2.8 etwas geändert hat?

Hinweis: Mein Container-Image basiert auf Ubuntu:16.04, auf dem ntpd ausgeführt wird[email geschützt](aus den offiziellen Ubuntu-Repositories). Der Host führt Ubuntu 14.04 aus, auf dem 4.2.6p5 läuft.

PS: Collectd sendet einen Befehl, der dem Timeout entspricht ntpdc -c kerninfo <container_host>, wenn ntpd im Container ausgeführt wird, auch wenn alle Restrict-Anweisungen korrekt sind.

Aktualisieren: Ich habe vergessen zu erwähnen, dass ich auch den ntpd im Container ausgeführt habe, mit der -dddOption, eine ausführlichere Ausgabe zu erhalten. Die einzigen relevanten Daten, die protokolliert wurden, sind:

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

Update 2:: Nachdem ich die Lösung gefunden hatte, habe ich die Frage geändert, in der Hoffnung, dass andere, die auf dasselbe Problem stoßen, die Frage/Antwort bei der Suche danach besser finden könnten. Ich habe auch einen Fehler korrigiert: Ich dachte, auf dem Host liefe Ubuntu 16.04, aber tatsächlich lief immer noch 14.04.

Answer 1

ntpdcIch habe mein Problem gelöst. Der Fehler liegt daran, dass NTP 4.2.8 das Tool und den von ihm verwendeten Kommunikationsmodus (auch bekannt als Mode7) veraltet (und standardmäßig deaktiviert) hat .

Ab NTP 4.2.8 und neueren Versionen ntpqkann das Tool anstelle von NTPDC verwendet werden. Es unterstützt nun die gleichen Befehle wie NTPDC. Ich kann es also ntpq -c kerninfo <container_host>erfolgreich ausführen. Der ntpqBefehl verwendet einen anderen Modus (auch bekannt als Mode6) für die Kommunikation.

Mit NTP 4.2.8 ist es noch möglich, den Modus 7 wieder zu aktivieren, um die Kompatibilität mit noch nicht migrierten Tools zu unterstützen. Dazu muss folgende Zeile in die Datei eingefügt werden /etc/ntp.conf:

enable mode7

Man sollte jedoch mit der Einschränkung sehr vorsichtig sein. Es scheint, dass die Aktivierung von Mode7 und das zu offene Öffnen des NTP-Servers für DDoS-Amplification-Angriffe genutzt werden könnte. Ich verwende derzeit die Standardbeschränkung für IPv4 und IPv6 unter Ubuntu, die -Ich finde- blockiert die Verwendung dieses Modus:

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

Da collectd nur den Modus7 unterstützt (sieheAusgabe Nr. 932), habe ich beschlossen, diesen Modus in meiner Konfiguration im Container wieder zu aktivieren. Solange ntp die erneute Aktivierung dieses Modus unterstützt, sollte diese Änderung das Problem beheben, dass collectd ntpd unter Ubuntu 16.04 (oder einer beliebigen Distribution, die ntp 4.2.8+ verwendet) nicht überwachen kann.

Hinweis: Damit Benutzer bei Auftreten dieses Problems besser eine Lösung finden können, werde ich die Frage bearbeiten, damit sie in Bezug auf NAT, das ich zunächst für die Grundursache hielt, weniger irreführend ist.