Réseaux et automatisation 14 min de lecture

Configurer un serveur NTP local sur MikroTik RouterOS

Synchroniser RouterOS sur plusieurs sources, distribuer l’heure au LAN par DHCP, protéger UDP 123 et rediriger facultativement les clients récalcitrants.

Une heure exacte n’est pas un détail cosmétique. Les journaux d’un pare-feu, les certificats TLS, l’authentification, les tâches planifiées, les sauvegardes et la corrélation d’incidents dépendent tous d’horloges cohérentes. Lorsque chaque caméra, NAS, serveur et objet connecté interroge son propre service sur Internet, l’administrateur perd à la fois en visibilité et en maîtrise.

RouterOS 7 peut résoudre ce problème en jouant deux rôles : client NTP vers plusieurs sources externes, puis serveur NTP unicast pour le réseau local. Les clients utilisent alors l’adresse du MikroTik comme référence. Une règle de redirection peut aussi reprendre les requêtes UDP 123 envoyées vers l’extérieur, mais cette mesure doit rester facultative et contrôlée.

Architecture et limites

Le flux recommandé est simple : plusieurs sources NTP alimentent RouterOS, RouterOS annonce son adresse par DHCP, puis les clients l’interrogent en unicast. Le pare-feu autorise UDP 123 depuis le LAN et refuse les demandes arrivant du WAN.

Schéma du MikroTik synchronisé sur quatre sources puis servant l’heure aux clients du LAN avec l’option DHCP 42
Le routeur s’alimente auprès de plusieurs sources, devient la référence unicast du LAN et reste fermé aux requêtes NTP venues du WAN. La redirection des clients externes est facultative.

Les exemples utilisent :

  • le réseau 192.168.88.0/24 ;
  • le routeur 192.168.88.1 ;
  • les listes d’interfaces LAN et WAN ;
  • le fuseau Europe/Brussels ;
  • quatre noms du pool NTP belge.

Adaptez les adresses, l’interface WAN et le fuseau. NTP transporte le temps en UTC ; le fuseau horaire ne change que l’affichage local du routeur et l’horodatage présenté par ses outils.

1. Sauvegarder et contrôler les prérequis

Travaillez depuis le LAN et activez le Safe Mode avec Ctrl+X. Conservez un export et une sauvegarde binaire avant de modifier le pare-feu ou le DHCP.

/export file=avant-ntp
/system backup save name=avant-ntp
/system resource print
/system clock print
/system ntp client print
/system ntp client servers print detail
/system ntp server print
/ip dhcp-server network print detail

Les noms de serveurs NTP exigent une résolution DNS fonctionnelle. Vérifiez aussi l’accès IP.

:put [:resolve 0.be.pool.ntp.org]
/ping 1.1.1.1 count=4

2. Régler le fuseau horaire

/system clock
set time-zone-name=Europe/Brussels
/system clock print

La base de fuseaux de RouterOS applique automatiquement l’heure d’été selon les règles du fuseau. Évitez un décalage UTC fixe : il deviendrait faux au changement saisonnier.

3. Choisir plusieurs sources NTP

Le guide de bonnes pratiques RFC 8633 recommande au moins quatre sources indépendantes lorsqu’une heure fiable est importante. Quatre sources permettent de conserver trois avis si l’une devient indisponible ou incohérente.

Pour un réseau situé en Belgique, le NTP Pool Project publie 0.be.pool.ntp.org à 3.be.pool.ntp.org. Les noms sont préférables à des adresses codées en dur : le pool peut renouveler les serveurs retournés par DNS. Pour une infrastructure critique, utilisez plutôt des sources exploitées contractuellement, des horloges internes ou une architecture dédiée.

/system ntp client
set enabled=yes mode=unicast

/system ntp client servers
add address=0.be.pool.ntp.org comment="NTP Pool BE 0"
add address=1.be.pool.ntp.org comment="NTP Pool BE 1"
add address=2.be.pool.ntp.org comment="NTP Pool BE 2"
add address=3.be.pool.ntp.org comment="NTP Pool BE 3"

Les valeurs par défaut min-poll=6, max-poll=10 et iburst=yes conviennent généralement. Ne réduisez pas agressivement les intervalles : cela ne rend pas l’horloge magiquement plus précise et augmente la charge de services fournis en grande partie par des volontaires.

Si le WAN reçoit aussi des serveurs NTP par DHCP, ils peuvent apparaître comme entrées dynamiques. Pour une sélection entièrement maîtrisée, désactivez leur import sur le client DHCP concerné après avoir identifié son interface.

/ip dhcp-client print detail
/ip dhcp-client
set [find where interface="ether1"] use-peer-ntp=no

Ne lancez pas cette seconde commande si le WAN n’utilise pas DHCP ou si l’interface ne s’appelle pas ether1.

4. Vérifier que RouterOS est réellement synchronisé

/system ntp client print
/system ntp client servers print detail
/system ntp monitor-peers

Attendez l’état synchronized. Contrôlez aussi synced-server, synced-stratum et system-offset. Les pairs doivent présenter des délais et des décalages plausibles. Une résolution DNS réussie ne prouve pas que les échanges UDP 123 passent réellement.

5. Activer le serveur NTP unicast

Pour des clients explicitement configurés avec l’adresse du routeur, il suffit d’activer le serveur. Les modes broadcast, multicast et manycast ne sont pas nécessaires dans ce scénario et ajoutent du trafic ainsi qu’une surface de diagnostic inutile.

/system ntp server
set enabled=yes broadcast=no multicast=no manycast=no \
    use-local-clock=no
/system ntp server print

use-local-clock=no empêche le routeur de présenter son oscillateur interne comme une référence valide lorsque l’amont disparaît. La documentation MikroTik rappelle que cette horloge dépend notamment de la température, de la gestion d’énergie et du matériel : elle ne constitue pas une source de précision.

6. Autoriser le LAN et fermer le WAN

Le service écoute en UDP 123. Ajoutez une autorisation pour les réseaux de confiance avant le rejet final de la chaîne input. Un pare-feu RouterOS standard bloque déjà les nouvelles connexions du WAN, mais des règles explicites rendent l’intention vérifiable.

/ip firewall filter
add chain=input action=accept in-interface-list=LAN \
    protocol=udp dst-port=123 \
    comment="NTP: autoriser les clients LAN"
add chain=input action=drop in-interface-list=WAN \
    protocol=udp dst-port=123 \
    comment="NTP: refuser les requêtes WAN"

Vérifiez l’ordre avec /ip firewall filter print. L’autorisation LAN doit précéder un rejet général du LAN, et la règle WAN ne doit pas remplacer les protections établies sans audit. Un serveur NTP exposé inutilement peut fournir des informations et, selon son implémentation, participer à des abus par amplification.

7. Annoncer le routeur avec l’option DHCP 42

RouterOS possède un champ ntp-server dans chaque réseau DHCP. Il correspond à l’option 42 et accepte jusqu’à deux adresses.

/ip dhcp-server network
set [find where address="192.168.88.0/24"] \
    ntp-server=192.168.88.1
/ip dhcp-server network print detail \
    where address="192.168.88.0/24"

Les clients doivent renouveler leur bail ou se reconnecter au réseau. DHCP n’impose toutefois pas l’usage de l’option 42 : le serveur ne la transmet normalement que si le client la demande, et certains systèmes gardent leur propre politique de temps. Les postes membres d’un domaine, par exemple, doivent respecter la hiérarchie de temps définie par ce domaine.

8. Rediriger UDP 123 : une option, pas un réflexe

Un appareil embarqué peut ignorer DHCP et interroger une adresse NTP codée en dur. RouterOS peut rediriger vers son propre service les requêtes UDP 123 destinées à une adresse non locale.

/ip firewall nat
add chain=dstnat action=redirect to-ports=123 \
    in-interface-list=LAN protocol=udp dst-port=123 \
    dst-address-type=!local \
    comment="NTP: rediriger le LAN vers RouterOS"

Placez cette règle avant une règle dstnat plus générale qui intercepterait déjà le paquet. Le test dst-address-type=!local évite de reprendre une demande déjà adressée au routeur.

La redirection possède quatre limites importantes :

  • elle ne corrige pas un client défectueux qui émet des milliers de requêtes : elle déplace sa charge vers le MikroTik ;
  • elle masque au client l’identité réelle de la source et doit être documentée ;
  • elle peut casser une politique NTP authentifiée ou un serveur qui doit joindre une référence précise ;
  • elle ne remplace pas la configuration des appareils administrables.

Créez une liste d’exclusion pour les contrôleurs de domaine, les serveurs NTS, les équipements GPS/PTP ou les laboratoires qui doivent joindre une source déterminée, puis ajoutez src-address-list=!ntp-bypass à la règle.

/ip firewall address-list
add list=ntp-bypass address=192.168.88.10 \
    comment="Serveur de temps autonome"

/ip firewall nat
set [find where comment="NTP: rediriger le LAN vers RouterOS"] \
    src-address-list=!ntp-bypass

9. Tester depuis plusieurs systèmes

Contrôlez d’abord les compteurs RouterOS.

/ip firewall filter print stats where comment~"NTP:"
/ip firewall nat print stats where comment~"NTP:"
/ip firewall connection print where protocol=udp dst-port=123
/log print where topics~"ntp"

Puis interrogez le routeur depuis les clients.

# Linux avec chrony
chronyc sources -v
chronyc tracking

# Windows
w32tm /stripchart /computer:192.168.88.1 /dataonly /samples:5

# macOS
sntp -d 192.168.88.1

Les commandes Linux montrent la source réellement sélectionnée par le service local. Sous Windows et macOS, le test ponctuel confirme que le MikroTik répond ; il ne prouve pas que le système a changé sa source permanente. Vérifiez ensuite la configuration du service de temps propre à la plateforme.

Sécurité et précision

Le NTP classique n’est pas chiffré et, sans clé partagée, n’authentifie pas cryptographiquement la source. Centraliser les clients réduit les sorties directes et facilite l’observation, mais ne protège pas le trajet entre RouterOS et ses sources contre un adversaire placé sur le chemin.

RouterOS documente l’usage de clés symétriques NTP. Elles ne fonctionnent que si le serveur amont et le client partagent une clé configurée de façon cohérente. Pour une exigence élevée d’intégrité, étudiez un serveur interne prenant en charge Network Time Security, une référence GNSS correctement sécurisée ou un service de temps contractuel. NTS est défini par la RFC 8915 et ne doit pas être confondu avec une simple redirection UDP.

Dépannage

SymptômeCause probableVérification
Client RouterOS en waitingDNS, route ou UDP 123 bloquéRésoudre les FQDN, contrôler les pairs et le pare-feu de sortie
Le routeur répond avec une heure non valideAmont perdu ou use-local-clock=yesContrôler le statut, le stratum et désactiver l’horloge locale
Les clients ne voient pas l’option 42Bail ancien ou option non demandéeRenouveler le bail et inspecter la politique NTP du client
Le compteur NAT reste à zéroClient déjà configuré sur le routeur ou règle mal placéeTester une destination externe et contrôler l’ordre dstnat
Le MikroTik reçoit trop de paquetsObjet connecté défectueux ou boucleIdentifier l’adresse source, isoler le client et corriger son micrologiciel
Une application refuse l’heure après redirectAuthentification ou destination stricteAjouter l’équipement à ntp-bypass
NTP répond depuis InternetRègle input WAN trop permissiveTester depuis l’extérieur et vérifier les compteurs de rejet

Retour arrière

Retirez d’abord la redirection, puis l’annonce DHCP et le service. Ne supprimez les sources que si elles ont été créées exclusivement pour ce projet.

/ip firewall nat remove \
    [find where comment="NTP: rediriger le LAN vers RouterOS"]
/ip firewall filter remove [find where comment~"NTP:"]
/ip firewall address-list remove [find where list="ntp-bypass"]
/ip dhcp-server network set \
    [find where address="192.168.88.0/24"] ntp-server=""
/system ntp server set enabled=no
/system ntp client servers remove [find where comment~"NTP Pool BE"]

Si le client NTP du routeur existait avant cette procédure, laissez-le actif. Le routeur a lui aussi besoin d’une horloge correcte pour ses journaux, certificats et tâches planifiées.

Conclusion

Le bon déploiement ne consiste pas à activer tous les modes NTP. RouterOS se synchronise en unicast sur plusieurs sources, sert ensuite le LAN en unicast, annonce son adresse avec l’option DHCP 42 et refuse les requêtes venues du WAN. Cette architecture est simple, mesurable et facile à documenter.

La redirection transparente peut contenir des appareils qui ignorent la politique du réseau, mais elle doit être surveillée et assortie d’exceptions. L’objectif reste une heure cohérente et traçable, pas seulement un compteur NAT qui augmente.

Références techniques

À propos de l’auteur

Jeremy Kraft administre les infrastructures et les services auto-hébergés de l’IBCSC. Ces guides reprennent des configurations réellement déployées, revérifiées avant publication.

Discussion

Commentaires

0

Aucun commentaire pour le moment. Vous pouvez ouvrir la discussion avec une question ou un retour d’expérience.

Vous avez un compte ? Se connecter

Texte simple, 2 000 caractères maximum. Les nouveaux commentaires sont modérés. Votre nom sera affiché avec le commentaire. Aucune adresse e-mail n’est demandée ; seule une empreinte non réversible de votre adresse IP est conservée pour lutter contre le spam.