Serveur NTP - Casse-tête

Support Debian
#1

Hello,

J’ai des serveurs censés se synchroniser mais qui me montrent ce type de résultats :

#ntpq -p
remote refid st t when poll reach delay offset jitter

LOCAL(0) LOCAL(0) 10 l 48 64 377 0.000 0.000 0.008
dnscache-*** 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
dnscache-**** 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00

(Pour cet exemple, j’ai remplacé le nom des serveurs ntp par qq-**** au lieu de mettre leur nom réel…)

J’obtiens aussi ceci :

]# ntpstat
synchronised to local net at stratum 11
time correct to within 949 ms
polling server every 16 s

Pas de souci de résolution. Pas de souci pour joindre les serveurs NTP. Pas de souci pour ce qui est du port distant (m’y suis connecté via un nc ntp-**** -v -u 123. Le résultat me renvoie “open”). Je ne vois pas non plus de souci sur le fichier de configuration.

Ici - pardon d’avance - c’est une redhat. Par contre, la configuration du service étant la même - il me semble - que ce soit une Redhat ou non, je ne crois pas que ça rentre en ligne de compte. C’est pour ça que je me permet d’ouvrir un sujet, ici (merci d’avance de bien vouloir me pardonner! D’autant que ce n’est pas ma machine). C’est parce que j’ai confiance en vous, c’est pour ça :stuck_out_tongue:

Ma question est la suivante, en fait. Sur d’autres machines (la version du serveur ntp n’est pas la même), j’obtiens plutôt ce genre de résultat :

/usr/sbin/ntpq -p

 remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================
-dnscache-**** 192.x.y.z 2 u 849 1024 377 26.865 2.679 0.784
dnscache-*** 145.x.y.z 2 u 108 1024 377 8.333 -0.143 0.721
+dnscache-**** 145.x.y.z 2 u 933 1024 377 46.640 -0.940 0.414
(…)

(vous l’aurez compris, là encore j’ai masqué les IP et le nom des caches).

Dans le premier cas, je suis bien synchro ou pas ? Je ne suis pas sûr de mon coup.

Pour moi, ce style de résultat :
LOCAL(0) LOCAL(0) 10 l 48 64 377 0.000 0.000 0.008
dnscache-*** 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00

veut dire que je suis seulement synchro en local mais que je n’atteins pas les serveurs NTP… ce que je ne pige pas, puisque je parviens à les joindre sans souci avec un ntpdate! :confused:

Merci du coup de main!

Cordialement,
Christian

#2

Oui il y a un souci.
Quel est le contenu de ton ntp.conf?
Résultat de

iptables-save | grep " 123"

as tu des règles de parefeu qui bloquerait le port 123 en UDP (entrée et sortie)?

#3

Ah Fran!

Merci à toi!!! Figure toi que mes collègues affirmaient que y avait pas de problèmes avec le NTP. Je n’étais pas d’accord, à cause de ces résultats, d’une part à cause du level des strates et ensuite parce qu’on devrait avoir autre chose que 0 en reach. En plus les entrées sont “vides” au début de chaque lignes, exeptés en local. Ce qui n’est pas normal (on devrait avoir des +, des -, des *, bref…). Merci de m’avoir clairement levé le doute, donc.

Le ntp.conf ressemble à ceci :

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
#La liste des serveurs ntp (masqués pour l’occasion)
#identique au contenu de /etc/ntp/step-tickers
server ntp-**** version 4
server ntp-**** version 4
server ntp-**** version 4
server ntp-**** version 4
server ntp-**** version 4
server ntp-**** version 44
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
keys /etc/ntp/keys

La machine écoute bien l’extérieure sur le port 123. Le résultat que j’obtiens ressemble à ceci (là aussi j’ai masqué les premières IPs.), dans cet ordre :

netstat -nltpu | grep 123

udp 0 0 10.x.y.z:123 0.0.0.0:* -
udp 0 0 81.x.y.z:123 0.0.0.0:* -
udp 0 0 127.0.0.1:123 0.0.0.0:* -
udp 0 0 0.0.0.0:123 0.0.0.0:* -

Ta question sur le iptables est très intéressante : ça m’a pris plus de temps que toi, mais oui, je me suis posé la même, à ceci près que je ne connaissais pas la commande que tu utilises. Voilà le résultat :

#iptables-save | grep " 123"
-A INPUT -p udp -m udp --sport 123 --dport 1024:65535 -j ACCEPT

Ca tombe bien, donc… d’autant que j’ai un doute.
Car quand je liste les rules à ma façon (basiquement iptables -L), j’obtenais ça :

ACCEPT udp – anywhere anywhere udp spt:ntp dpts:1024:65535

Or tel quel, j’ai le sentiment que la rule ouvre un accès entre les port 1024 et 65535 (le port 123 étant hors de cette intervalle de port). Dsl je ne suis pas connaisseur, côté iptables (une faute de gout de ma part, je le crains. Je connais la puissance de l’outil).

Qu’est ce que tu en penses ?

#4

Hi,

Oui, mais si je teste, j’obtiens ce type de résultat :

#nc ntp-**** -v -u 123
dnscache-**** [w.x.y.z] 123 (ntp) open

Il me semble donc que le port 123 est ouvert, en fait :confused:

#5

Ton fichier de configuration a l’air correct (pas regardé en détails mais pas d’erreurs flagrantes).

Par contre ta régle iptables a l’air curieuse

-A INPUT -p udp -m udp --sport 123 --dport 1024:65535 -j ACCEPT
Ce que j’interprète comme tout ce qui vient d’un port 123 pour un port classique est accepté. Certes mais les dialogues NTP sont de port 123 vers port 123. (Je viens de faire un tcpdump sur un de mes serveurs NTP et je confirme).

Met une règle type

et je rajouterais si tu as une politique par défaut en OUTPUT à DROP

(très restrictive comme règle mais devrait convenir).

#6

Hi,

Pardon, mais je ne suis pas certain de comprendre. Tu dis : “les dialogues NTP sont de port 123 vers port 123”. Si j’interprète bien ta réponse, ce que je comprends, c’est que tu me confirmes que la rule :

-A INPUT -p udp -m udp --sport 123 --dport 1024:65535 -j ACCEPT

permet un dialogue entre le port 123 distant et un port situé dans l’intervalle 1024/65535 alors qu’il faudrait un rule qui permet la même chose mais entre le port 123 distant et le port 123 local. C’est bien cela ? :slightly_smiling:

Amicalement,
Christian

#7

Oui. De plus ta règle ne concerne pas ton serveur qui lui écoute sur le port 123. En fait tu autorises n’importe qui à utiliser un port UDP sur ta machine à condition qu’il soit >= 1024 et que la connexion se fasse à partir d’un port 123. C’est une faille dans ton parefeu assez importante et ta règle ne fait pas ce que tu veux.

#8

Oups. C’est mal, ça.
Je crois que je vais taper sur mon client.

Merci!

J’ai un autre souci très semblable sur une autre machine, sauf qu’il n’y a pas de rules iptables. Mais je vais voir ça : tu m’as donné de bonnes pistes. Je vais voir avec le mec qui a créé la règle pour régler ça sur cette machine-ci. Merci pour ton aide !

PS. Faut que je me mette sur IPtables. Ce n’est pas la première fois que je me le dis, en plus :confused:

En passant, tu ne connaitrais pas une boite sympas sur paris / 78 / 28 qui chercherait un tech, par hasard ? Ca pue, là où je suis. :s

Cordialement,
Christian

#9

Ah en passant, un truc utile. La cmd ntpdate me semble mettre la machine à l’heure quand je requête en direction d’un des caches. Le service non. dois-je comprendre que la commande ne fonctionne pas de la même façon que le serveur NTP ? ntpdate fonctionne tout de même si le serveur ntp est bloqué par un FW ?

#10

Ta commande ntpdate interroge un port 123 d’une machine distante à partir d’un port quelconque.

#11

Ah ok. Je comprends. En effet, dans ce cas, ce n’est pas du tout la même chose.

Bon je vais voir par rapport à ton retour. Merci pour ton aide!! :slightly_smiling::slight_smile:

Amicalement,

#12

hello
as tu regler ton soucis
sinon sur une autre machine install ntp
puis tu y mets ce qui suit ce devrai marcher

fichier ntp.conf

server w.x.y.z prefer ; ton serveur ntp preferer

server ntp.xxx.yy
server ntp.rrr.yy
server ntp.TTT.YY
server ntp.uuu.yy

server 127.127.1.0

fudge 127.127.1.0 stratum 4

la premiere ligne ton serveur ntp preferer
le second chapitre ( server ntp.xxx.yy server ntp.rrr.yy ) divers site ntp public
la derniere ligne pour dire a tes client que ton serveur a un haut niveau de synchro/fiabiliter

ensuite fait un ntpq -p
tu verra que ton serveur ce synchronise et que il arrive a une valeur 377 c’est qu ils sont en parfaite synchro avec tes serveur de reference

peux tu me poster la reponse du ntpq -p

#13

Non, 377 n’indique pas une synchro parfaite mais indique juste le succès des connexions sur 8 bits, chaque bit à un indique un succès de la connexion.
Le succès de la synchro ne se voit pas là mais dans le fait même que le serveur s’affiche. Une * devant le serveur indique que le dit serveur est la référence actuelle, les «+» sont des serveurs en accord parfaits, les «-» les serveurs qui ont tendance à diverger.
La colonne offset indique les écarts lors du dernier contact.

La ligne
server 127.127.1.0

est une ligne qui indique au serveur de se synchroniser sur son horloge ce qui est crétin, l’intérêt de cette ligne est éventuellement de rajouter effectivement
fudge 127.127.1.0 stratum 4
qui indique que l’horloge interne est un serveur de stratum 4 autrement dit qu’il serait synchronisé sur un serveur synchronisé sur un serveur synchronisé sur un serveur synchronisé sur une horloge atomique ce qui est faux et constitue un mensonge pour ceux qui se synchroniserait sur ce serveur (celui ci se rait dans ce cas de niveau 5 et non 13 comme c’est le cas), en clair ça affiche une qualité de synchronisation fausse.

Par ailleurs 127.127.1.0 est une adresse loopback, usuellement on met plutôt 127.0.0.1 mais bon.

En clair ces 2 lignes au mieux ne changent rien, au pire mette la pagaille sur les serveurs extérieurs se synchronisant sur ce serveur en leur faisant croire que le serveur est de qualité ce qu’il n’est pas. Ça n’est donc pas à faire.

#14

Hi, je réponds en retard, pardon…

Super interressante, ton explication. Je ne pige pas un truc, par contre. Cettte IP : 127.127.1.0. Je la vois souvent sur nos serveur. C’est l’adresse loopback alors. Mais si nous devions avoir 127.0.0.1 (l’adresse “normale”) pourquoi diantre, on a celle-là ? C’est une configuration par défaut ?

Sinon,oui, j’ai réglé le problème sur l’une des deux machines. L’autre, le client va la déprovisionner. Donc, en attendant, j’ai utilisé un cron - basiquement. Juste histoire d’avoir une synchro minimum avec ntpdate, même si on perd l’intéret d’avoir un serveur NTP. Le client ne voulait pas modifier son iptables (que j’ai commencé un peu à pratiquer, depuis… à force de dire que j’allais le faire, il était temps - sans jeu de mot - que je m’y mette un peu).