ntp client syncd nicht

[Colttt]

Hallo,

wir haben hier ein ntp-server für unsere Server am laufen, das ist ein Ubuntu14.04LTS.
Der funktioniert auch und sieht soweit gut aus:

Code: Alles auswählen

ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*178.63.9.110    129.69.1.153     2 u   56  128  377   22.658    0.249   0.053
-85.214.38.116   192.53.103.108   2 u   54  128  377    2.101   -5.105   0.051
+37.58.57.238    192.53.103.103   2 u   50  128  377   20.971    0.839   0.114
+94.130.76.108   192.53.103.108   2 u   56  128  377   24.007   -1.009   0.163

Auf meinen Debian Stretch Servern bekomme ich ein Stratum 16:

Code: Alles auswählen

ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 timeserv.domain.ag .INIT.          16 u    - 1024    0    0.000    0.000   0.000

In Debian Jessie bekomme ich ein stratum 3 und es funktioniert einwandfrei, auch ein 'ntpdate timserv.domain.org' klappt auf allen Servern kann mir das jemand erklären?

Vielen Dank vorab

[heisenberg]

Das folgende schon gelesen?

http://doc.ntp.org/3-5.93e/debug.html

[Colttt]

Ja hab ich, aber irgendwie hilft mir das nicht wirklich weiter:

Code: Alles auswählen

ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 30838  8011   yes    no  none    reject    mobilize  1
ntpq> 
ntpq> 
ntpq> rv 30838
associd=30838 status=8011 conf, sel_reject, 1 event, mobilize,
srcadr=timeserv.domain.ag, srcport=123, dstadr=172.16.101.23,
dstport=123, leap=11, stratum=16, precision=-23, rootdelay=0.000,
rootdisp=0.000, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000,
rec=00000000.00000000  Thu, Feb  7 2036  7:28:16.000, reach=000,
unreach=78, hmode=3, pmode=0, hpoll=10, ppoll=10, headway=0,
flash=1600 peer_stratum, peer_dist, peer_unreach, keyid=0, offset=0.000,
delay=0.000, dispersion=15937.500, jitter=0.000, xleave=0.021,
filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtoffset=    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
filtdisp=   16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
ntpq> 
ntpq> 
ntpq> rv
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p10@1.3728-o Sun Feb 25 21:22:55 UTC 2018 (1)",
processor="x86_64", system="Linux/4.9.0-8-amd64", leap=11, stratum=16,
precision=-23, rootdelay=0.000, rootdisp=1066.485, refid=INIT,
reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000,
clock=e01a1e69.443f887b  Fri, Feb 22 2019  8:08:25.266, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=0.000, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000

da steht nichts drin was ich nicht schon wüsste, nur das WARUM steht da leider nicht.

[dufty2]

reach=000
=> es kommen keine (ntp-)Pakete auf dem ntp-client 172.16.101.23 an:
* Firewall auf ntp-client (172.16.101.23)
* Firewall im Netz
* Firewall auf ntp-server (timeserv.domain.ag)
* IP von timeserv.domain.ag ist falsch bzw. wird falsch aufgeloest
...

Notfalls auf beiden Seiten (ntp-client/ntp-server) mal sniffen
mittels tcpdump / wireshark.

[Colttt]

hiho,

danke für die Info, aber warum geht dann ntpdate?

[mat6937]

..., aber warum geht dann ntpdate?

Welcher Server wird mit ntpdate benutzt?

Code: Alles auswählen

tcpdump -c 200 -vvveni <Interface> udp dst port 123

(Interface anpassen und ohne spitze Klemmern).

[Colttt]

der selbe wenn ich ihn mit angebe

[mat6937]

... ich ihn mit angebe

Und welchen Server gibst Du an?

[Colttt]

meinen Zeitserver.

Code: Alles auswählen

ntpdate timeserv.example.ag
25 Feb 13:42:56 ntpdate[12458]: step time server 194.94.xxx.xxx offset 2.625406 sec

andere maschinen im selben netz funktionieren.

[mat6937]

meinen Zeitserver.

Code: Alles auswählen

ntpdate timeserv.example.ag
25 Feb 13:42:56 ntpdate[12458]: step time server 194.94.xxx.xxx offset 2.625406 sec

andere maschinen im selben netz funktionieren.

Naja, evtl. liegt es an der Namensauflösung. Wie hast Du die "lokale" Namensauflösung (DNS) auf eine öffentliche IPv4-Adresse (hier 194.94.xxx.xxx; die Du anonymisiert hast) konfiguriert?

[Colttt]

die geht auch über unsere namensauflösung, ich hab übrigens auch schon die IP eingetragen, jedoch hat das nichts geändert.

irgendwo hatte ich beiläufig gelesen das die neuen ntp-clients nicht mehr mit den älteren wollen

[mat6937]

Funktioniert das reverse-DNS mit deiner Namensauflösung?

irgendwo hatte ich beiläufig gelesen das die neuen ntp-clients nicht mehr mit den älteren wollen

Das kann ich mir nicht vorstellen. Ist diese IP-Adresse (194.94.xxx.xxx) auf dem UDP-Port 123 aus dem Internet erreichbar? Wenn ja, dann poste man _temporär_ diese IP-Adresse hier, damit ich das testen kann.

[Colttt]

das posten würde nichts nützen, da wir das nur für unsere IP adressen erlauben, desweiteren müsste ich an unserer FW ein paar einstellungen vornehmen

[dufty2]

hiho,

danke für die Info, aber warum geht dann ntpdate?

ntpdate benutzt - wie ein normaler client - Source-Ports > 1023,
während ntpd - als client - auch 123 benutzt, also
<ntp-client-ip>:123 => <ntp-server-ip>:123

[Colttt]

ok guter hinweis, scheint aber auch nicht das problem zu sein:

Code: Alles auswählen

nmap -sU -p 123 --script ntp-info timeserv.example.ag

Starting Nmap 7.40 ( https://nmap.org ) at 2019-02-26 09:25 CET
Nmap scan report for timeserv.example.ag (194.94.xxx.xxx)
Host is up (0.00017s latency).
PORT    STATE SERVICE
123/udp open  ntp
| ntp-info: 
|   receive time stamp: 2019-02-26T08:26:05
|   version: ntpd 4.2.6p5@1.2349-o Fri Jul  6 20:19:54 UTC 2018 (1)
|   processor: x86_64
|   system: Linux/3.13.0-161-generic
|   leap: 0
|   stratum: 3
|   precision: -20
|   rootdelay: 31.589
|   rootdisp: 42.723
|   refid: 178.63.9.110
|   reftime: 0xe01f73ce.3608c5f7
|   clock: 0xe01f768f.e9bd2105
|   peer: 57654
|   tc: 10
|   mintc: 3
|   offset: 0.008
|   frequency: 27.593
|   sys_jitter: 1.020
|   clk_jitter: 0.180
|_  clk_wander: 0.014\x0D
Service Info: OS: Linux/3.13.0-161-generic

Nmap done: 1 IP address (1 host up) scanned in 13.75 seconds

und der Client scheint auch an zufragen, denn ich sehe ihn unter private clients mittels:

Code: Alles auswählen

nmap -sU -pU:123 -Pn -n --script=ntp-monlist timeserv.example.ag

[dufty2]

* ntpd auf ntp-client runterfahren
* tcpdump auf ntp-client anwerfern
* tcpdump auf ntp-server anwerfen
* ntpd auf ntp-client hochfahren
* etwas warten
* ntpd auf ntp-client runterfahren
* tcpdump auf ntp-server stoppen
* tcpdump auf ntp-client stoppen
* ntpd auf ntp-client hochfahren
* beide tcpdumps (ntp-client-seitig wie ntp-server-seitig) miteinander vergleichen:
** ntp-request (auf ntp-client losgeschickt) passt zu ntp-request (auf ntp-server empfangen)?
** ntp-response (auf ntp-server losgeschickt) passt zu ntp-response (auf ntp-client empfangen)?
Falls alles ok, iptables auf ntp-client ggf. kontrollieren,
da "tcpdump" noch vor "iptables" kommt im Netzwerkstack.

[Colttt]

soo endlich mal wieder zeit dafür gehabt.

server und clientseite sehen tcpdump gleich aus..

Code: Alles auswählen

#client fragt:
Network Time Protocol (NTP Version 4, client)
    Flags: 0xe3, Leap Indicator: unknown (clock unsynchronized), Version number: NTP Version 4, Mode: client
    Peer Clock Stratum: unspecified or invalid (0)
    Peer Polling Interval: 6 (64 sec)
    Peer Clock Precision: 0.000000 sec
    Root Delay: 0 seconds
    Root Dispersion: 0 seconds
    Reference ID: (Initialization)
    Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Origin Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Receive Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Transmit Timestamp: Mar 21, 2019 14:23:59.184649604 UTC

#server antwortet:
Network Time Protocol (NTP Version 4, server)
    Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, Mode: server
    Peer Clock Stratum: secondary reference (3)
    Peer Polling Interval: 6 (64 sec)
    Peer Clock Precision: 0.000000 sec
    Root Delay: 0.00921630859375 seconds
    Root Dispersion: 0.020660400390625 seconds
    Reference ID: 129.70.132.35
    Reference Timestamp: Mar 21, 2019 14:23:51.562362183 UTC
    Origin Timestamp: Mar 21, 2019 14:23:59.184649604 UTC
    Receive Timestamp: Mar 21, 2019 14:23:59.170848067 UTC
    Transmit Timestamp: Mar 21, 2019 14:23:59.170907972 UTC

ich versuche das mittlerweile auch mit debian stretch als server, jedoch das selbe problem