timeserver mit xntpd und firewall (was:xntp als Zeitserver)
Hallo Liste, es geht noch mal um xntpd - genauer gesagt um die Abfrage der Zeit von einem SuSE8.2-client aus von einem SuSE8.2-DSL-Gateway via xntpd. Auf dem Gateway läuft xntpd und synchronisiert auch schön. Die Abfrage der Zeit vom Gateway vom client aus wird aber mit einem "try to get time...failed." quittiert. Inzwischen weiß ich, daß das irgendetwas mit der Firewall zu tun haben muß, denn wenn ich versuche, von einem anderen client im gleichen Netzwerk (auf dem ich probeweise xntpd gestartet habe) die Zeit zu holen, klappt das ohne Probleme!! Hat dazu jemand eine Idee? Danke und Gruß Siegfried
Siegfried Haas wrote:
Hallo Liste, es geht noch mal um xntpd - genauer gesagt um die Abfrage der Zeit von einem SuSE8.2-client aus von einem SuSE8.2-DSL-Gateway via xntpd. Auf dem Gateway läuft xntpd und synchronisiert auch schön. Die Abfrage der Zeit vom Gateway vom client aus wird aber mit einem "try to get time...failed." quittiert. Inzwischen weiß ich, daß das irgendetwas mit der Firewall zu tun haben muß, denn wenn ich versuche, von einem anderen client im gleichen Netzwerk (auf dem ich probeweise xntpd gestartet habe) die Zeit zu holen, klappt das ohne Probleme!! Hat dazu jemand eine Idee?
Hallo Siegfried,
Ich versuchs nochmal.... Ich habe eine ähnliche config wie du und ich
habe auf dem Client im inneren Netz Suse 7.3.
im /etc/ntp.conf
server 192.168.1.18
peer 192.168.1.18 prefer
Mit xntpdc sehe ich dann (einen Moment nach dem booten)
ntpdc> sysinfo
system peer:
claus schrieb:
Siegfried Haas wrote:
Hallo Liste, es geht noch mal um xntpd - genauer gesagt um die Abfrage der Zeit von einem SuSE8.2-client aus von einem SuSE8.2-DSL-Gateway via xntpd. Auf dem Gateway läuft xntpd und synchronisiert auch schön. Die Abfrage der Zeit vom Gateway vom client aus wird aber mit einem "try to get time...failed." quittiert. Inzwischen weiß ich, daß das irgendetwas mit der Firewall zu tun haben muß, denn wenn ich versuche, von einem anderen client im gleichen Netzwerk (auf dem ich probeweise xntpd gestartet habe) die Zeit zu holen, klappt das ohne Probleme!! Hat dazu jemand eine Idee?
Hallo Siegfried,
Ich versuchs nochmal.... Ich habe eine ähnliche config wie du und ich habe auf dem Client im inneren Netz Suse 7.3.
im /etc/ntp.conf server 192.168.1.18 peer 192.168.1.18 prefer
Mit xntpdc sehe ich dann (einen Moment nach dem booten) ntpdc> sysinfo system peer:
system peer mode: sym_active leap indicator: 00 stratum: 4 precision: -16 root distance: 0.05113 s root dispersion: 0.11209 s reference ID: [192.168.1.18] reference time: c56919c2.bdaf07bf Tue, Dec 14 2004 8:50:26.740 system flags: auth monitor ntp kernel stats kernel_sync jitter: 0.000626 s stability: 0.044 ppm broadcastdelay: 0.003998 s authdelay: 0.000000 s Sieht für mich soweit gut aus.
Nur habe ich auf dem Client keine Firewall laufen, mag das der Unterschied sein?
Gruss, Claus
Das ist tatsächlich das Problem! Wie gesagt, wenn ich im internen Netz einen Zeitserver laufen lasse, geht es auf Anhieb mit der default-ntp-config! Ich habe schon in der SuSE-firewall2 versucht, den Port 123 freizugeben (in Yast eingetragen), das hat aber keine Änderung gebracht. Auch wenn ich die firewall deaktiviere klappt es nicht! Irgendwo muß da doch ein Knoten drinnen sein?! Gruß Siegfried
Siegfried Haas wrote:
claus schrieb:
Nur habe ich auf dem Client keine Firewall laufen, mag das der Unterschied sein?
Das ist tatsächlich das Problem! Wie gesagt, wenn ich im internen Netz einen Zeitserver laufen lasse, geht es auf Anhieb mit der default-ntp-config! Ich habe schon in der SuSE-firewall2 versucht, den Port 123 freizugeben (in Yast eingetragen), das hat aber keine Änderung gebracht. Auch wenn ich die firewall deaktiviere klappt es nicht! Irgendwo muß da doch ein Knoten drinnen sein?!
Ich habe auf dem Gateway Server das Susefirewall2 laufen und habe für ntp folgende Ports offen: /etc/sysconfig/SuSEfirewall2: FW_SERVICES_EXT_UDP="ntp" FW_SERVICES_INT_UDP="ntp" FW_SERVICES_EXT_TCP="ntp" FW_SERVICES_INT_TCP="ntp" Ich glaube aber TCP ist nicht nötig ... weiss das jemand genauer? Ich denke sie musst du auf dem Client auch auf machen, da (AFAIR) NTP hin- und hergeschickt wird. http://www.linuxhorizon.ro/ntp.html Bedenke welches Interface (INT, EXT) auf deinem Client das "innere" Netz ist. Das erklärt natürlich nicht warum es ohne Firewall auch nicht läuft. :-( Gruss, Claus
claus schrieb:
Siegfried Haas wrote:
claus schrieb:
Nur habe ich auf dem Client keine Firewall laufen, mag das der Unterschied sein?
Das ist tatsächlich das Problem! Wie gesagt, wenn ich im internen Netz einen Zeitserver laufen lasse, geht es auf Anhieb mit der default-ntp-config! Ich habe schon in der SuSE-firewall2 versucht, den Port 123 freizugeben (in Yast eingetragen), das hat aber keine Änderung gebracht. Auch wenn ich die firewall deaktiviere klappt es nicht! Irgendwo muß da doch ein Knoten drinnen sein?!
Ich habe auf dem Gateway Server das Susefirewall2 laufen und habe für ntp folgende Ports offen: /etc/sysconfig/SuSEfirewall2: FW_SERVICES_EXT_UDP="ntp" FW_SERVICES_INT_UDP="ntp" FW_SERVICES_EXT_TCP="ntp" FW_SERVICES_INT_TCP="ntp" Ich glaube aber TCP ist nicht nötig ... weiss das jemand genauer? Ich denke sie musst du auf dem Client auch auf machen, da (AFAIR) NTP hin- und hergeschickt wird. http://www.linuxhorizon.ro/ntp.html
Bedenke welches Interface (INT, EXT) auf deinem Client das "innere" Netz ist. Das erklärt natürlich nicht warum es ohne Firewall auch nicht läuft. :-(
Gruss, Claus
Danke für die Hilfe bisher, habe die FW-Services in die Firewall eingefügt und außerdem port 123 und 53 (für udp) geöffnet. Aber weiterhin gibt xntpd die Meldung ....failed. Interessant ist die Ausgabe von ntpq -p ntpq : read: Connection refused Also ist da noch immer eine Firewall-Regel, die es zu umschiffen gilt - aber welche?! Grüße Siegfried
Siegfried Haas wrote:
habe die FW-Services in die Firewall eingefügt und außerdem port 123 und 53 (für udp) geöffnet. Aber weiterhin gibt xntpd die Meldung ....failed. Hast du mal in /var/log/warn (u.ä) auf beiden beteiligten Maschinen geforscht un zu sehen ob es da DROPs auf irgendwelchen Paketen. Ausserdem könntest du mal tracen (tcpdump bzw. Ethereal) was sich zwischen den Maschinen tut.
Interessant ist die Ausgabe von ntpq -p ntpq : read: Connection refused Da würde ich mal vermuten, dass die UDP Ports auf deinem inneren Interface des Gateways zu sind, ok du hattest gesagt mit einer anderen Maschine hat es funktionniert, aber prüf das doch noch mal .. logs, traces ...
Also ist da noch immer eine Firewall-Regel, die es zu umschiffen gilt - aber welche?! Es müssten die bereits genannten sein, ich hab auch nix anderes offen nur auf den richtigen Interfaces.
Viel Glück, Claus
Hallo, Siegfried Haas schrieb: [...]
Interessant ist die Ausgabe von ntpq -p ntpq : read: Connection refused
Hast du den Status des NTP-Daemons auf dem Gateway untersucht? Also direkt auf dem Gateway anmelden und dann "ntpq -p" ausführen. Wenn der Daemon nach dem Start eine Zeitabweichung von mehr als ca. 1000 Sekunden feststellt, beendet er sich nach einigen Minuten selbst wieder mit einer Fehlermeldung im Syslog. Anschließend wird natürlich "connection refused", weil kein Daemon mehr läuft, der die Anfrage annimmt. Wenn der Daemon dort läuft, aber nicht synchron ist, wird er von Clients nicht als Zeitquelle akzeptiert. Wenn er synchron ist, wird in der 1. Spalte einer Zeile der Ausgabe ein '*' angezeigt. Wenn das nicht der Fall ist, ist er nicht synchron. Siehe auch: http://www.meinberg.de/german/info/ntp.htm#ntp_status Selbst die aktuellste Version von NTP hat noch Probleme mit Dialup-Verbindungen, denn nur beim Start des Daemons werden die Interfaces initialisiert. Wenn im Betrieb ein Interface heruntergefahren und wieder neu gestartet wird, kann der NTP Daemon darüber nicht mehr kommunizieren. Das betrifft speziell auch DSL, wenn einmal alle 24h die Verbindung zwangsunterbrochen wird und bei der Wiedereinwahl eine neue dynamiche IP-Adress vergeben wird.
Also ist da noch immer eine Firewall-Regel, die es zu umschiffen gilt - aber welche?!
Erst wenn sicher ist, daß der NTP-Daemon auf dem Gateway aktiv und synchron ist, und trotzdem die Clients nicht darauf zugreifen können, sollte mit Firewall-Einstellungen weiter experimentiert werden. Viele Grüße, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany
Martin Burnicki wrote: [...]
Selbst die aktuellste Version von NTP hat noch Probleme mit Dialup-Verbindungen, denn nur beim Start des Daemons werden die Interfaces initialisiert. Wenn im Betrieb ein Interface heruntergefahren und wieder neu gestartet wird, kann der NTP Daemon darüber nicht mehr kommunizieren. Das betrifft speziell auch DSL, wenn einmal alle 24h die Verbindung zwangsunterbrochen wird und bei der Wiedereinwahl eine neue dynamiche IP-Adress vergeben wird.
Ja. Für diesen Fall habe ich auf dem Gateway, welches für die Anbindung an DSL zuständig ist einfach in die /etc/ppp/poll.tcpip /usr/sbin/rcxntpd restart eingetragen. Das funktioniert ganz gut. [...] Benn -- #250319 - http://counter.li.org
Siegfried Haas schrieb:
claus schrieb:
Siegfried Haas wrote:
claus schrieb:
Nur habe ich auf dem Client keine Firewall laufen, mag das der Unterschied sein?
Das ist tatsächlich das Problem! Wie gesagt, wenn ich im internen Netz einen Zeitserver laufen lasse, geht es auf Anhieb mit der default-ntp-config! Ich habe schon in der SuSE-firewall2 versucht, den Port 123 freizugeben (in Yast eingetragen), das hat aber keine Änderung gebracht. Auch wenn ich die firewall deaktiviere klappt es nicht! Irgendwo muß da doch ein Knoten drinnen sein?!
Ich habe auf dem Gateway Server das Susefirewall2 laufen und habe für ntp folgende Ports offen: /etc/sysconfig/SuSEfirewall2: FW_SERVICES_EXT_UDP="ntp" FW_SERVICES_INT_UDP="ntp" FW_SERVICES_EXT_TCP="ntp" FW_SERVICES_INT_TCP="ntp" Ich glaube aber TCP ist nicht nötig ... weiss das jemand genauer? Ich denke sie musst du auf dem Client auch auf machen, da (AFAIR) NTP hin- und hergeschickt wird. http://www.linuxhorizon.ro/ntp.html
Bedenke welches Interface (INT, EXT) auf deinem Client das "innere" Netz ist. Das erklärt natürlich nicht warum es ohne Firewall auch nicht läuft. :-(
Gruss, Claus
Danke für die Hilfe bisher,
habe die FW-Services in die Firewall eingefügt und außerdem port 123 und 53 (für udp) geöffnet. Aber weiterhin gibt xntpd die Meldung ....failed.
Interessant ist die Ausgabe von ntpq -p ntpq : read: Connection refused
Also ist da noch immer eine Firewall-Regel, die es zu umschiffen gilt - aber welche?!
Grüße
Siegfried
Hallo aus Neumünster! Jetzt klappt es! Ich habe in /etc/sysconfig/SuSEfirewall2 eingetragen: FW_SERVICES_EXT_UDP="ntp" FW_SERVICES_INT_UDP="ntp" FW_SERVICES_EXT_TCP="ntp" FW_SERVICES_INT_TCP="ntp" Und die Ports 123 und 53 geöffnet - was fehlte war dann ein reboot! Danach klappte es dann! Ohne die beiden offenen Ports geht es aber nicht! Danke Siegfried
Hallo, claus schrieb:
Siegfried Haas wrote:
claus schrieb:
Nur habe ich auf dem Client keine Firewall laufen, mag das der Unterschied sein?
Das ist tatsächlich das Problem! Wie gesagt, wenn ich im internen Netz einen Zeitserver laufen lasse, geht es auf Anhieb mit der default-ntp-config! Ich habe schon in der SuSE-firewall2 versucht, den Port 123 freizugeben (in Yast eingetragen), das hat aber keine Änderung gebracht. Auch wenn ich die firewall deaktiviere klappt es nicht! Irgendwo muß da doch ein Knoten drinnen sein?!
Ich habe auf dem Gateway Server das Susefirewall2 laufen und habe für ntp folgende Ports offen: /etc/sysconfig/SuSEfirewall2: FW_SERVICES_EXT_UDP="ntp" FW_SERVICES_INT_UDP="ntp" FW_SERVICES_EXT_TCP="ntp" FW_SERVICES_INT_TCP="ntp" Ich glaube aber TCP ist nicht nötig ... weiss das jemand genauer? [...]
Ja. NTP verwendet definitiv nur UTP. Bei der Reservierung des Ports 123 für NTP wurde jedoch wie üblich dieser Port sowohl für UDP als auch für TCP reserviert, daher tauchen in der Datei /etc/services meist beide Zeilen auf: ntp 123/tcp # Network Time Protocol ntp 123/udp # Network Time Protocol Viele Grüße, Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany
participants (4)
-
Bernd Schmelter -
claus -
Martin Burnicki -
Siegfried Haas