ntpdate funciona, mas o ntpd não pode sincronizar

Question

Isso está no RHEL 5.5.

Primeiro, o ntpdate para o host remoto funciona:

$ ntpdate XXX.YYY.4.21
24 Oct 16:01:17 ntpdate[5276]: adjust time server XXX.YYY.4.21 offset 0.027291 sec

Segundo, aqui estão as linhas do servidor no meu /etc/ntp.conf. Todas as linhas restrict foram comentadas para solução de problemas.

server 127.127.1.0
server XXX.YYY.4.21

Eu executo service ntpd start e confiro com ntpq :

$ ntpq
ntpq> peer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.           5 l   36   64  377    0.000    0.000   0.001
 timeserver.doma .LOCL.           1 u   39  128  377    0.489   51.261  58.975

ntpq> opeer
 remote           local          st t when poll reach   delay   offset    disp
==============================================================================
*LOCAL(0)        127.0.0.1        5 l   40   64  377    0.000    0.000   0.001
 timeserver.doma XXX.YYY.22.169   1 u   43  128  377    0.489   51.261  58.975

XXX.YYY.22.169 é o endereço do host no qual estou trabalhando. Uma consulta reversa no endereço IP no meu arquivo ntp.conf valida que a saída ntpq está nomeando corretamente o servidor remoto. No entanto, como você pode ver, parece apenas passar para o meu .LOCL. servidor de horário. Além disso, ntptrace apenas retorna o servidor de horário local e ntptrace XXX.YYY.4.21 expira.

$ ntptrace
localhost.localdomain: stratum 6, offset 0.000000, synch distance 0.948181

$ ntptrace XXX.YYY.4.21
XXX.YYY.4.21: timed out, nothing received
***Request timed out

Isso parece que meu daemon ntp está apenas se consultando.

Estou pensando na possibilidade de que o roteador-não-controle entre o meu servidor de horário de rede de teste e o servidor de horário de rede da empresa esteja bloqueando a porta de origem. (Acho ntpdate envia na porta 123, que fica em torno desse filtro e é por isso que eu não posso usá-lo enquanto o ntpd está sendo executado.) Eu tenho e-mail para a rede pessoal para verificar isso.

Por fim, telnet XXX.YYY.4.21 123 nunca expira ou conclui uma conexão.

As perguntas:

O que eu sinto falta aqui?

O que mais posso verificar para tentar descobrir onde esta conexão está falhando?

Será que strace ntptrace XXX.YYY.4.21 me mostrará a porta de origem que o ntptrace está enviando? Eu posso desconstruir a maioria das chamadas strace, mas não consigo descobrir a localização desse dado.

Se eu não puder examinar diretamente o roteador de gateway entre minha rede de teste e o servidor de horário, como posso criar evidências de que ele é responsável por essas desconexões? Alternativamente, como posso descartar isso?

    

Answer 1

Para aqueles que estão procurando uma solução grande, peço desculpas. Isso vai ser brega.

Sim, o servidor de horário está inacessível, por algum motivo que eu não consegui determinar. A boa notícia é que um dos servidores DNS externos aos quais tenho acesso acaba servindo os próprios pacotes NTP, e ele está se conectando a esse servidor de horário externo para seus ticks. É uma solução alternativa, não uma correção. Mas vou pegar o que puder conseguir.

Então, no final, eu só perco um estrato de serviço.

Como uma nota lateral, eu me registrei no banco de dados de bugs do NTP para que eu pudesse escrever o erro 2297 >, solicitando documentação formal para o peer refids .INIT., .LOCL. e LOCAL (0).

    

Answer 2

O 377 na coluna reach significa que a conectividade está ok; telnet não se conectará porque o NTP é UDP.

Tente remover o server 127.127.1.0 da sua configuração - o * by *LOCAL(0) nos informa que o servidor local com o stratum 5 está sendo usado para sincronização, preferível ao servidor remoto com o stratum 1; o atraso e o offset, ambos com 0,000, provavelmente tem muito a ver com isso.

    

Answer 3

Se você vai incluir o relógio local, falsifique seu nível um pouco. Parece que você definiu como 5. Geralmente, configurei pelo menos 8 ( fudge 127.127.1.0 stratum 8 ). Se você não fudge, você pode aparecer como um relógio atômico para outros hosts em sua rede. Em uma rede que eu escaneei, encontrei muitos servidores de baixa capacidade anunciando horários que normalmente eram incorretos por horas ou dias.

Shane está correto sobre o valor reach , o que indica que você tem acesso ao servidor. Os altos valores de offset e jitter para seu servidor de horário indicam que pode não ser muito confiável. Eles podem ser altos, porque o seu servidor ainda está sincronizando. O fato de que o poll interval aumentou para 128 indica que seu servidor está obtendo resultados consistentes. Deve aumentar gradualmente para 1024 segundos.

Tente executar um loop como:

while sleep 60; do
    ntpq -n -c peers; done

Isso lhe dará uma idéia de como o ntp está funcionando. Você deve ver estabilizar ao longo do tempo.

Existem várias restrições que podem ser definidas em ntpd para limitar a quantidade de informações sobre o servidor que podem ser acessadas remotamente. É possível que você esteja restrito a usar apenas o servidor upstream como fonte de tempo.

Regras de firewall que restringem o tráfego para a porta 123 para origem e destino são possíveis. Isso fornece uma configuração ntp de trabalho, mas limita o acesso por outras ferramentas. Algumas ferramentas permitem que você use a porta 123 como a porta de origem, se disponível. Eu sou parcial ao usar ntpdate no modo de depuração.

Se você está correto sobre o refid do servidor upstream ser seu endereço IP, ele parece estar usando seu servidor como o seu timesource preferido. Tente adicionar restrict noquery à sua configuração. Pode ser que seu servidor upstream esteja mal configurado. Tente adicionar seu roteador e / ou servidores de nomes como fontes, acho que eles podem ser fontes melhores do que o servidor corporativo oficial.

    

Answer 4

Eu tive o mesmo problema:

ntpq -p estava mostrando alcance = 0

Ainda 1- o ntpd estava em execução 2- o ntp.conf tem servidores listados 3- ntpdate trabalhou usando esses servidores 4-ntpdate -u trabalhou usando esses servidores 5- nc mostrou TCP porta 123 foi aberto no servidor 6- nc mostrou que a porta UDP 123 estava aberta nesses servidores

Então, basicamente, o ntpdate funcionou e não havia problemas de firewall e, ainda assim, ntpq -p mostrou reach = 0 para cada servidor listado.

Acabou sendo as linhas restritas no ntp.conf. Acabei de remover todas as linhas restritas do ntp.conf e reiniciei o ntpd e tudo funcionou a partir daí.

    

Answer 5

Só queria adicionar meus dois centavos ao resultado da pesquisa do Google. Eu enfrentei esse problema em um host onde o NTP não estava vinculado à interface externa do host. Se você tiver esse problema, veja a saída de netstat -tulpn .

Esta instância do ntpd não será capaz de sincronizar com uma fonte de tempo boa conhecida.

$ sudo netstat -tulpn | grep ntp
udp        0      0 127.0.0.1:123               0.0.0.0:*                                  31316/ntpd          
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               31316/ntpd          

Isso vai acontecer.

$ sudo netstat -tulpn | grep ntp
udp        0      0 192.168.1.15:123            0.0.0.0:*                               32294/ntpd          
udp        0      0 127.0.0.1:123               0.0.0.0:*                               32294/ntpd          
udp        0      0 0.0.0.0:123                 0.0.0.0:*                               32294/ntpd   

Isso foi resultado do arquivo de configuração que tentava restringir a vinculação a interfaces IPv4 usando apenas o caractere curinga 0.0.0.0.

$ grep ^interface /etc/ntp.conf 
interface listen 0.0.0.0

A configuração correta (desejada) foi a seguinte.

$ grep ^interface /etc/ntp.conf 
interface listen ipv4
interface ignore ipv6

(Ou, para remover as duas opções de configuração da interface.)

Você também pode verificar /etc/sysconfig/ntp ou equivalente para qualquer configuração que possa restringir a vinculação de interface.