Hallo,
ich habe ein Problem mit meinem ntp-Daemon auf meinem Linux-Server.
Der ntpd selbst und einige Zeitserver sind richtig konfiguriert.
Wenn ich den ntpq durchstarte und nachher
ntpq peers
ausführe, bekomme ich:
remote refid st t when poll reach delay offset jitter
==============================================================================
LOCAL(0) 73.78.73.84 5 l 12 64 1 0.000 0.000 0.004
ntp0-rz.rrze.un .INIT. 16 u – 64 0 0.000 0.000 4000.00
ntp1-rz.rrze.un .INIT. 16 u – 64 0 0.000 0.000 4000.00
ntp2-rz.rrze.un .INIT. 16 u – 64 0 0.000 0.000 4000.00
ntp3-rz.rrze.un .INIT. 16 u – 64 0 0.000 0.000 4000.00
hora.cs.tu-berl .PPS. 1 u 7 64 1 28.025 222.602 0.004
sombrero.cs.tu- .PPS. 1 u 6 64 1 28.126 222.380 0.004
ntp1-rz.rrze.un .INIT. 16 u – 64 0 0.000 0.000 4000.00
ntp1.ptb.de .PTB. 1 u 4 64 1 21.517 222.171 0.004
ntp2.ptb.de .PTB. 1 u 3 64 1 27.124 224.404 0.004
rustime01.rus.u .DCFp. 1 u 2 64 1 17.799 221.283 0.004
ntpq>
soweit also alles in Ordnung…
Nur – nach “einiger Zeit” bekomme ich von den externen Servern nichts mehr rein, und das einzige was übrigbleibt ist dann die lokale Uhr, die natürlich entsprechend falsch geht…
Ich hab’ jetzt gerade keinen Screenshot davon da, wenn kein Traffic mehr rein kommt, auf jeden Fall ist z.B. “Jitter” überall auf einem festen Wert, was ja IMHO nicht sein kann…
Jedenfalls: Auf meinem Router läuft natürlich auch iptables aber selbstverständlich habe ich udp port 123 incoming/outgoing erlaubt – sonst würde ja auch generell kein Traffic funktionieren…
Meine einzige Vermutung, warum es irgendwann nicht mehr geht ist nun, dass nach einem DSL-Reconnect nach 24h irgendwie die iptables durcheinanderkommen… Nachdem aber ja udp stateless ist, wäre das auch seltsam…
Kurz noch ein paar Infos zum System:
Basis SuSE 7.2, aber alles selbst geupdatet
DSL Flatrate (always on, wechselnde IP)
IPTables firewall
Hat jemand von Euch eine Idee woran das liegen könnte?
Auszüge aus conf-Dateien kann ich gerne schicken, ich wollte das Posting jedoch zunächst nicht überfrachten!
Danke!
Hallo Markus!
Der ntpd selbst und einige Zeitserver sind richtig konfiguriert.
…
Nur – nach “einiger Zeit” bekomme ich von den externen Servern nichts mehr rein, und das einzige was übrigbleibt ist dann die lokale Uhr, die natürlich entsprechend falsch geht…
…
Meine einzige Vermutung, warum es irgendwann nicht mehr geht ist nun, dass nach einem DSL-Reconnect nach 24h irgendwie die iptables durcheinanderkommen…
…
DSL Flatrate (always on, wechselnde IP)
Mit dem Connection Tracking von iptables hat das nichts zu tun, aber mit der Vermutung, dass es irgenwie an der täglichen DSL Zwangstrennung liegt, bist Du auf der richtigen Spur.
Der ntpd bindet sich an jede einzelne IP Adressen des Systems, was Du auch mit netstat sehen kannst: # netstat -lpnu |grep ntpd udp 0 0 192.168.1.254:123 0.0.0.0:* 26220/ntpd udp 0 0 192.168.1.3:123 0.0.0.0:* 26220/ntpd udp 0 0 10.1.0.1:123 0.0.0.0:* 26220/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 26220/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 26220/ntpd udp6 0 0 :::123 :::* 26220/ntpd
Beim Reconnect nach einer DSL-Zwangstrennung bekommt ppp0 eine andere IP-Adresse. Damit rechnet der ntpd aber nicht, er bleibt weiterhin an die alte IP Adresse gebunden, die auf dem Rechner aber nicht mehr existiert. Alle folgenden NTP Queries ins Internet schlagen fehl. Der ntpd ist nicht für Systeme mit dynamischen IP-Adressen konzipiert.
Workaround: Der pppd bietet die Möglichkeit, nach dem Verbindungsaufbau Skripte auszufühen (bei Debian z.B. unter /etc/ppp/ip-up.d/). Hier kannst Du den ntpd Dienst neustarten (bei Debian z.B. mit /etc/init.d/ntp-server restart).
Harald
Hallo Harald,
sorry, ich habe Deinen Antwort erst heute gesehen!
Vielen Dank für den Hinweis, dass würde den beschriebenen Effekt ja genau erklären! Ich werde Deinen Tipp ausprobieren!
Grüße,
Markus