ntpd не синхронизирует часы, в то время как ntpdate делает
Моей проблемой является бит, подобный тем, которые ниже, но все еще отличающийся. ntpdate синхронизации синхронизируют успешно, но ntpd не возвращает данных после передачи запросов к тому же серверу (серверам) времени. Дрейф моих часов 1.0-1.5s в час!
- сервер ntpd всегда в режиме 'INIT'
- ntpdate: никакой сервер, подходящий для синхронизации, не найден
- ntpd не синхронизирует часы автоматически
ntpdate
$ ntpdate -qv 194.177.4.2
16 Sep 21:45:42 ntpdate[21836]: ntpdate 4.2.6p5@1.2349-o 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
и с большим количеством деталей
$ ntpdate -qd 212.33.77.42
16 Sep 21:48:32 ntpdate[21841]: ntpdate 4.2.6p5@1.2349-o 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 4.2.6p5@1.2349-o 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
Я остановил его с Ctr+C. Наблюдаемые ошибки, кажется, не проблема, как проигнорированы.
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...
Они источник от этих строк/etc/ntp.conf
# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1
После комментария их исчезают ошибки, но сервер все еще не получает пакетов назад. И в то время как сервер работает, ntpq -np шоу это находится в состоянии INIT (здесь с другим пулом серверов).
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
Я предполагаю это доказательства, у меня нет связанной с брандмауэром проблемы. Я также спросил свой ISP. Они ничего не блокируют и не предлагают сервер местного времени.
крон
Очевидное обходное решение, которое я в настоящее время использую, каждый час планируется ntpdate. Однако, как объяснено Tim Bielawa здесь, ntpd работы путем корректировки продолжительности секунды в системе небольшим битом так, чтобы Вы медленно получили корректное время, в то время как ntpdate может скорректировать часы назад, которые могли бы волновать некоторые программы.
# m h dom mon dow command
@hourly /usr/sbin/ntpdate -u ntp.tp.pl
Обновление
nmap
выполняемый на сервере
$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
Выполняемый на хосте в другой стране
$ 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
Хотя nmap 'СОСТОЯНИЕ, о котором сообщают, open|filtered' мой iptables очищены для осуществления.
$ 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
Выполняемый, в то время как ниже работал.
$ 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
дал этот результат
$ 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
Вот дамп для ntpdate -q 194.177.4.2, который был успешен.
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
И когда я выполнил это
sudo ntpdate 194.177.4.2
19 Sep 15:36:19 ntpdate[8123]: no server suitable for synchronization found
дамп был
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
Комментарий
В то время как один из многих тестов $ sudo ntpd -d Я мог наблюдать ниже.
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
Сервер 178.39.91.211 не находится в моей конфигурации. Я предполагаю, что некоторый другой хост спросил мой сервер, 'каково время?' Означая, входящая коммуникация на порте 123 возможно? Я не имею tcpdump журнал для вышеупомянутого, но ntpd слушает только на порте 123. У меня есть дамп для подобного события, к сожалению, без ответа:
15:27:29.313748 IP 209.126.136.2.42440 > example.com.ntp: NTPv2, Reserved, length 12
У меня есть впечатление, не возможно отослать пакеты с моего сервера на порте 123. ISP, который спрашивают снова все еще, отклоняет, они заблокировали бы что-либо.
Обновление 2
Наконец, мой ISP подтвердил что прецедент исходный порт блоков ISP 123 на моем IP-адресе. Я следовал ниже предложения от Bill Thor и добавил правило NAT к моему iptables который изменяет исходный порт 123 на другой, если целевой порт равняется также 123.
$ 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
Теперь, мой ntp сервер получает ответы от других серверов времени.
$ 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
И мой ntpотчеты согласно ниже.
$ 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
2 ответа
Факт все серверы застревают с .INIT. ремонт, указывает, что Вы не можете установить соединение с сервером. После того как Вы подключаете к серверу это значение изменения в предпочтительном источнике для того сервера.
кажется, что Вы не можете достигнуть серверов пула. Попытайтесь добавить server с IP-адресом 194.177.4.2 к Вашему ntp.conf файл.
, Так как нападения усиления стали проблемой, я нашел, что у меня есть проблемы, соединяющиеся с серверами ntp по IPv4. У меня есть туннель IPv6, который позволяет мне соединяться с серверами пула по IPv6.
Эта конфигурация может работать на Вас. Я опустил свой ключ и конфигурацию статистики.
driftfile /var/lib/ntp/ntp.drift # Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board pool 2.ubuntu.pool.ntp.org iburst server 194.177.4.2. maxpoll 17 iburst # By default, exchange time with everybody, but don't allow configuration. restrict -4 default kod notrap nomodify nopeer noquery limited restrict -6 default kod notrap nomodify nopeer noquery limited # Local users may interrogate the ntp server more closely. restrict 127.0.0.1 restrict ::1 restrict 10.0.0.0 mask 255.0.0.0 kod nomodify notrap notrust noserve limited restrict 172.16.0.0 mask 255.31.0.0 kod nomodify notrap notrust restrict 192.168.0.0 mask 255.255.0.0 kod nomodify notrap notrust restrict 2001:470:c3c::0 mask ffff:ffff:ffff:: kod nomodify notrap notrust # Needed for adding pool entries restrict source notrap nomodify noquery
опции Some заставят ntpdate использовать непривилегированный порт, который может привести к другому поведению, чем если бы Вы соединяетесь от порта 123. ntp будет всегда использовать порт 123. Ваш tcpdump указывают, что серверы не отвечают на Ваши запросы, когда они происходят из порта 123. Это повредит нападения усиления.
я сталкивался с Вашей проблемой о IPv4 некоторое время теперь. Я проверил, что трафик не заблокирован, когда оба порта 123 с командой traceroute --sport=123 -p 123 94.154.96.7. Я нашел два поведения:
- Серверы, которые являются достижимым мусором для отбытия срок службы; или
- трафик блоков сетевого шлюза А, когда оба порта равняются 123.
В любом случае, срок отбыт, если один из исходного порта не 123.
я нашел обходное решение с помощью второго IP, который я имею на подмене IP таблиц и хосте. Я использую shorewall для создания моего брандмауэра, таким образом, я добавил правило подмены:
#INTERFACE SOURCE ADDRESS PROTO PORT(S) eth0 192.0.2.4 192.0.2.5:200-300:persistent udp 123
Это, кажется, приводит к следующим правилам.
-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
я не полностью протестировал это, но это работает на для более коротких тайм-аутов.
ntpdate использует более высокий порт числа для отправки запроса. таким образом, когда порт 123 заблокирован 'внутрь', затем ntpdate обновит время, но ntpd перестанет работать.