12
Mikrotik: Datum und Uhrzeit im Netzwerk verteilen
Moin,
innerhalb meines Netzwerks habe ich bei den Segmenten, die keinen Internetzugang haben, dass Problem, dass deren Datums/Uhrzeiteinstellungen im Verlauf zunehmend ungenauer werden oder sie einfach gar keine Datums/Uhrzeitdaten haben.
Daher möchte ich den Mikrotik (MT) als Zeitserver im Netz verwenden. Dabei habe ich aber a) ein paar NTP-Wissenslücken und b) ein Verständnisproblem wie man das beim MT am besten löst. Offenbar gibt es mehrere Stellen, an denen man konfigurieren kann.
Gerade im Segment für das Smarthome sind viele unterschiedliche Geräte im Einsatz. Bei den IP-Kameras ist es z.B. unschön, wenn der Zeitstempel im Bild nicht zur echten Zeit passt. Bei einigen Geräte wie den Shellys kann man z.B. einen SNTP-Server als Ziel angeben. Bei anderen Geräten kann man außer typischen Zeitzone/Datum/Uhrzeit-Einstellung augenscheinlich nix konfigurieren.
Die Frage ist nun, wie ich diesen Geräte-Zoo am besten mit Zeitinformationen versorgen kann - grobes Kochrezept bisher:
in jedem DHCP-Server (je Segment) unter NTP-Servers den MT mit einer IP in dem Segment angeben?
** in jedem DHCP-Server (je Segment) unter den DHCP Options die Option 42 (NTP_LIST) angeben (mit der IP des MT in dem Segment)?
Fragen über Fragen - für ein paar Tipps wäre ich sehr dankbar!
Gruß,
Tripod
innerhalb meines Netzwerks habe ich bei den Segmenten, die keinen Internetzugang haben, dass Problem, dass deren Datums/Uhrzeiteinstellungen im Verlauf zunehmend ungenauer werden oder sie einfach gar keine Datums/Uhrzeitdaten haben.
Daher möchte ich den Mikrotik (MT) als Zeitserver im Netz verwenden. Dabei habe ich aber a) ein paar NTP-Wissenslücken und b) ein Verständnisproblem wie man das beim MT am besten löst. Offenbar gibt es mehrere Stellen, an denen man konfigurieren kann.
Gerade im Segment für das Smarthome sind viele unterschiedliche Geräte im Einsatz. Bei den IP-Kameras ist es z.B. unschön, wenn der Zeitstempel im Bild nicht zur echten Zeit passt. Bei einigen Geräte wie den Shellys kann man z.B. einen SNTP-Server als Ziel angeben. Bei anderen Geräten kann man außer typischen Zeitzone/Datum/Uhrzeit-Einstellung augenscheinlich nix konfigurieren.
Die Frage ist nun, wie ich diesen Geräte-Zoo am besten mit Zeitinformationen versorgen kann - grobes Kochrezept bisher:
- Zusätzliches Package installieren, damit NTP-Client und Server verfügbar sind
- ... aber dann wird es bereits mau ... muss man z.B.
in jedem DHCP-Server (je Segment) unter NTP-Servers den MT mit einer IP in dem Segment angeben?
** in jedem DHCP-Server (je Segment) unter den DHCP Options die Option 42 (NTP_LIST) angeben (mit der IP des MT in dem Segment)?
Fragen über Fragen - für ein paar Tipps wäre ich sehr dankbar!
Gruß,
Tripod
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667304
Url: https://administrator.de/contentid/667304
Ausgedruckt am: 26.11.2024 um 08:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Solange der NTP-Server erreichbar ist, ist es egal, wo der sich befindet. Ich würde nur einen Zeitserver für das Netzwerk verwenden. Die Zeitserver-Daten kannst Du per DHCP verteilen (dort darf ein Zeitserver von "außerhalb" des DHCP-Bereiches stehen). Mache Clients benötigen aber auch eine direkte Konfiguration ihres DHCP-Clients (z.B. oft Switche).
Zum Schluss musst Du noch sicherstellen, dass die Clients den Server erreichen können, indem Du das Routing überprüfst und die NTP in der Firewall entsprechend freischaltest. Achtung, meist wird zwar UDP angegeben, aber aber TCP wird auch verwendet.
Grüße
lcer
Solange der NTP-Server erreichbar ist, ist es egal, wo der sich befindet. Ich würde nur einen Zeitserver für das Netzwerk verwenden. Die Zeitserver-Daten kannst Du per DHCP verteilen (dort darf ein Zeitserver von "außerhalb" des DHCP-Bereiches stehen). Mache Clients benötigen aber auch eine direkte Konfiguration ihres DHCP-Clients (z.B. oft Switche).
Zum Schluss musst Du noch sicherstellen, dass die Clients den Server erreichen können, indem Du das Routing überprüfst und die NTP in der Firewall entsprechend freischaltest. Achtung, meist wird zwar UDP angegeben, aber aber TCP wird auch verwendet.
Grüße
lcer
Fragen über Fragen
Warum ? Das gehört mit zu den wirklich leichtesten Übungen auf einem MT und ist eigentlich ganz einfach:- Unter System -> SNTP Client diesen aktivieren und einen Uplink NTP einstellen, damit der MT sich selber die korrekte Zeit ziehen kann. Öffentliche NTP Server findest du HIER.
- Dann konfigurierst du den MT so das er selber auch NTP Server im Netz ist. Wie das geht steht HIER.
- Sofern du Endgeräte hast die sich den NTP Server auch per DHCP Option 42 ziehen können solltest du zusätzlich bei allen DHCP Server noch die Option 42 auf die jeweilige MT IP Adresse im DHCP als NTP Server setzen.
- Fertisch
İch würde nicht ausgerechnet die TU Berlin als Beispiel nehmen. Die zeigen gerade ihre İT-İnkompetenz.
lks
Wie peinlich !! 😱
Na ja mit Erlangen gibt es ja eine gute Alternative und man muss zudem noch weniger tippen beim Hostnamen...
Na ja mit Erlangen gibt es ja eine gute Alternative und man muss zudem noch weniger tippen beim Hostnamen...
Zitat von @aqui:
Die Option muss man nicht zusätzlich definieren den gibt es schon fertig als Option in den DHCP Network Definitions - Sofern du Endgeräte hast die sich den NTP Server auch per DHCP Option 42 ziehen können solltest du zusätzlich bei allen DHCP Server noch die Option 42 auf die jeweilige MT IP Adresse im DHCP als NTP Server setzen.
Grüße Uwe
Stimmt ! Im Eifer des Gefechts glatt übersehen ! Danke für den Hinweis... 👍
Moin,
danke eure für die Rückmeldungen!
SNTP und NTP Client parallel geht glaube ich nicht? Ich habe habe es noch nicht probiert, aber die Dokumentation liest sich so, dass die Funktion automatisch deaktiviert wird, sobald man das NTP package installiert.
OK, d.h. man nimmt nur einen NTP Server für alle Segmente (und muss die FW Regeln bzgl. Port 123 durchlässig machen). Je Segment einen NTP Server ist vermutlich oversized.
danke eure für die Rückmeldungen!
Zitat von @aqui:
Unter System -> SNTP Client diesen aktivieren und einen Uplink NTP einstellen, damit der MT sich selber die korrekte Zeit ziehen kann. Öffentliche NTP Server findest du HIER.
Unter System -> SNTP Client diesen aktivieren und einen Uplink NTP einstellen, damit der MT sich selber die korrekte Zeit ziehen kann. Öffentliche NTP Server findest du HIER.
SNTP und NTP Client parallel geht glaube ich nicht? Ich habe habe es noch nicht probiert, aber die Dokumentation liest sich so, dass die Funktion automatisch deaktiviert wird, sobald man das NTP package installiert.
Zitat von @aqui:
Dann konfigurierst du den MT so das er selber auch NTP Server im Netz ist. Wie das geht steht HIER.
Dann konfigurierst du den MT so das er selber auch NTP Server im Netz ist. Wie das geht steht HIER.
OK, d.h. man nimmt nur einen NTP Server für alle Segmente (und muss die FW Regeln bzgl. Port 123 durchlässig machen). Je Segment einen NTP Server ist vermutlich oversized.
Moin,
danke eure für die Rückmeldungen!
OK, das war auch eine meiner Fragen, wo der Unterschied zwischen den Dialogen zur "manuellen" Eingabge der Option 42 und genau dieser Einstellmöglichkeit liegt.
danke eure für die Rückmeldungen!
Zitat von @colinardo:
Die Option muss man nicht zusätzlich definieren den gibt es schon fertig als Option in den DHCP Network Definitions.
Die Option muss man nicht zusätzlich definieren den gibt es schon fertig als Option in den DHCP Network Definitions.
OK, das war auch eine meiner Fragen, wo der Unterschied zwischen den Dialogen zur "manuellen" Eingabge der Option 42 und genau dieser Einstellmöglichkeit liegt.
Zitat von @Tripod:
SNTP und NTP Client parallel geht glaube ich nicht? Ich habe habe es noch nicht probiert, aber die Dokumentation liest sich so, dass die Funktion automatisch deaktiviert wird, sobald man das NTP package installiert.
Doch das ist kein Problem, läuft hier seit Jahren einwandfrei SNTP und NTP Client parallel geht glaube ich nicht? Ich habe habe es noch nicht probiert, aber die Dokumentation liest sich so, dass die Funktion automatisch deaktiviert wird, sobald man das NTP package installiert.
. Irgendwoher muss der Mikrotik ja seine eigene Zeit beziehen...Das ist in der Hilfe nur etwas missverständlich geschrieben. Damit ist gemeint das die SNTP-Client Implementierung aus dem Default-Package deaktiviert wird, aber im zusätzlichen NTP Package ist auch ein SNTP-Client enthalten der genutzt werden kann.
OK, d.h. man nimmt nur einen NTP Server für alle Segmente (und muss die FW Regeln bzgl. Port 123 durchlässig machen). Je Segment einen NTP Server ist vermutlich oversized.
Also ich habe nun ...
Dummerweise habe ich nun nach der Konfiguration festgestellt, dass
Wie kann ich die gesamte Konfiguration am besten testen?
Hinweis: Die Winbox scheint bzgl. der Konfiguration des NTP Clients einen Fehler aufzuweisen: Der Status bleibt immer auf "stopped". Wenn man sich den Status per Console mittels system ntp client print, dann steht dieser aber auf "synchronized".
- das NTP Package installiert
- NTP-Client konfiguriert
- NTP-Server konfiguriert
- in den DHCP-Server-Konfigurationen für jedes Segment jeweils die IP des MT als NTP-Server eingetragen
- an der FW habe ich nix geändert, sondern mir die Logs angeschaut. Der NTP-Client kommt ins WAN.
Dummerweise habe ich nun nach der Konfiguration festgestellt, dass
- die Shelly-Wifi-Schalter ausschließlich mit einem SNTP-Server sprechen (und offenbar nicht mit einem NTP-Server?)
- die IP-Cams lediglich eine vordefinierte Auswahlliste öffentlicher NTP-Server einstellbar haben (und nicht eine individuelle IP zulassen)
Wie kann ich die gesamte Konfiguration am besten testen?
Hinweis: Die Winbox scheint bzgl. der Konfiguration des NTP Clients einen Fehler aufzuweisen: Der Status bleibt immer auf "stopped". Wenn man sich den Status per Console mittels system ntp client print, dann steht dieser aber auf "synchronized".
Nun wenn du intern nur bestimmte Ports in der INPUT Chain freigibst dann musst du dort auch Port 123 UDP/TCP in der Firewall freigeben.
(natürlich nur ein Beispiel mit Interface Angabe und ohne Berücksichtigung der Filter-Position in deinen Chains, das musst du bei dir selbstredend anpassen!)
https://de.wikipedia.org/wiki/Network_Time_Protocol
Zitat:
Beispiel (Interface natürlich anpassen)
Damit werden dann sämtliche Anfragen auf TCP/UDP Port 123 aus dem jeweiligen Interface auf den NTP-Server des Mikrotik umgebogen, d.h. dieser beantwortet die NTP Anfragen anstatt die ursprünglich angefragten öffentlichen IPs.
Hier siehst du das im Testlab umgesetzte:
Ein Archlinux mit IP 192.168.200.2/24 hat durch die Mikrotik (IP 192.168.200.1) Firewall keinen Internetzugang, NTP-Anfragen werden wie oben beschrieben per DSTNAT auf den Mikrotik selbst umgeleitet und von diesem beantwortet
Hier siehst du wie der Mikrotik dann selbst die NTP Anfrage beantwortet im Wireshark-Protokoll (dieser "faked" ja durch das NAT die externe IP, lässt es also für den Client so aussehen als käme die Antwort tatsächlich von der externen IP).
In der
Works as designed, wie @aqui immer sagt.
/ip firewall filter
add chain=input in-interface=ether8 protocol=udp dst-port=123 action=accept
add chain=input in-interface=ether8 protocol=tcp dst-port=123 action=acceptDummerweise habe ich nun nach der Konfiguration festgestellt, dass
Ein NTP Server beantwortet auch SNTP Anfragen das Basis-Protokoll ist das gleiche, das ist also kein Problem.- die Shelly-Wifi-Schalter ausschließlich mit einem SNTP-Server sprechen (und offenbar nicht mit einem NTP-Server?)
https://de.wikipedia.org/wiki/Network_Time_Protocol
Zitat:
Der Aufbau des Protokolls ist mit dem von NTP identisch. SNTP-Clients können damit die Zeit auch von NTP-Servern beziehen.
* die IP-Cams lediglich eine vordefinierte Auswahlliste öffentlicher NTP-Server einstellbar haben (und nicht eine individuelle IP zulassen)
Wenn du dort keine anderen Server eintragen kannst du dir einfach behelfen indem du am Mikrotik per DSTNAT Anfragen auf Port 123 auf den Mikrotik umbiegst.Beispiel (Interface natürlich anpassen)
/ip firewall nat
add action=redirect chain=dstnat dst-port=123 in-interface=ether8 protocol=udp to-ports=123
add action=redirect chain=dstnat dst-port=123 in-interface=ether8 protocol=tcp to-ports=123Hier siehst du das im Testlab umgesetzte:
Ein Archlinux mit IP 192.168.200.2/24 hat durch die Mikrotik (IP 192.168.200.1) Firewall keinen Internetzugang, NTP-Anfragen werden wie oben beschrieben per DSTNAT auf den Mikrotik selbst umgeleitet und von diesem beantwortet
Hier siehst du wie der Mikrotik dann selbst die NTP Anfrage beantwortet im Wireshark-Protokoll (dieser "faked" ja durch das NAT die externe IP, lässt es also für den Client so aussehen als käme die Antwort tatsächlich von der externen IP).
Wie kann ich die gesamte Konfiguration am besten testen?
Nimm dir z.B. eine Linux Büchse und lass diese mit dem Router synchronisieren (z.B. mittels timedatectl).In der
/etc/systemd/timesyncd.conf gewünschten NTP-Server in der NTP= Direktive hinterlegen und dannsudo timedatectl set-ntp 1
sudo systemctl restart systemd-timesyncd
timedatectl show-timesync
timedatectl timesync-statusHinweis: Die Winbox scheint bzgl. der Konfiguration des NTP Clients einen Fehler aufzuweisen: Der Status bleibt immer auf "stopped". Wenn man sich den Status per Console mittels system ntp client print, dann steht dieser aber auf "synchronized".
Hmm also hier zeigt die Winbox auch Synchronized an, fahr mal ein Update deiner Winbox. Wird nur ein Anzeigefehler sein wenn die Shell Synchronized ausgibt.Works as designed, wie @aqui immer sagt
.
@colinardo
Vielen Dank für die ausführliche Info!
Ich hatte tatsächlich in FW Regeln in der Input Chain vergessen. Nachdem die drin waren, haben die Shellys, bei denen die IP des MT eingetragen war sich eine Uhrzeit gezogen.
Der Tipp mit dem Redirect ist klasse. Dadurch kann ich mir das Eintragen der IP praktisch sparen! Da wo es geht (Shellys) werde ich sie dennoch eintragen - bei den IP-Cams, also da wo es nicht geht, ist es die Rettung!
Vielen Dank für die ausführliche Info!
Ich hatte tatsächlich in FW Regeln in der Input Chain vergessen. Nachdem die drin waren, haben die Shellys, bei denen die IP des MT eingetragen war sich eine Uhrzeit gezogen.
Der Tipp mit dem Redirect ist klasse. Dadurch kann ich mir das Eintragen der IP praktisch sparen! Da wo es geht (Shellys) werde ich sie dennoch eintragen - bei den IP-Cams, also da wo es nicht geht, ist es die Rettung!
