it-swarm.com.de

ntpd synchronisiert die Uhr nicht, während ntpdate dies tut

Mein Problem ist ein bisschen ähnlich wie das unten stehende, aber immer noch anders. ntpdate synchronisiert die Uhr erfolgreich, aber ntpd erhält keine Daten zurück, nachdem Abfragen an dieselben Zeitserver gesendet wurden. Die Abweichung meiner Uhr beträgt 1,0-1,5 Sekunden pro Stunde!

ntpdate

$ ntpdate -qv 194.177.4.2
16 Sep 21:45:42 ntpdate[21836]: ntpdate [email protected] Thu Feb 11 18:30:41 UTC 2016 (1)
server 194.177.4.2, stratum 2, offset 17.656685, delay 0.06981
16 Sep 21:45:48 ntpdate[21836]: step time server 194.177.4.2 offset 17.656685 sec

und mit mehr Details

$ ntpdate -qd 212.33.77.42
16 Sep 21:48:32 ntpdate[21841]: ntpdate [email protected] Thu Feb 11 18:30:41 UTC 2016 (1)
Looking for Host 212.33.77.42 and service ntp
Host found : 212.33.77.42
transmit(212.33.77.42)
receive(212.33.77.42)
transmit(212.33.77.42)
receive(212.33.77.42)
transmit(212.33.77.42)
receive(212.33.77.42)
transmit(212.33.77.42)
receive(212.33.77.42)
server 212.33.77.42, port 123
stratum 2, precision -20, leap 00, trust 000
refid [212.33.77.42], delay 0.03363, dispersion 0.00159
transmitted 4, in filter 4
reference time:    db86ca25.1cf0982a  Fri, Sep 16 2016 21:44:37.113
originate timestamp: db86cb28.8dda4c1d  Fri, Sep 16 2016 21:48:56.554
transmit timestamp:  db86cb16.da7f48f5  Fri, Sep 16 2016 21:48:38.853
filter delay:  0.03363  0.03381  0.03365  0.03368 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 17.69400 17.69494 17.69572 17.69653
         0.000000 0.000000 0.000000 0.000000
delay 0.03363, dispersion 0.00159
offset 17.694009

16 Sep 21:48:38 ntpdate[21841]: step time server 212.33.77.42 offset 17.694009 sec

ntpd

$ Sudo ntpd -d4L
ntpd [email protected] Thu Feb 11 18:30:40 UTC 2016 (1)
16 Sep 21:16:47 ntpd[21468]: proto: precision = 2.793 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
Finished Parsing!!
16 Sep 21:16:47 ntpd[21468]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
16 Sep 21:16:47 ntpd[21468]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
16 Sep 21:16:47 ntpd[21468]: Listen normally on 1 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags 00000001
16 Sep 21:16:47 ntpd[21468]: Listen normally on 2 eth0 xxx.116.4.142 UDP 123
restrict: op 1 addr xxx.116.4.142 mask 255.255.255.255 mflags 00003000 flags 00000001
16 Sep 21:16:47 ntpd[21468]: Listen normally on 3 as0t0 172.27.224.1 UDP 123
restrict: op 1 addr 172.27.224.1 mask 255.255.255.255 mflags 00003000 flags 00000001
16 Sep 21:16:47 ntpd[21468]: Listen normally on 4 as0t1 172.27.228.1 UDP 123
restrict: op 1 addr 172.27.228.1 mask 255.255.255.255 mflags 00003000 flags 00000001
16 Sep 21:16:47 ntpd[21468]: Listen normally on 5 as0t2 172.27.232.1 UDP 123
restrict: op 1 addr 172.27.232.1 mask 255.255.255.255 mflags 00003000 flags 00000001
16 Sep 21:16:47 ntpd[21468]: Listen normally on 6 as0t3 172.27.236.1 UDP 123
restrict: op 1 addr 172.27.236.1 mask 255.255.255.255 mflags 00003000 flags 00000001
16 Sep 21:16:47 ntpd[21468]: peers refreshed
16 Sep 21:16:47 ntpd[21468]: Listening on routing socket on fd #23 for interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000005d0
16 Sep 21:16:47 ntpd[21468]: restrict: error in address '::' on line 45. Ignoring...
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
16 Sep 21:16:47 ntpd[21468]: restrict: error in address '::1' on line 49. Ignoring...
key_expire: at 0 associd 45622
peer_clear: at 0 next 1 associd 45622 refid INIT
event at 0 194.177.4.2 8011 81 mobilize assoc 45622
newpeer: xxx.116.4.142->194.177.4.2 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 45623
peer_clear: at 0 next 2 associd 45623 refid INIT
event at 0 212.33.77.42 8011 81 mobilize assoc 45623
newpeer: xxx.116.4.142->212.33.77.42 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 45624
peer_clear: at 0 next 3 associd 45624 refid INIT
event at 0 193.25.222.240 8011 81 mobilize assoc 45624
newpeer: xxx.116.4.142->193.25.222.240 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 45625
peer_clear: at 0 next 4 associd 45625 refid INIT
event at 0 192.86.14.67 8011 81 mobilize assoc 45625
newpeer: xxx.116.4.142->192.86.14.67 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
key_expire: at 0 associd 45626
peer_clear: at 0 next 5 associd 45626 refid INIT
event at 0 91.189.94.4 8011 81 mobilize assoc 45626
newpeer: xxx.116.4.142->91.189.94.4 mode 3 vers 4 poll 6 10 flags 0x1 0x1 ttl 0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
event at 0 0.0.0.0 c011 01 freq_not_set
transmit: at 1 xxx.116.4.142->194.177.4.2 mode 3 len 48
auth_agekeys: at 1 keys 1 expired 0
transmit: at 2 xxx.116.4.142->212.33.77.42 mode 3 len 48
transmit: at 3 xxx.116.4.142->193.25.222.240 mode 3 len 48
transmit: at 4 xxx.116.4.142->192.86.14.67 mode 3 len 48
transmit: at 5 xxx.116.4.142->91.189.94.4 mode 3 len 48
[...]
^C16 Sep 21:17:37 ntpd[21468]: ntpd exiting on signal 2

Ich habe es mit Ctr+C gestoppt. Die beobachteten Fehler scheinen kein Problem zu sein, da sie ignoriert werden.

restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000005d0
16 Sep 21:16:47 ntpd[21468]: restrict: error in address '::' on line 45. Ignoring...
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags 00000000
16 Sep 21:16:47 ntpd[21468]: restrict: error in address '::1' on line 49. Ignoring...

Sie stammen aus diesen Zeilen von /etc/ntp.conf

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

Nach dem Auskommentieren verschwinden die Fehler, aber der Server erhält keine Pakete zurück. Und während der Server läuft, zeigt ntpq -np an, dass er sich im INIT Status befindet (hier mit unterschiedlichem Serverpool).

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 94.154.96.7     .INIT.          16 u    -   64    0    0.000    0.000   0.000
 158.75.5.245    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 193.219.28.147  .INIT.          16 u    -   64    0    0.000    0.000   0.000
 193.219.28.2    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 91.189.89.198   .INIT.          16 u    -   64    0    0.000    0.000   0.000

Ich denke, diese Beweise habe ich kein Problem mit der Firewall. Ich habe auch meinen ISP gefragt. Sie blockieren nichts und bieten keinen lokalen Zeitserver.

cron

Die offensichtliche Problemumgehung, die ich derzeit verwende, ist stündlich geplant ntpdate. Wie von Tim Bielawahier erklärt, funktioniert ntpd durch Anpassen der Länge einer Sekunde auf Ihrem System durch a ein wenig, damit Sie langsam die richtige Zeit erhalten , während ntpdate die Uhr möglicherweise rückwärts stellt, was einige Programme ausflippen lässt.

# m h  dom mon dow   command
@hourly /usr/sbin/ntpdate -u ntp.tp.pl

Aktualisieren

nmap

auf dem Server ausgeführt

$Sudo nmap -p 123 -sU xxx.yyy.zzz.142
Starting Nmap 6.40 ( http://nmap.org ) at 2016-09-19 14:30 CEST
Nmap scan report for example.com (xxx.yyy.zzz.142)
Host is up (0.00021s latency).
PORT    STATE SERVICE
123/udp open  ntp
Nmap done: 1 IP address (1 Host up) scanned in 1.12 seconds

$ Sudo nmap -p 123 -sU example.com
Starting Nmap 6.40 ( http://nmap.org ) at 2016-09-19 14:27 CEST
Nmap scan report for example.com (127.0.1.1)
Host is up.
PORT    STATE         SERVICE
123/udp open|filtered ntp
Nmap done: 1 IP address (1 Host up) scanned in 2.09 seconds

$ Sudo nmap -p 123 -sU localhost
Starting Nmap 6.40 ( http://nmap.org ) at 2016-09-19 14:26 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00018s latency).
Other addresses for localhost (not scanned): 127.0.0.1
rDNS record for 127.0.0.1: localhost.localdomain
PORT    STATE SERVICE
123/udp open  ntp
Nmap done: 1 IP address (1 Host up) scanned in 1.08 seconds

Auf einem Host in einem anderen Land ausgeführt

$ Sudo nmap -p 123 -sU xxx.yyy.zzz.142
Starting Nmap 6.40 ( http://nmap.org ) at 2016-09-19 14:51 CEST
Nmap scan report for example.com (xxx.yyy.zzz.142)
Host is up (0.046s latency).
PORT    STATE         SERVICE
123/udp open|filtered ntp
Nmap done: 1 IP address (1 Host up) scanned in 0.78 seconds

iptables

Obwohl nmap 'STATE open | filters' gemeldet hat, wird iptables für die Übung bereinigt.

$ Sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  

tcpdump

Wird ausgeführt, während unten ausgeführt wurde.

$ Sudo ntpd -d
transmit: at 2 xxx.yyy.zzz.142->94.154.96.7 mode 3 len 48
transmit: at 3 xxx.yyy.zzz.142->194.177.4.2 mode 3 len 48
transmit: at 67 xxx.yyy.zzz.142->94.154.96.7 mode 3 len 48
transmit: at 70 xxx.yyy.zzz.142->194.177.4.2 mode 3 len 48

gab dieses Ergebnis

$ Sudo tcpdump udp port 123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:16:29.733037 IP example.com.ntp > 96-7.cpe.smnt.pl.ntp: NTPv4, Client, length 48
15:16:30.733095 IP example.com.ntp > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:17:34.733013 IP example.com.ntp > 96-7.cpe.smnt.pl.ntp: NTPv4, Client, length 48
15:17:37.733139 IP example.com.ntp > pscolka.of.pl.ntp: NTPv4, Client, length 48

Hier ist ein Speicherauszug für ntpdate -q 194.177.4.2, der erfolgreich war.

15:31:16.790206 IP example.com.48658 > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:31:16.834517 IP pscolka.of.pl.ntp > example.com.48658: NTPv4, Server, length 48
15:31:18.790268 IP example.com.48658 > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:31:18.834546 IP pscolka.of.pl.ntp > example.com.48658: NTPv4, Server, length 48
15:31:20.790210 IP example.com.48658 > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:31:20.834336 IP pscolka.of.pl.ntp > example.com.48658: NTPv4, Server, length 48
15:31:22.790253 IP example.com.48658 > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:31:22.834572 IP pscolka.of.pl.ntp > example.com.48658: NTPv4, Server, length 48

Und als ich das ausgeführt habe

Sudo ntpdate 194.177.4.2 
19 Sep 15:36:19 ntpdate[8123]: no server suitable for synchronization found

die Müllkippe war

15:36:11.856663 IP example.com.ntp > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:36:13.856654 IP example.com.ntp > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:36:15.856640 IP example.com.ntp > pscolka.of.pl.ntp: NTPv4, Client, length 48
15:36:17.856765 IP example.com.ntp > pscolka.of.pl.ntp: NTPv4, Client, length 48

Anmerkung

Während einer von vielen Tests $ Sudo ntpd -d konnte ich folgendes beobachten.

receive: at 1618 xxx.yyy.zzz.142<-178.39.91.211 mode 3 len 48
transmit: at 1618 xxx.yyy.zzz.142->178.39.91.211 mode 4 len 48
receive: at 1618 xxx.yyy.zzz.142<-178.39.91.211 mode 3 len 48

Server 178.39.91.211 ist nicht in meiner Konfiguration. Ich vermute, ein anderer Host hat meinen Server gefragt, wie spät es ist. Das heißt, eingehende Kommunikation über Port 123 ist möglich? Ich habe oben kein tcpdump -Log, aber ntpd lauscht nur am Port 123. Ich habe Dump für ähnliche Veranstaltung, leider ohne Antwort:

15:27:29.313748 IP 209.126.136.2.42440 > example.com.ntp: NTPv2, Reserved, length 12

Ich habe den Eindruck, dass es nicht möglich ist, Pakete von meinem Server über Port 123 zu versenden. Der ISP, der erneut gefragt wurde, bestreitet immer noch, dass er alles blockieren würde.

Update 2

Schließlich hat mein ISP bestätigt, dass der vorherige ISP den Quellport 123 auf meiner IP-Adresse blockiert. Ich folgte dem folgenden Vorschlag von Bill Thor und fügte NAT Regel zu meinem iptables hinzu, wodurch der Quellport 123 in einen anderen geändert wird, wenn der Zielport ebenfalls 123 ist.

$ Sudo iptables -t nat -A POSTROUTING -p udp -s xxx.yyy.zzz.142 --sport 123 --dport 123 -j SNAT --to-source xxx.yyy.zzz.142:12345

Jetzt empfängt mein ntp Server Antworten von anderen Zeitservern.

$ Sudo tcpdump udp port 123
14:31:29.875903 IP example.com.12345 > pscolka.of.pl.ntp: NTPv4, Client, length 48
14:31:29.921176 IP pscolka.of.pl.ntp > example.com.12345: NTPv4, Server, length 48
14:32:30.875809 IP example.com.12345 > ntp.task.gda.pl.ntp: NTPv4, Client, length 48
14:32:30.882699 IP ntp.task.gda.pl.ntp > example.com.12345: NTPv4, Server, length 48
14:32:33.875963 IP example.com.12345 > pscolka.of.pl.ntp: NTPv4, Client, length 48
14:32:33.920863 IP pscolka.of.pl.ntp > example.com.12345: NTPv4, Server, length 48

Und meine ntp Berichte wie unten.

$ ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 2001:67c:1560:8 .STEP.          16 -    - 1024    0    0.000    0.000   0.000
*153.19.250.123  212.244.36.227   2 u   20   64  377    6.785   -0.791   9.129
 194.177.4.2     80.50.231.226    2 u   64   64    0    0.000    0.000   0.000
1
BCT

Die Tatsache, dass alle Server mit einer .INIT. -Refid blockiert sind, zeigt an, dass Sie keine Verbindung zum Server herstellen können. Sobald Sie eine Verbindung zu einem Server hergestellt haben, wird dieser Wert zur bevorzugten Quelle für diesen Server.

Anscheinend können Sie die Poolserver nicht erreichen. Versuchen Sie, eine server mit der IP-Adresse 194.177.4.2 zu Ihrer ntp.conf -Datei hinzuzufügen.

Seitdem Amplification-Attacken zu einem Problem wurden, habe ich festgestellt, dass Probleme beim Herstellen einer Verbindung zu NTP-Servern über IPv4 auftreten. Ich habe einen IPv6-Tunnel, mit dem ich über IPv6 eine Verbindung zu Poolservern herstellen kann.

Diese Konfiguration funktioniert möglicherweise für Sie. Ich habe meine Schlüssel- und Statistikkonfiguration ausgelassen.

 Driftdatei /var/lib/ntp/ntp.drift[.____.[.____.# Verwenden Sie Server aus dem NTP Pool-Projekt. Genehmigt vom Ubuntu Technical Board 
 Pool 2.ubuntu.pool.ntp.org iburst 
 Server 194.177.4.2. maxpoll 17 iburst 
 
 # Standardmäßig Zeit mit allen austauschen, aber keine Konfiguration zulassen. 
 einschränken -4 default kod notrap nomodify nopeer noquery limited 
 einschränken -6 default kod notrap nomodify nopeer noquery limited 
 
 # Lokale Benutzer können den NTP-Server genauer abfragen. 
 Einschränken 127.0.0.1 
 Einschränken :: 1 
 einschränken 10.0.0.0 Maske 255.0.0.0 kod nomodify notrap notrust noserve limited 
 einschränken 172.16.0.0 Maske 255.31.0.0 kod nomodify notrap notrust 
 einschränken 192.168.0.0 Maske 255.255.0.0 kod nomodify notrap notrust 
 einschränken 2001: 470: c3c :: 0 mask ffff: ffff: ffff :: kod nomodify notrap notrust 
 
 # Erforderlich zum Hinzufügen von Pooleinträgen 
 Quelle einschränken notrap nomodify noquery 

Einige Optionen bewirken, dass ntpdate einen nicht privilegierten Port verwendet, was zu einem anderen Verhalten führen kann als bei einer Verbindung über Port 123. ntp verwendet immer Port 123. Ihr tcpdump gibt an, dass es sich um Server handelt Antworten Sie nicht auf Ihre Anfragen, wenn diese von Port 123 stammen. Dadurch werden Verstärkungsangriffe abgebrochen.

Ich bin jetzt schon eine Weile auf Ihr Problem mit IPv4 gestoßen. Ich habe mit dem Befehl traceroute --sport=123 -p 123 94.154.96.7 überprüft, dass der Datenverkehr nicht blockiert wird, wenn beide Ports 123 sind. Ich habe zwei Verhaltensweisen gefunden:

  • Erreichbare Server lehnen es ab, Zeit bereitzustellen. oder
  • Ein Netzwerk-Gateway blockiert den Datenverkehr, wenn beide Ports 123 sind.

In beiden Fällen wird die Zeit zugestellt, wenn einer der Quellports nicht 123 ist.

Ich habe eine Problemumgehung gefunden, indem ich eine zweite IP-Adresse auf dem Host verwendet habe und IP-Tabellen maskiert habe. Ich verwende shorewall, um meine Firewall zu erstellen, sodass ich eine Maskeraderegel hinzugefügt habe:

#INTERFACE SOURCE ADDRESS PROTO PORT (S) 
 Eth0 192.0.2.4 192.0.2.5:200-300:persistent udp 123

Dies scheint zu den folgenden Regeln zu führen.

-A POSTROUTING -o eth0 -j eth0_masq
-A eth0_masq -s 192.0.2.4 -p 17 --dport 123 -j SNAT --to-source 192.0.2.5:200-300 --persistent

Ich habe das noch nicht vollständig getestet, aber es funktioniert für kürzere Auszeiten.

2
BillThor

ntpdate verwendet einen Port mit höherer Nummer, um eine Abfrage zu senden. Wenn also Port 123 "nach innen" blockiert ist, aktualisiert ntpdate die Zeit, aber ntpd schlägt fehl.

0
rajeev