[gelöst] NTP synchronisiert nicht

Started by dsecure, July 28, 2021, 11:18:35 PM

Previous topic - Next topic
July 28, 2021, 11:18:35 PM Last Edit: July 29, 2021, 02:55:47 PM by dsecure
Hallo,

heute ist mir aufgefallen, dass NTP nicht mehr synchronisiert, hatte gehofft mit dem Update auf 21.7 behebt  sich das Problem von alleine.

Einige Versuche, das Problem einzugrenzen:

root@opnsense:~ # ntpd -q -g
28 Jul 23:11:44 ntpd[41978]: ntpd 4.2.8p15@1.3728-o Thu Jul 22 12:42:44 UTC 2021 (1): Starting
28 Jul 23:11:44 ntpd[41978]: Command line: ntpd -q -g
28 Jul 23:11:44 ntpd[41978]: ----------------------------------------------------
28 Jul 23:11:44 ntpd[41978]: ntp-4 is maintained by Network Time Foundation,
28 Jul 23:11:44 ntpd[41978]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
28 Jul 23:11:44 ntpd[41978]: corporation.  Support and training for ntp-4 are
28 Jul 23:11:44 ntpd[41978]: available at https://www.nwtime.org/support
28 Jul 23:11:44 ntpd[41978]: ----------------------------------------------------
28 Jul 23:11:44 ntpd[41978]: proto: precision = 0.420 usec (-21)
28 Jul 23:11:44 ntpd[41978]: getconfig: Couldn't open </etc/ntp.conf>: No such file or directory
28 Jul 23:11:44 ntpd[41978]: unable to bind to wildcard address :: - another process may be running - EXITING


root@opnsense:~ # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
time.cloudflare .INIT.          16 u    -   64    0    0.000   +0.000   0.000
a08.alphasrv.ne .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ntp2.m-online.n .INIT.          16 u    -   64    0    0.000   +0.000   0.000
5.145.135.89 (s .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ptbtime1.ptb.de .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ptbtime2.ptb.de .INIT.          16 u    -   64    0    0.000   +0.000   0.000
ptbtime3.ptb.de .INIT.          16 u    -   64    0    0.000   +0.000   0.000
lucy.thehomeofa .INIT.          16 u    -   64    0    0.000   +0.000   0.000
clock2.infonet. .INIT.          16 u    -   64    0    0.000   +0.000   0.000
where-you.at    .INIT.          16 u    -   64    0    0.000   +0.000   0.000


root@opnsense:~ # ntptime
ntp_gettime() returns code 5 (ERROR)
  time e4ac4b00.de4dd000  Wed, Jul 28 2021 23:30:40.868, (.778868375),
  maximum error 16640000 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 41.639 ppm, interval 4 s,
  maximum error 16640000 us, estimated error 16000000 us,
  status 0x41 (PLL,UNSYNC),
  time constant 3, precision 0.000 us, tolerance 496 ppm,
  pps frequency 41.639 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.


Warum synchronisiert NTP nicht mehr, was kann ich tun?

Was ich ebenfalls probiert hatte war, den Dienst neu zu installieren, leider hat dies auch nichts gebracht. Laut Firewallprotokoll, sind die NTP Server über den Port 123 erreichbar.

Allerdings verstehe ich nachfolgend nicht, warum NTP keine Daten bekommt?

root@opnsense:~ # ntpdate -d 0.opnsense.pool.ntp.org
29 Jul 00:22:05 ntpdate[91089]: ntpdate 4.2.8p15@1.3728-o Thu Jul 22 12:42:45 UTC 2021 (1)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
transmit(144.76.76.107)
transmit(162.159.200.123)
transmit(194.36.144.87)
transmit(185.242.112.53)
144.76.76.107: Server dropped: no data
162.159.200.123: Server dropped: no data
194.36.144.87: Server dropped: no data
185.242.112.53: Server dropped: no data

29 Jul 00:22:14 ntpdate[91089]: no server suitable for synchronization found


Anmerkung: NTP kann über 0.opnsense.pool.ntp.org von einer andere Sense problemlos synchronisiert werden.

Okay, ich glaube ich habe eine Idee. Mein gesamter LAN traffic geht über einen TCPStack von zwei DSL Anschlüssen zu einem VPS. Nun habe ich mit einer test Linux Server VM, direkt über eine der beiden DSL Leitungen NTP synchronisiert und siehe da, hier erhalte ich eine Antwort.

root@debian-test-server:/# nano /etc/hosts
root@debian-test-server:/# ntpdate -d 0.opnsense.pool.ntp.org
29 Jul 03:49:18 ntpdate[505]: ntpdate 4.2.8p12@1.3728-o (1)
Looking for host 0.opnsense.pool.ntp.org and service ntp
213.172.105.106 reversed to ns1.blazing.de
host found : ns1.blazing.de
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)
transmit(213.172.105.106)
receive(213.172.105.106)
transmit(217.144.138.234)
receive(217.144.138.234)
transmit(185.120.22.14)
receive(185.120.22.14)
transmit(136.243.66.91)
receive(136.243.66.91)

server 213.172.105.106, port 123
stratum 2, precision -20, leap 00, trust 000
refid [213.172.96.14], root delay 0.000351, root dispersion 0.000183
transmitted 4, in filter 4
reference time:    e4ac8777.f0ffc7a5  Thu, Jul 29 2021  3:48:39.941
originate timestamp: e4ac87a4.ceff8897  Thu, Jul 29 2021  3:49:24.808
transmit timestamp:  e4ac87a6.163b49c7  Thu, Jul 29 2021  3:49:26.086
filter delay:  0.05145  0.05064  0.05032  0.05026
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.29039 -1.29048 -1.29036 -1.29064
         0.000000 0.000000 0.000000 0.000000
delay 0.05026, dispersion 0.00020
offset -1.290640

server 217.144.138.234, port 123
stratum 2, precision -18, leap 00, trust 000
refid [26.91.187.18], root delay 0.015701, root dispersion 0.022079
transmitted 4, in filter 4
reference time:    e4ac8613.e9786818  Thu, Jul 29 2021  3:42:43.911
originate timestamp: e4ac87a5.028c3053  Thu, Jul 29 2021  3:49:25.009
transmit timestamp:  e4ac87a6.496ea449  Thu, Jul 29 2021  3:49:26.286
filter delay:  0.05415  0.05365  0.05389  0.05379
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.29105 -1.29096 -1.29068 -1.29108
         0.000000 0.000000 0.000000 0.000000
delay 0.05365, dispersion 0.00012
offset -1.290967

server 185.120.22.14, port 123
stratum 2, precision -25, leap 00, trust 000
refid [131.188.3.221], root delay 0.003952, root dispersion 0.001129
transmitted 4, in filter 4
reference time:    e4ac8779.ef297fc9  Thu, Jul 29 2021  3:48:41.934
originate timestamp: e4ac87a5.35d14eb0  Thu, Jul 29 2021  3:49:25.210
transmit timestamp:  e4ac87a6.7c9df6e5  Thu, Jul 29 2021  3:49:26.486
filter delay:  0.05252  0.05127  0.05148  0.05136
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.28956 -1.28937 -1.28964 -1.28950
         0.000000 0.000000 0.000000 0.000000
delay 0.05127, dispersion 0.00014
offset -1.289373

server 136.243.66.91, port 123
stratum 2, precision -24, leap 00, trust 000
refid [178.189.127.147], root delay 0.016251, root dispersion 0.027786
transmitted 4, in filter 4
reference time:    e4ac84c1.3bbb619e  Thu, Jul 29 2021  3:37:05.233
originate timestamp: e4ac87a5.694e44d5  Thu, Jul 29 2021  3:49:25.411
transmit timestamp:  e4ac87a6.afd2ae70  Thu, Jul 29 2021  3:49:26.686
filter delay:  0.05286  0.05257  0.05267  0.05238
         0.00000  0.00000  0.00000  0.00000
filter offset: -1.28890 -1.28866 -1.28893 -1.28885
         0.000000 0.000000 0.000000 0.000000
delay 0.05238, dispersion 0.00011
offset -1.288854

29 Jul 03:49:26 ntpdate[505]: step time server 213.172.105.106 offset -1.290640 sec


Das erklärt auch warum das mit der anderen Sense funktioniert, die verwendet ebenfalls als standard Gateway nur eine der DSL Leitungen... aber seit wann blocken die das im Rechenzentrum und warum, hat doch bisher immer funktoniert?

Wie kann ich nun NTP per FW Rule auf einen der anderen GW's umleiten, wenn mir da noch jemand behilflich sein könnte^^ würde gerne die Zeitauflösung über meine Primäre Sense für das interne LAN zur Verfügung stellen? :)

Nur fürs Protokoll, habe es selber gelöst in dem ich die beiden anderen Anschlüsse noch als Gateways hinzugefügt habe, also keine Portweiterleitung oder Ähnliches erforderlich. Jetzt funktioniert die Synchronisierung mittels NTP wieder.