scaduto, nulla ricevuto

9

Ho provato tutto e ho cercato su Google molto! Ma non riesco a far funzionare NTP sul mio server. Questo post è l'ultima speranza! Ho installato ntp sul server debian con questa configurazione ( /etc/ntp.conf):

driftfile /var/lib/ntp/ntp.drift

statdir /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

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

restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap

# Restrict eth0 ip
restrict 192.168.1.1
restrict 127.0.0.1 noserve nomodify
restrict ::1

Ora quando provo:

ntpq -pn
127.0.0.1: timed out, nothing received
***Request timed out

Quando provo:

ntpdate -q
9 Mar 18:08:01 ntpdate[27896]: no servers can be used, exiting

Ma con:

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

Ricevo i pacchetti in arrivo e imposto il time offset. Questo mi ha portato a una configurazione ntp.conf errata .

Qualche indizio sul perché questo stia accadendo.

debian ntp

— Test
fonte

Quale file stai mostrando? È quello /etc/ntp.conf? Sei sicuro di quei server NTP? Prova Debian, il mio (funzionante) ntp.conf è qui .

— terdon

Sì, è ntp.conf. Proverò con i server di Debian. Grazie

— Test

No, sempre gli stessi errori.

— Test

Supponendo di aver riavviato ntpd dopo aver apportato queste modifiche, è corretto? service ntpd restart.

— slm

1

Inoltre, le tue linee di limitazione sono strane ... Guarda support.ntp.org/bin/view/Support/AccessRest

— restrizioni

3

Se nessuno dei server NTP che stai cercando sembra rispondere, è probabile che un firewall stia bloccando le richieste in uscita o le risposte in arrivo.

NTP utilizza la porta UDP 123. È possibile verificare se le richieste in uscita vengono bloccate eseguendo traceroute su quella porta. A seconda dell'implementazione di traceroute, questo potrebbe essere qualcosa del genere traceroute -p 123 0.it.pool.ntp.org(Debian include diverse implementazioni di traceroute, check traceroute --helpo man traceroutesul proprio sistema). Se le richieste in arrivo sono bloccate ma le richieste in uscita passano, non credo che tu possa diagnosticare dove sono bloccate senza accesso a una macchina esterna alla tua rete (se hai accesso a tale macchina, esegui traceroute -p 123 your.ip.address). Se si dispone di un indirizzo IP privato , la possibilità di utilizzare NTP richiede la collaborazione dell'amministratore di rete (in particolare, il supporto NTP nell'appliance NAT ).

Se hai impostato un firewall sul tuo computer, assicurati che passi NTP. Il modo semplice è consentire tutto il traffico sulla porta UDP 123:

iptables -A INPUT -p udp --sport 123 --dport 123 -j ACCEPT
iptables -A OUTPUT -p udp --sport 123 --dport 123 -j ACCEPT

(Potresti voler aggiungere -d/ -sdirettive per limitare a un determinato indirizzo IP o set di indirizzi IP. Tieni presente che se lo fai, dovrai aggiornare queste regole se i server NTP nel pool che stai utilizzando cambiano gli indirizzi IP .)

Se il traffico NTP è bloccato da qualche parte tra la macchina e Internet, contattare l'amministratore di rete. È probabile che esista una macchina di inoltro che è possibile utilizzare come server NTP.

— Gilles 'SO- smetti di essere malvagio'
fonte

Il traffico NTP esterno è probabilmente bloccato dal provider di hosting / ISP. Questo è un approccio pesante per prevenire DDOS. Chiedi al tuo ISP a quali server ntp interni puoi connetterti.

— dfc

1

@dfc Nella mia esperienza, i firewall aziendali bloccano l'NTP come parte del blocco di tutti gli UDP o come conseguenza naturale del NAT, ma gli ISP non lo fanno (tranne quelli che NAT). Ma in effetti, se il tuo ISP blocca l'NTP in entrata, dovrebbe fornire un server NTP sulla sua rete.

— Gilles 'SO-smetti di essere malvagio' il

Avevo già aggiunto queste regole a iptables, ma sempre lo stesso errore. Stranamente con: ntpdate -d 0.it.pool.ntp.org, funziona. Quindi credo che sia ntp.conf.

— Prova il

@Gilles è la "tua esperienza" prendendo in considerazione la recente ondata di attacchi DDoS che usano ntp? Un anno fa sarei d'accordo con il tuo commento. Tuttavia, dopo le recenti ondate di attacchi, il filtro ntp in uscita è molto più comune di quanto si pensi.

— dfc

@BojanVidanovic Non ha alcun senso che funzioni con ntpdate e non con ntp. Quando funziona con ntpdate dovresti prendere nota dell'indirizzo IP che ha restituito ann answer e provare a inserirlo in ntp.conf. La risposta DNS per l'indirizzo pool.ntp.org varierà a seconda di quanti server le cose di monitoraggio del pool sono attualmente integre oltre a qualche pseudo randomizzazione nel demone DNS.

— dfc

3

Per quanto posso dire, la tua domanda è "Perché ntpq -pnnon funziona come mi aspetto?"

Cambia questa riga:

restrict 127.0.0.1 noserve nomodify

tornando a quello che era originariamente:

restrict 127.0.0.1

ora ntpq -pnfunzionerà.

Cordiali saluti: ::1è la versione IPv6 di127.0.0.1

Config aggiornata:

driftfile /var/lib/ntp/ntp.drift

statdir /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

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

restrict -4 default nomodify nopeer noquery notrap
restrict -6 default nomodify nopeer noquery notrap

# Restrict eth0 ip
restrict 192.168.1.1
restrict 127.0.0.1
restrict ::1

— DFC
fonte

127.0.0.1: scaduto, nulla ricevuto *** Richiesta scaduta

— Test

Hai aggiornato il tuo /etc/ntp.conf con ciò che è mostrato sopra e riavviato ntp e hai ricevuto il messaggio scaduto? Qual è l'output di netstat -laun?

— dfc

Molte grazie! Ho anche aggiunto "restringi localhost" alla fine delle restrizioni

— Vagner do Carmo,

1

Il problema sembra essere nella selezione di quei 2 server in queste 2 righe del file di configurazione:

server ntp1.inrim.it iburst
server ntp2.inrim.it iburst

Quando provo a interrogare uno di essi, ottengo anche il tuo errore:

$ sudo ntpq -p ntp1.inrim.it
ntp1.inrim.it: timed out, nothing received
***Request timed out

$ sudo ntpq -p ntp2.inrim.it
ntp2.inrim.it: timed out, nothing received
***Request timed out

Proverei a selezionare alcuni server diversi per cominciare.

Quei server?

Quando ho cercato su Google i loro nomi, mi sono imbattuto in questa pagina intitolata: Come configurare il vostro NTP . C'era un altro server che non funzionava menzionato lì:

$ sudo ntpq -p host2.miaditta.it 
host2.miaditta.it: timed out, nothing received
***Request timed out

Questi server sembrano essere il problema.

Encryption?

Se guardi più in basso nell'URL sopra menzionato, discutono dell'uso della crittografia, potrebbe essere necessario abilitarlo per accedere a quei server NTP.

Suggerimenti per il debug

Sono stato in grado di connettermi con successo a entrambi i iburstserver usando questo comando:

$ ntpdate -d <server>

Esempio

$ ntpdate -d ntp1.inrim.it
 9 Mar 21:01:37 ntpdate[20739]: ntpdate 4.2.6p5@1.2349-o Tue Apr  2 17:47:01 UTC 2013 (1)
Looking for host ntp1.inrim.it and service ntp
host found : ntp1.inrim.it
transmit(193.204.114.232)
receive(193.204.114.232)
...
server 193.204.114.232, port 123
stratum 1, precision -22, leap 00, trust 000
refid [CTD], delay 0.19319, dispersion 0.00084
transmitted 4, in filter 4
reference time:    d6c78d79.f0206119  Sun, Mar  9 2014 21:01:45.937
originate timestamp: d6c78d7e.55ab5b4b  Sun, Mar  9 2014 21:01:50.334
transmit timestamp:  d6c78d77.7e9b8296  Sun, Mar  9 2014 21:01:43.494
filter delay:  0.19460  0.19710  0.19453  0.19319 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 6.755368 6.757349 6.755239 6.756265
         0.000000 0.000000 0.000000 0.000000
delay 0.19319, dispersion 0.00084
offset 6.756265

 9 Mar 21:01:43 ntpdate[20739]: step time server 193.204.114.232 offset 6.756265 sec

Quindi sembra che il tuo problema sia effettivamente qualcosa di sbagliato nel tuo ntp.conffile. Conferma che questo è il caso e possiamo continuare a eseguire il debug ulteriormente.

— slm
fonte

Sì, non userò quei server, ma ho aggiunto debian.pool.ntp.org e ancora ottengo: scaduto. O it.pool.ntp.org, che funziona mi dà lo stesso errore. A questo punto penso che qualcosa stia bloccando NTP.

— Test

se provo: ntpdate 0.debian.pool.ntp.org, funziona.

— Test

Sì, con: ntpdate -d ntp1.inrim.it vedo i tuoi stessi risultati. Quindi probabilmente è ntp.conf.

— Prova il

1

@BojanVidanovic - sì sì, probabilmente il problema è tuo ntp.conf. Quindi questo è un buon progresso. Prenderei il massimo delle linee tranne quelle del server per eseguire il debug ulteriormente.

— slm

1

Il passaggio a ntpd, l'aggiunta di -dopzioni aggiungerà altro e -D levelabiliterà INFO, TRACE, DEBUG, ecc.

— slm

0

Nel mio caso, l'adattatore di loopback era disabilitato nel sistema. Dopo averlo abilitato, il problema è stato risolto. Vedi il file / etc / network / interfaces.

— lehab
fonte

0

Da quello che vedo, hai configurato un SERVER NTP ma lo stai puntando su una PISCINA

server 0.pool.ntp.org

Provare:

pool 0.pool.ntp.org

invece usa "server" con un server dedicato, non un pool.

— ronator
fonte