ntpdate -d sembra avere successo, ma ntpdate non restituisce alcun server adatto

14

Ho un sistema che non esegue ntpd sul quale sto tentando di aggiornare l'orologio usando ntpdate. Il sistema è un dispositivo che sembra basato su CentOS 6.

Quando corro ntpdate 0.pool.ntp.org, ottengo:

8 Sep 17:52:05 ntpdate[7445]: no server suitable for synchronization found

Tuttavia, quando lo faccio ntpdate -d 0.pool.ntp.org, ottengo:

8 Sep 17:55:14 ntpdate[9499]: ntpdate 4.2.2p1@1.1570-o Fri Nov 18 13:21:21 UTC 2011 (1)
Looking for host 0.pool.ntp.org and service ntp
host found : 4.53.160.75
transmit(4.53.160.75)
receive(4.53.160.75)
transmit(4.53.160.75)
receive(4.53.160.75)
transmit(4.53.160.75)
receive(4.53.160.75)
transmit(4.53.160.75)
receive(4.53.160.75)
transmit(4.53.160.75)
transmit(64.16.214.60)
receive(64.16.214.60)
transmit(64.16.214.60)
receive(64.16.214.60)
transmit(64.16.214.60)
receive(64.16.214.60)
transmit(64.16.214.60)
receive(64.16.214.60)
transmit(64.16.214.60)
transmit(54.236.224.171)
receive(54.236.224.171)
transmit(54.236.224.171)
receive(54.236.224.171)
transmit(54.236.224.171)
receive(54.236.224.171)
transmit(54.236.224.171)
receive(54.236.224.171)
transmit(54.236.224.171)
transmit(50.22.155.163)
receive(50.22.155.163)
transmit(50.22.155.163)
receive(50.22.155.163)
transmit(50.22.155.163)
receive(50.22.155.163)
transmit(50.22.155.163)
receive(50.22.155.163)
transmit(50.22.155.163)
server 4.53.160.75, port 123
stratum 2, precision -23, leap 00, trust 000
refid [4.53.160.75], delay 0.03160, dispersion 0.00005
transmitted 4, in filter 4
reference time:    d7b867d0.f9841075  Mon, Sep  8 2014 17:37:20.974
originate timestamp: d7b86c03.b6a49dae  Mon, Sep  8 2014 17:55:15.713
transmit timestamp:  d7b86c02.7e12a51e  Mon, Sep  8 2014 17:55:14.492
filter delay:  0.03189  0.03188  0.03172  0.03160
         0.00000  0.00000  0.00000  0.00000
filter offset: 1.218061 1.217856 1.218023 1.217968
         0.000000 0.000000 0.000000 0.000000
delay 0.03160, dispersion 0.00005
offset 1.217968

server 64.16.214.60, port 123
stratum 2, precision -23, leap 00, trust 000
refid [64.16.214.60], delay 0.04886, dispersion 0.00006
transmitted 4, in filter 4
reference time:    d7b86425.55948a73  Mon, Sep  8 2014 17:21:41.334
originate timestamp: d7b86c03.f7d91219  Mon, Sep  8 2014 17:55:15.968
transmit timestamp:  d7b86c02.bed42c3c  Mon, Sep  8 2014 17:55:14.745
filter delay:  0.04919  0.04892  0.04912  0.04886
         0.00000  0.00000  0.00000  0.00000
filter offset: 1.210967 1.210879 1.210967 1.210836
         0.000000 0.000000 0.000000 0.000000
delay 0.04886, dispersion 0.00006
offset 1.210836

server 54.236.224.171, port 123
stratum 3, precision -20, leap 00, trust 000
refid [54.236.224.171], delay 0.04878, dispersion 0.00011
transmitted 4, in filter 4
reference time:    d7b864eb.b06fee7d  Mon, Sep  8 2014 17:24:59.689
originate timestamp: d7b86c04.2b9d2547  Mon, Sep  8 2014 17:55:16.170
transmit timestamp:  d7b86c02.f1e80bed  Mon, Sep  8 2014 17:55:14.944
filter delay:  0.04977  0.04950  0.04878  0.04887
         0.00000  0.00000  0.00000  0.00000
filter offset: 1.214091 1.214069 1.213755 1.213750
         0.000000 0.000000 0.000000 0.000000
delay 0.04878, dispersion 0.00011
offset 1.213755

server 50.22.155.163, port 123
stratum 2, precision -23, leap 00, trust 000
refid [50.22.155.163], delay 0.07384, dispersion 0.00005
transmitted 4, in filter 4
reference time:    d7b869c9.2b3f3d0b  Mon, Sep  8 2014 17:45:45.168
originate timestamp: d7b86c04.75472e97  Mon, Sep  8 2014 17:55:16.458
transmit timestamp:  d7b86c03.384a83b1  Mon, Sep  8 2014 17:55:15.219
filter delay:  0.07408  0.07414  0.07384  0.07387
         0.00000  0.00000  0.00000  0.00000
filter offset: 1.214115 1.214122 1.214012 1.214069
         0.000000 0.000000 0.000000 0.000000
delay 0.07384, dispersion 0.00005
offset 1.214012

 8 Sep 17:55:15 ntpdate[9499]: step time server 4.53.160.75 offset 1.217968 sec

Sulla base delle mie ricerche precedenti, questo risultato (con le varie linee di ricezione () e l'offset) suggerisce che sta comunicando correttamente con i server NTP remoti (non bloccato da un firewall). Quindi, perché non aggiorna il mio orologio quando lo eseguo?

ntp

— csyria
fonte

16

Prova a eseguirlo come:

ntpdate -u 0.pool.ntp.org

I -uconfigura ntpdateper usare porte non privilegiate, cosa che fa sempre quando si utilizza l' -dopzione.

Pertanto, funziona con -ue, -dma non senza nessuno dei due, ricontrollerei i tuoi firewall.

Dalla pagina man:

-u Dirt ntpdate per usare una porta senza privilegi per i pacchetti in uscita. Questo è molto utile quando si trova dietro un firewall che blocca il traffico in entrata verso porte privilegiate e si desidera sincronizzare con host oltre il firewall. Si noti che l'opzione -d utilizza sempre porte senza privilegi.

— garethTheRed
fonte

1

Questo l'ha fatto. Immagino di avere un firewall più restrittivo da qualche parte oltre questo server, che mi mancava perché -d funzionava. Grazie!

— csyria,

2

aggiungi questa regola in iptables:

iptables -t nat -A POSTROUTING -p udp --sport 123 -j MASQUERADE --to-ports 1025-65535

— Norberto Aquino
fonte

2

Ciao Norberto. Questo potrebbe risolvere il problema, ma sarebbe molto utile se potessi modificare la tua risposta per spiegare perché lo fa.

— roaima,

1

Per il downvoter: una ragione per il downvote sarebbe cortese e molto probabilmente utile. IMO non c'è nulla di intrinsecamente sbagliato in questa risposta che una piccola spiegazione non potrebbe risolvere.

— roaima,