Eu tenho cinco servidores que estou configurando para uso em produção com base em uma configuração que testamos recentemente. Os servidores são RHEL6 com NTP versão [email protected]. No momento, porém, estou tentando descobrir a solução para isso, tendo apenas dois servidores em execução ao mesmo tempo. Quando concluído, ele consistirá dos cinco servidores NTP, cada um usando uma chave SHA1. De acordo com o comando associations em ntpq , toda a autenticação está funcionando.
Servidor 1:
ind assID status conf reach auth condition last_event cnt
===========================================================
1 50914 9314 yes yes none outlyer reachable 1
2 50915 9414 yes yes none candidat reachable 1
3 50916 9314 yes yes none outlyer reachable 1
4 50917 9414 yes yes none candidat reachable 1
5 50918 9614 yes yes none sys.peer reachable 1
6 50919 f014 yes yes ok reject reachable 1
(A última entrada é o meu servidor. Os outros cinco são fontes de tempo externas).
A saída peer mostra que é capaz de se comunicar com o Servidor 2:
ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
-192.5.41.40 .PTP. 1 u 11 64 177 24.125 -1.858 5.692
+ntp-s1.cise.ufl .GPS. 1 u 23 64 177 36.340 0.443 0.235
-ntp.colby.edu .GPS. 1 u 30 64 177 23.204 -0.474 0.221
+navobs1.oar.net .GPS. 1 u 26 64 177 26.496 0.671 0.755
*gnomon.cc.colum .USNO. 1 u 21 64 177 10.862 0.422 0.304
server2. 128.59.39.48 2 u 366 64 100 0.256 -1.010 0.000
Servidor 2:
ind assID status conf reach auth condition last_event cnt
===========================================================
1 21528 9314 yes yes none outlyer reachable 1
2 21529 9414 yes yes none candidat reachable 1
3 21530 9414 yes yes none candidat reachable 1
4 21531 9614 yes yes none sys.peer reachable 1
5 21532 9314 yes yes none outlyer reachable 1
6 21533 e07f yes yes ok reject 7
Como você pode ver, a última entrada é capaz de autenticar com sucesso, mas não vê o Servidor 1 como acessível. A saída 'peer' mostra que há um problema com o protocolo Autokey:
ntpq> pe
remote refid st t when poll reach delay offset jitter
==============================================================================
-192.5.41.40 .PTP. 1 u 1 64 177 26.081 -2.240 4.083
+ntp.colby.edu .GPS. 1 u 15 64 177 23.506 0.343 0.530
+navobs1.oar.net .GPS. 1 u 19 64 177 26.477 1.622 0.758
*gnomon.cc.colum .USNO. 1 u 13 64 177 11.332 0.985 0.713
-navobs1.gatech. .GPS. 1 u 17 64 177 34.621 -1.261 0.753
Server1. .CRYP. 16 u 410 64 0 0.000 0.000 0.000
O arquivo cryptstats no Servidor 2 indica error 10f opcode 2010000 ts 3632247548 fs 4259841 repetidamente. No entanto, não consigo encontrar nada que explique o que esse erro ou esse opcode significa em termos simples e identificáveis.
O que torna isso ainda mais frustrante para mim é que, quando eu tenho todos os cinco servidores em execução, alguns poderão se comunicar com o Server1, enquanto outros, como o Server2, não conseguem.
Server1 ntp.conf
Este arquivo é para o Server1. Com exceção das listas de peer e server, todos os servidores NTP são idênticos. A lista peer é alterada de tal forma que um servidor não é listado como seu próprio ponto. A lista server é um pouco diferente de um servidor para o outro, de modo que há pelo menos uma fonte de tempo diferente em todos eles.
restrict default kod notrap
restrict 127.0.0.1
driftfile /var/lib/ntp/drift
logfile /var/log/ntp.log
server tick.usno.navy.mil iburst
server ntp-s1.cise.ufl.edu iburst
server ntp.colby.edu iburst
server navobs1.oar.net iburst
server gnomon.cc.columbia.edu iburst
peer server2 iburst autokey
#peer server3 iburst autokey
#peer server4 iburst autokey
#peer server5 iburst autokey
crypto
includefile /etc/ntp/crypto/pw
keysdir /etc/ntp/crypto/
statistics clockstats cryptostats loopstats peerstats
statsdir /var/lib/ntp/ntpstats/
filegen clockstats file clockstats type day enable
filegen cryptostats file cryptostats type day enable
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
Eu também gerou novas chaves no Server1. Isso não ajudou.
UPDATE: Parece que se eu desligar ntpd em ambos os servidores e depois trazê-lo de volta (não uma reinicialização, mas uma parada ... start), o que aparece primeiro é capaz de comunicar com sucesso enquanto o que aparece em segundo exibe o CRYP refid. Eu testei isso trazendo Server1 até Server2 e vendo que Server1 é capaz de se comunicar com sucesso enquanto Server2 exibe CRYP . Em seguida, inverti a ordem e o Server2 conseguiu se comunicar com êxito enquanto o Server1 exibia CRYP .
Tags ntp