[Eisfair] ntp tut's nicht

[Hendrik Orep]

Moin und ein frohes neues,

das Thema ist zwar schon ein paar Monate alt, aber falls noch jemand mal
das Problem haben sollte, wollte ich gerne trotzdem noch meine
Erfahrungen dazu teilen.

Am 15.08.2017 um 09:49 schrieb Jürgen Pfautsch:
> Hi NG,
> 
> folgende Ausgabe:
> eis2 # ntpq -p
>     remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> 
> 103.245.79.2    .INIT.          16 u    -   64    0    0.000    0.000 0.000
> ntp02.cpe.rmutt .INIT.          16 u    -   64    0    0.000    0.000 0.000
> time1.isu.net.s .INIT.          16 u    -   64    0    0.000    0.000 0.000
> ns2.cidc.com.kh .INIT.          16 u    -   64    0    0.000    0.000 0.000
> 
[…]
> Per Ping sind alle Server erreichbar, aber ein manueller Abgleich
> schlägt fehl mit
> Try to set Time via 3.kh.pool.ntp.org ...
> 15 Aug 14:33:17 ntpdate[5450]: no server suitable for synchronization found
> etc.

Das selbe Problem hatte ich auch ein paar Monate lang. Nach längerer
Fehlersuche konnte ich zumindest bei mir die Ursache vor einiger Zeit
herausfinden.

tl;dr: Die Einstellung "DoS Protection" in meinem Zyxel-Switch war schuld.

Langversion:
Genau wie bei Jürgen aktualisierte der ntpd auf meinem Eisfair-Server
die Uhrzeit nicht mehr. Die Zeitserver waren auch per ping erreichbar,
eine manueller Abgleich über den entsprechenden Menüpunkt schlug
ebenfalls fehl. Auch die Verwendung anderer NTP-Server brachte keine
Änderung.
Das Problem trat zeitgleich auch auf einem Rechner mit Debian Jessie
auf, wo eine andere ntp-Version installiert war.

Zunächst hatte ich das Problem bei mir gelöst indem ich auf den
betroffenen Systemen chrony [1] manuell eingerichtet hatte. Hiermit
klappte ein Zeitabgleich mit den gleichen Servern, welche in der
NTP-Konfiguration eingetragen waren.
Im Unterschied zum ntpd verwendet chrony für ntp-Anfragen
unprivilegierte Ports aus einem höheren Bereich.
Bei einem ntpdate-Aufruf lässt sich dieses Verhalten durch anhängen des
Parameters -u erzwingen. Ein "ntpdate de.pool.ntp.org" schlug also fehl,
ein "ntpdate -u de.pool.ntp.org" war aber erfolgreich.

Daraufhin hatte ich den Verdacht, dass der Router (in diesem Fall war
das eine Fritzbox) hier etwas blockt, zumal diese ja selber einen
NTP-Server im Netz bereitstellt (übrigens wohl auch chronyd).
Praktischerweise bietet dieses Gerät die Möglichkeit den Traffic
mitzuschneiden, so dass man diesen in Wireshark analysieren kann.
Hierbei stellte sich heraus, dass beim Router überhaupt keine NTP-Pakete
vom Eisfair und dem Debian ankamen, wenn deren ntpd lief. Die Pakete vom
chronyd und von ntpdate -u waren jedoch zu sehen.

Danach habe ich den Laptop mit Wireshark mal direkt in einen Port an den
Switch, der zwischen dem Eisfair und dem Router ist, gesteckt und den
Port zum Eisfair an diesen gespiegelt und mir die Pakete angesehen. Man
konnte hier sehen, dass ntpd auf dem Eisfair Pakete verschickt. Auf dem
Router waren aber keine ankommenden Pakete zu sehen gewesen.

Im Zyxel-Switch, der zwischen Eisfair-Server und Router hängt, gibt es
unter dem Punkt "Security" die Option "DoS". Laut der Anleitung soll
diese Option verschiedene "Denial of Service"-Attacken verhindern könne.
Man kann jedoch die Arten nicht einzeln auswählen, sondern die Option
nur als ganzes aktivieren. Eine der DoS-Arten wird in der Anleitung als
"Blat Attack" genannt, und damit beschrieben, dass Pakete dabei
verschickt werden, bei denen Quell- und Zielport identisch sind.

Der normale ntpd verschickt jedoch UDP-Pakete mit dem Sourceport 123 an
den NTP-Server mit Destination-Port 123/udp. Diese Pakete werden also
kommentarlos gefiltert.

Nachdem ich diese Option im Switch deaktiviert habe, läuft die
Zeitsynchronisation mit ntp nun wieder einwandfrei. Auch ein (mir nicht
so wichtig gewesenes, deshalb nicht weiter untersuchtes) Problem mit dem
Asterisk, der sich nicht am SIP-Server registrieren wollte, ließ sich so
beheben.


Vielleicht ist dieser Bericht ja noch mal für jemanden nützlich, wenn er
das selbe Problem hat oder Ansätze zur Fehlersuche gebrauchen kann.

Gruß
Hendrik

PS: Danke für das ständige Weiterentwickeln und Pflegen von Eisfair!

[1] https://chrony.tuxfamily.org/