Ich versuche, einen NTP-Server für mein lokales Netzwerk einzurichten, aber ntpd weigert sich, die Synchronisierung mit externen Servern durchzuführen.
# ntptrace
localhost: stratum 16, offset 0.000000, synch distance 0.396285
# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
31.135.95.60 .INIT. 16 u - 1024 0 0.000 0.000 0.000
31.131.249.26 .INIT. 16 u - 1024 0 0.000 0.000 0.000
91.122.42.73 .INIT. 16 u - 1024 0 0.000 0.000 0.000
194.190.168.1 .INIT. 16 u - 1024 0 0.000 0.000 0.000
Die von mir verwendete Konfiguration ist so ziemlich die Standardkonfiguration:
# grep ^[^#] /etc/ntp.conf
server 0.gentoo.pool.ntp.org
server 1.gentoo.pool.ntp.org
server 2.gentoo.pool.ntp.org
server 3.gentoo.pool.ntp.org
driftfile /var/lib/ntp/ntp.drift
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]
restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap
disable monitor
Das Seltsame ist, dass ich einen anderen NTP-Server im LAN habe, der gut funktioniert und synchronisiert. Ich habe also nicht den UDP-Port 123 dafür verantwortlich gemacht, sondern ihn zur Sicherheit explizit auf dem Gateway geöffnet, auf dem ich versuche, NTPD zu starten.
# iptables -L -n -v
Chain INPUT (policy ACCEPT 839K packets, 836M bytes)
pkts bytes target prot opt in out source destination
31696 3023K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
3435 273K ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT udp -- !br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 reject-with icmp-port-unreachable
0 0 REJECT udp -- !br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 reject-with icmp-port-unreachable
0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:123
0 0 DROP tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:0:1023
204 15504 DROP udp -- br1 * 0.0.0.0/0 0.0.0.0/0 udp dpts:0:1023
0 0 DROP tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:2049
0 0 DROP udp -- br1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:2049
0 0 DROP tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:32765:32768
0 0 DROP udp -- br1 * 0.0.0.0/0 0.0.0.0/0 udp dpts:32765:32768
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- br0 * 0.0.0.0/0 192.168.0.0/16
21579 1859K ACCEPT all -- br0 * 192.168.0.0/16 0.0.0.0/0
21307 6910K ACCEPT all -- br1 * 0.0.0.0/0 192.168.0.0/16
Chain OUTPUT (policy ACCEPT 762K packets, 151M bytes)
pkts bytes target prot opt in out source destination
br0 ist LAN und br1 ist WAN.
Ein Versuch, eine Verbindung zu einem Stratum 2-Server herzustellen (das ist auf dem anderen Server zu sehen, auf dem ntpd einwandfrei funktioniert):
# ntpdate -d 95.213.132.250
2 May 07:35:30 ntpdate[9987]: ntpdate [email protected] Fri May 1 20:36:27 UTC 2015 (1)
transmit(95.213.132.250)
receive(95.213.132.250)
transmit(95.213.132.250)
receive(95.213.132.250)
transmit(95.213.132.250)
receive(95.213.132.250)
transmit(95.213.132.250)
receive(95.213.132.250)
server 95.213.132.250, port 123
stratum 2, precision -21, leap 00, trust 000
refid [95.213.132.250], delay 0.03688, dispersion 0.00314
transmitted 4, in filter 4
reference time: d8eeccd9.08f19253 Sat, May 2 2015 7:11:05.034
originate timestamp: d8eed298.9d09bba6 Sat, May 2 2015 7:35:36.613
transmit timestamp: d8eed298.9ae29d48 Sat, May 2 2015 7:35:36.605
filter delay: 0.04114 0.04720 0.04874 0.03688
0.00000 0.00000 0.00000 0.00000
filter offset: 0.004748 0.008231 0.008865 0.002733
0.000000 0.000000 0.000000 0.000000
delay 0.03688, dispersion 0.00314
offset 0.002733
2 May 07:35:36 ntpdate[9987]: adjust time server 95.213.132.250 offset 0.002733 sec
Ich versuche, eine Ausgabe von ntpd zu erhalten
# ntpd -gqd
2 May 07:45:35 ntpd[20292]: ntpd [email protected] Fri May 1 20:36:26 UTC 2015 (1): Starting
2 May 07:45:35 ntpd[20292]: Command line: ntpd -gqd
2 May 07:45:35 ntpd[20292]: proto: precision = 0.051 usec (-24)
2 May 07:45:35 ntpd[20292]: Listen and drop on 0 v4wildcard 0.0.0.0:123
2 May 07:45:35 ntpd[20292]: Listen normally on 1 lo 127.0.0.1:123
2 May 07:45:35 ntpd[20292]: Listen normally on 2 br0 192.168.0.1:123
2 May 07:45:35 ntpd[20292]: Listen normally on 3 br0 192.168.0.9:123
2 May 07:45:35 ntpd[20292]: Listen normally on 4 br0 192.168.0.17:123
2 May 07:45:35 ntpd[20292]: Listen normally on 5 br1 192.168.42.250:123
2 May 07:45:35 ntpd[20292]: Listening on routing socket on fd #22 for interface updates
2 May 07:45:35 ntpd[20292]: restrict: ignoring line 51, address/host '[::1]' unusable.
^C 2 May 07:45:44 ntpd[20292]: ntpd exiting on signal 2 (Interrupt)
2 May 07:45:44 ntpd[20292]: 46.8.40.31 local addr 192.168.42.250 -> <null>
2 May 07:45:44 ntpd[20292]: 217.70.19.12 local addr 192.168.42.250 -> <null>
2 May 07:45:44 ntpd[20292]: 89.208.145.140 local addr 192.168.42.250 -> <null>
2 May 07:45:44 ntpd[20292]: 31.135.95.60 local addr 192.168.42.250 -> <null>
Wie man am Anfang sehen kann ^C, wurde der Daemon manuell unterbrochen, da er nicht wie vorgesehen beendet wurde (auf dem anderen Server wird ntpd nach einer Einschränkungsmeldung mit der Meldung „Zeitüberschreitung“ beendet).
Was auch immer ich mache, die Drift ändert sich auch nach vielen Neustarts nicht:
# cat /var/lib/ntp/ntp.drift
-7.037
Antwort1
Ihre Firewall-Regeln erlauben kein NTP. Die Zeile
0 0 ACCEPT tcp -- br1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:123
ist alles schön und gut, aber NTP ist ein UDP-Dienst. Ändern Sie das Protokoll, und es sollte besser werden. Ihre FORWARDRegeln sind (im Wesentlichen) viel lockerer, permit any anyweshalb der Host im LAN einwandfrei synchronisiert.
Antwort2
Ich habe ein ähnliches Problem mit ntpd[email geschützt]unter OpenWrt 22.03.3 In meinem Fall bindet sich ntpd falsch an Schnittstellen oder verarbeitet Daten von diesen. Als Workaround muss man der conf-Datei Folgendes hinzufügen:
Schnittstelle, hören Sie ethX
Wobei ethX die Schnittstelle ist, über die ntpd Antworten von NTP-Servern abhören soll