O Debian NTP Server não consegue sincronizar

Question

Eu tenho o Debian 8 e o servidor NTP. O problema é que o servidor NTP usa apenas o servidor IP "self" e não sei por que

ntpq -p:

 remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.1.100.11     .INIT.          16 u    -   64    0    0.000    0.000   0.000

ntp.conf:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
tinker panic 0 

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
#server ntp.your-provider.example

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
#server 0.debian.pool.ntp.org iburst
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org


#server tempus1.gum.gov.pl iburst
#server tempus2.gum.gov.pl iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details.  The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 192.168.11.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.10.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.255.0 mask 255.255.255.0 nomodify notrap
restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap

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

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines.  Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

    

Answer 1

Aqui está um diff higienizado da configuração padrão do Debian 8 NTP em sua configuração (excluindo comentários):

0a1
> tinker panic 0 
1a3
> statsdir /var/log/ntpstats/
6,9c8,11
< server 0.debian.pool.ntp.org iburst
< server 1.debian.pool.ntp.org iburst
< server 2.debian.pool.ntp.org iburst
< server 3.debian.pool.ntp.org iburst
---
> server 0.pool.ntp.org
> server 1.pool.ntp.org
> server 2.pool.ntp.org
> server 3.pool.ntp.org
11a14,17
> restrict 192.168.11.0 mask 255.255.255.0 nomodify notrap
> restrict 192.168.10.0 mask 255.255.255.0 nomodify notrap
> restrict 192.168.255.0 mask 255.255.255.0 nomodify notrap
> restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap
13d18
< restrict ::1

Nenhuma dessas alterações provavelmente causou problemas com a conectividade upstream. Quando eu coloco sua configuração no lugar em uma VM, isso resulta em uma configuração de trabalho (embora eu recomende manter as linhas de servidor padrão no lugar em vez de suas substituições).

Portanto, parece que o que está causando o seu problema é externo a essa máquina em particular. Algumas sugestões para restringir o problema:

Confirme se o DNS resolve os nomes dos servidores NTP corretamente (ou seja, não resolve o servidor):

host 0.pool.ntp.org
grep 0.pool.ntp.org /etc/hosts

Estas substituições são a causa mais provável do seu problema, já que parece não haver mais nada em sua configuração, o que faria com que seu sistema usasse 10.1.100.11 como um servidor NTP.

Verifique se você tem conectividade com o pool NTP com ntpdate ou sntp:

ntpdate -d 0.pool.ntp.org
sntp 0.pool.ntp.org

Ou reinicie o ntp enquanto procura por pacotes com tcpdump, tshark ou wireshark:

tshark -i eth0 -n -f 'udp port 123' &
service ntp restart

Se algum desses falhar, ou se você ver seus pedidos saindo sem respostas, provavelmente há um firewall em algum lugar bloqueando suas solicitações.

Se você precisar de mais ajuda para rastreá-lo, poste a saída de:

tail /var/log/ntpstats/peerstats