Messages

91

German - Deutsch / Re: Probleme mit NTP

« on: May 21, 2021, 12:39:57 pm »

Die Synchronisation läuft leider nach wie vor noch nicht sauber.
Der initiale Sync nach einem (Dienst-)Neustart läuft, aber dann gleicht sich die Zeit nicht mehr ab.

Im Log treten weiterhin diese Fehler auf:

Code: [Select]

2021-05-21T11:35:15 ntpd[48751] receive: Unexpected origin timestamp 0xe451fd50.5b674221 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451fd56.1de170b5
2021-05-21T11:25:28 ntpd[48751] receive: Unexpected origin timestamp 0xe451fb03.ab0d1271 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451fb0a.96e26369
2021-05-21T10:07:25 ntpd[48751] receive: Unexpected origin timestamp 0xe451e8ba.c6dd2766 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451e8bd.55395647
2021-05-21T10:01:24 ntpd[48751] receive: Unexpected origin timestamp 0xe451e752.f0c0a0da does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451e755.1e853c52
2021-05-21T10:01:24 ntpd[48751] frequency error 5243 PPM exceeds tolerance 500 PPM
2021-05-21T10:01:22 ntpd[48751] kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
2021-05-21T09:55:48 ntpd[48751] receive: Unexpected origin timestamp 0xe451e603.f801a850 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe451e604.28fed278
2021-05-21T09:55:48 ntpd[48751] receive: Unexpected origin timestamp 0xe451e603.f7fdae3f does not match aorg 0000000000.00000000 from server@132.199.4.1 xmt 0xe451e604.289e5bfe
2021-05-21T09:55:40 ntpd[48751] kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
2021-05-21T09:55:40 ntpd[48751] kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
2021-05-21T09:55:40 ntpd[48751] Listening on routing socket on fd #48 for interface updates

Das Drift-File wird scheinbar nur beim Systemstart einmalig erstellt und dann nicht mehr angepasst.
Der Wert steht hier bei 500.000.
Wird das File gelöscht, wird es erst erst beim nächsten Neustart von OPNsense neu angelegt. Ein Neustart vom NTPd-Dienst reicht nicht aus. Der Wert im File wird im laufenden Betrieb auch nicht angepasst, sondern bleibt immer beim initialen Wert.
Das sollte doch normalerweise anders sein, oder?

92

German - Deutsch / Re: Probleme mit NTP

« on: May 20, 2021, 08:25:08 am »

1) Warum pusht mir Unraid überhaupt die Zeit "erzwungen" in die VM? Ich würde das - zumindest bei einem virtualisierten Border Gateway wie einer Firewall - nicht haben wollen, sondern diese soll selbst (als Internet-nächstes device) die Zeit holen und ggf. verteilen.

Das ist ein interessanter Punkt.
Mein Gedankengang war, dass ein Betriebssystem eine Bezugsquelle für die Zeit benötigt. Sozusagen als Ausgangslage. So wie die RTC im BIOS für Unraid wäre dann HPET für die OPNsense-VM die Basis.
Allerdings würde das Problem wie Du schreibst ja nur bis zum ersten Abgleich mit einem NTP-Server bestehen. Hier hatte ich irgendwo in den Tiefen des Internets gelesen, dass die Synchronisation mit dem Zeitserver fehlschlägt, wenn die Abweichung zu groß ist.

2) Wie kann man diesen Unbill abschalten? (denn dann sollte auch das ständige laggen in der VM nicht mehr vorkommen) Ohne die "Bremse" durch den HV würde die VM mit ntpd nämlich sehr wahrscheinlich einfach sauber vor sich hinlaufen. NTPd misst ständig nach wie sehr die Zeit laggt, stellt sich entsprechend das Drift File so ein und korrigiert ggf. ein paar ms/ns nach. Dafür ist das Driftfile da, dass quasi gemessen wird, ahja VM geht alle 1h so ~0,141542s falsch, also korrigieren.

Zum Test habe ich aus der XML-Konfiguration der VM in Unraid die komplette "clock offset"-Sektion entfernt und die VM neu gestartet. Dann habe ich mit

Code: [Select]

dmesg | grep Timecounter und

Code: [Select]

sysctl kern.timecounter die Konfiguration überprüft.
Interessanterweise waren die ausgegebenen Werte exakt gleich mit denen, als die "clock offset"-Sektion noch enthalten war.
Als Zeitzähler wurde wieder HPET erkannt und gewählt.
Aber:
Seit der Anpassung vor etwa 7 Stunden hinkt die Zeit in der OPNsense schon wieder gut 3 Minuten nach. Die NTP-Synchronisation scheint wieder nicht zu funktionieren. "Sync Source" sagt "Keine aktiven Peers verfügbar", im NTP-Status steht bei allen Servern "Unerreichbar/Ausstehend". Im NTP-Protokoll sind keine Fehlermeldungen/Warnungen gelistet.
Mit der Konfiguration zuvor hatte die Synchronisation jetzt über 2 Tage durchgängig funktioniert. Im Protokoll gab es zwar die erwähnten Warnungen, aber es lief zumindest.

Apropos Drift-File:
Mit ACPI-fast war die Abweichung im Drift-File bei -0.019.
Mit HPET steht die Abweichung auf 500.000. Eine Anpassung des Wertes findet nicht statt!
Zum Test habe ich jetzt nochmal das Drift-File gelöscht und den NTPd-Dienst neu gestartet. Für den Moment läuft die Zeitsynchronisation gerade. Mit dem Neustart des Dienstes wurde kein neues Drift-File angelegt.

3) Man sollte ggf. mal die Hardware oder den Unraid prüfen, warum zum Geier der ständig so "hinkt" und ihm dann ggf. entweder die Sense oder selbst einen NTPd verpassen, damit er ordentlich läuft.

Hier habe ich bisher die BIOS-Einstellungen überprüft und keine Fehler gefunden. Die Spannung der BIOS-Batterie ist auch OK. Und das BIOS ist ebenfalls aktuell.
Unraid ist eine "frische" Standardinstallation.
Aktuell bezieht Unraid die Zeit von den selben öffentlichen NTP-Quellen wie OPNsense. Der Abgleich funktioniert hier.
Wo kann ich hier noch ansetzen?

4) Intern alle Kisten HW/VM so einstellen, dass sie sich die Sense VM und den HV Host (der dann NTP gestützt hoffentlich richtig läuft) als NTPs nehmen. Dann reden nur 1-2 Geräte mit NTP draußen, sind korrekt gesetzt und geben intern den Ton an.

Das wäre meine Wunschkonfiguration!



---
Edit zu Punkt 2)
nach Löschen des Drift-Files und Neustart des NTPd-Dienstes lief die Synchronisation nur einmalig. Seitdem gab es keine neue Synchronisation mehr. Das Fehlerbild sieht aus wie gehabt. Die Zeit liegt inzwischen wieder knapp 1 Minute zurück.
Ich gehe jetzt vorerst wieder zurück auf den Zustand vor entfernen der "clock offset"-Sektion.

93

German - Deutsch / Re: IPv6 und DHCP Server richtig konfigurieren

« on: May 18, 2021, 01:17:10 pm »

@Simaryp
steht für das nächste Release im Juli auf der Roadmap:
https://opnsense.org/about/road-map/

Im Github wird dazu auch schon fleißig gewerkelt.

94

German - Deutsch / Re: Probleme mit NTP

« on: May 16, 2021, 09:10:10 pm »

Könnte es nicht so sein, dass der Hypervisior (Hier Unraid bzw. was auch immer die benutzen) die Zeit immer wieder stellt und dann der ntpd in der VM dann durcheinander kommt?

Das war auch meine Theorie weshalb ich hier nochmal explizit nachgefragt hatte.

Daher hatte ich vorbeugend nicht nur das Drift-File glöscht, sondern auch den NTP-Client am Host deaktiviert.

Seit der Anpassung vor ca. 19 Stunden liegt die Zeit am Host jetzt ziemlich genau 10 Minuten zurück.
Das ist eine interessante Erkenntnis, da nun zum einen klar ist, dass die BIOS-Uhr zu langsam läuft, und zum andern, dass die VM die Zeit über HPET nicht an den Host zurücksynchronisiert.

In OPNsense ist die Zeit übrigens noch immer aktuell!
Die zyklische Synchronisation via NTP mit den öffentlichen Zeitservern läuft sauber. Zwischen den Zyklen kommt es immer wieder zu einigen Sekunden Abweichungen (ca. 10 Sekunden in 15 Minuten). Mit der nächsten Synchronisation wird das dann wieder korrigiert.

Die Fehlermeldungen sind übrigens geblieben:

Code: [Select]

2021-05-16T20:56:56 ntpd[91227] receive: Unexpected origin timestamp 0xe44be974.174fb3c5 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe44be97a.e819171d

Zusammenfassend würde ich also folgendes Festhalten:

• Das Löschen des Drift-Files und/oder die Umstellung auf HPET haben offenbar geholfen
• Die VM synchronisiert die Zeit über HPET nicht auf den Host zurück
• Der Zeitgeber des Hosts läuft zu langsam
• Möglicherweise war das Drift-File garnicht das Problem, sondern die Zeitsprünge die sich durch die Zeitkorrekturen bei der NTP-Synchronisationen am Host ergeben haben. Zum Test (und zur Korrektur der Zeit in Unraid) habe ich NTP wieder aktiviert und beobachte ob und wie sich das auf die Zeitsynchronisation in OPNsense auswirkt.

Jetzt wäre die nächste Frage: Was kann ich gegen die zu langsam laufende Zeit am Host machen?

Was passiert eigentlich, wenn du den ntpd in der Opnsense mal deaktivierst? Bleibt dann die Zeit konstant?

Ich vermute mal die Zeit würde im gleichen Maße zu langsam laufen wie am Host.

Wenn ja, dann kannst du als externen Server 127.127.1.0 nehmen, dann nimmt er sich selbst als Source.

Ich denke nicht dass das hier weiterhelfen wird, aber der Tipp ist genial! Danke dafür!
Gut zu wissen dass es diese Möglichkeit gibt.

95

German - Deutsch / Re: Probleme mit NTP

« on: May 16, 2021, 01:08:43 am »

Hallo KH,

in /var/db/ntpd.drift stand -0.019.
Ich habe vorbeugend jetzt die Datei gelöscht und ntpd neu gestartet.

Jetzt werde ich wieder beobachten.


Die BIOS-Batterie des Hosts dürfte OK sein. Das Board wurde erst vor ca. 3 Monaten neu gekauft.

Der Gedanke mit dem cron-Job war mir auch schon gekommen. Sofern möglich möchte ich diese Vorgehensweise aber vermeiden. Ist ja auch wieder eher so ein Workaround als eine tatsächliche Lösung.


Mal generell gefragt:
Wie verhält es sich mit der Synchronisation zwischen Host und Gast?
Also das Board verfügt über eine RTC. Über das installierte Betriebssystem (in meinem Fall Unraid) habe ich die Möglichkeit die Systemzeit einzustellen. Manuell oder via NTP. Damit wird die RTC auf dem Board korrigiert.
Dann lasse ich eine VM auf Unraid laufen die z.B. über HPET die Zeit vom Host liest und selbst nutzt.
Wenn ich jetzt in der VM die Zeit via NTP synchronisieren lasse, wird dann die Zeit auf den Host zurücksynchronisiert?

96

German - Deutsch / Re: Probleme mit NTP

« on: May 15, 2021, 08:07:02 pm »

Es sah vielversprechend aus, kam dann aber doch wieder zu Abweichungen.

Ich hatte das Verhalten jetzt seit den Anpassung vorhin beobachtet.
Die Zeit verlief wunderbar synchron, bis diese Meldungen im NTP-Protokoll auftauchten:

Code: [Select]

2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.564f8c38 does not match aorg 0000000000.00000000 from server@2001:638:809:7::7 xmt 0xe44a6acf.c7f0dbb0
2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.5659de65 does not match aorg 0000000000.00000000 from server@2001:638:610:be01::104 xmt 0xe44a6acf.c6d26f56
2021-05-15T17:44:15 ntpd[78666] receive: Unexpected origin timestamp 0xe44a6acf.5656d4d0 does not match aorg 0000000000.00000000 from server@2001:638:a000:1123:123::2 xmt 0xe44a6acf.c67a89cb
Im "Status" stehen seitdem alle Server auf Unerreichbar/Ausstehend.
Erst nach Neustart des ntpd-Dienstes wird wieder mit den NTP-Servern synchronisiert.


Was bedeutet die Fehlermeldung und wie kann ich den Fehler beheben?

97

German - Deutsch / Re: Probleme mit NTP

« on: May 15, 2021, 03:37:10 pm »

Vielen Dank für diesen Tipp!!

Code: [Select]

root@ADL15-FW001:~ # sysctl kern.timecounter.hardware
kern.timecounter.hardware: HPET
OPNsense nutzt jetzt tatsächlich HPET.

Code: [Select]

root@ADL15-FW001:~ # dmesg | grep Timecounter
Timecounter "HPET" frequency 100000000 Hz quality 950
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec


Code: [Select]

root@ADL15-FW001:~ # sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: i8254(0) ACPI-fast(900) HPET(950) TSC-low(-100) dummy(-            1000000)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 49369
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 3004578
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 100000000
kern.timecounter.tc.HPET.counter: 2725944664
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1908553173
kern.timecounter.tc.TSC-low.counter: 1216703817
kern.timecounter.tc.TSC-low.mask: 4294967295

Ich werde die Zeit jetzt mal genau im Auge behalten.

98

German - Deutsch / Re: Probleme mit NTP

« on: May 15, 2021, 02:13:03 pm »

Code: [Select]

root@ADL15-FW001:~ # sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-fast

Hier kommt ACPI-fast.
Wie kann ich das umstellen?

99

German - Deutsch / Re: Probleme mit NTP

« on: May 15, 2021, 11:42:35 am »

Was ich gelesen habe fragt der NTP-Dienst regelmäßig seine Zeitquelle ab, legt den Intervall hierfür aber eigenständig fest. Man kann dieses Verhalten wohl beeinflussen indem man einen Minimalwert und einen Maximalwert dafür festlegt.

Häufigeres Abfragen würde die Probleme sicherlich verringern, aber wohl nicht beheben.
Einige Zeitserver blocken die Peers bei zu häufigen Anfragen. Ich müsste dann zwangsläufig auf die Variante mit dem dediziertem Zeitserver im LAN arbeiten.
Grundsätzlich gibt es aber einige Dienste die Probleme mit den Zeitsprüngen haben die sich bei den Sychronisationen ergeben. Das lässt sich wohl nur lösen indem die eigentlich Ursache gefunden und behoben wird.

Hier klingt für mich der Ansatz mit den Zeitzählern sehr vielversprechend.
Allerdings weiß ich leider noch nicht wie ich die nötigen Anpassungen vornehmen kann und welches die richtigen Werte seitens Unraid und seitens OPNsense wären.

100

German - Deutsch / Re: Probleme mit NTP

« on: May 15, 2021, 01:15:06 am »

Ich denke dieser Ansatz wäre zwar intern für die anderen Geräte im LAN hilfreich, aber für die OPNsense-Instanz nicht zielführend.

Nach meinem Verständnis ist es unerheblich woher OPNSense die aktuelle Zeit bezieht. Die Abfrage bei einem (bzw. mehreren redundanten) öffentlichen NTP-Server(n) funktioniert ja und wird es sicherlich ebenso von einem NTP-Server im LAN.
Aber solange es beim internen Zeitzähler hardwarseitig, oder wie hier innerhalb der virtuellen Umgebung, immer wieder zu (teils größeren) Abweichungen kommt, wird OPNSense zumindest bis zur nächsten NTP-Abfrage wieder mit der falschen Zeit laufen. Bei einer zu großen Abweichung scheitert dann wohl auch die Abfrage an sich und die Systemzeit läuft gänzlich willkürlich.

Alle Fragen nach der Zeit (123/TCP / 123/UDP) aus dem LAN werden von Firewall/Gatway/Router auf diese Maschine umgelenkt.

Das wäre ja nur dann erforderlich, wenn an einem Client im LAN der Zeitserver hard-coded wäre und man Zeitabweichungen zwischen dem eigenen internen Zeitserver und dem hart kodiertem öffentlichen vermeiden wöllte. Das ist bei meinen Geräten nicht der fall. Hier kann ich die Adresse des Zeitservers überall statisch festlegen, oder via DHCP übergeben. Eventuelle zeitabweichungen sollten aber auch nicht allzu gravierend sein.

101

German - Deutsch / Re: Probleme mit NTP

« on: May 14, 2021, 04:58:39 pm »

Danke für Deine Einschätzung JeGr.
Ich denke auch es wäre sinnvoller zuerst die Systemzeit von Unraid und OPNsense in Einklang zu bringen.

Wenn ich bisher alles richtig interpretiere werden in der aktuellen Standardkonfiguration Host-seitig von Unraid folgende Timer zum Abgleich zur Verfügung gestellt:

• rtc (catchup)
• pit (delay)
• hpet (not present)

OPNsense unterstützt folgende Timer:

• i8254 (0)
• ACPI-fast (900)
• TSC-low (-100)
• dummy (-1000000)

   
Wobei in meinem Fall aktuell wohl "ACPI-fast" genutzt wird.

Damit Unraid und OPNsense sich abgleichen können müssen die verwendeten Timer auf beiden Seiten identisch sein.
Hier erkenne ich aber keine Übereinstimmungen.

Im Unraid-Forum habe ich den Hinweis gefunden, dass man 'tsc' als Timer in Unraid zur Konfiguration hinzufügen kann. So ist es auch in der libvirt-Dokumentation aufgeführt.

Wie kann ich der OPNsense sagen sie soll statt 'ACPI-fast' 'TSC-low' nutzen?
Und wäre das überhaupt der richtige Ansatz?

102

German - Deutsch / Re: Probleme mit NTP

« on: May 14, 2021, 11:28:29 am »

Vielen Dank für die Anmerkungen.
Sie haben mich auf jeden Fall schon mal ein Stück weiter geführt.

Ich hatte die Themen alle in dem Thread aufgeführt, weil ich leider nicht beurteilen kann in wie weit hier eventuell Zusammenhänge bestehen.
Nicht dass hier etwas übersehen wird weil ich ein womöglich wichtiges Detail weggelassen habe.

Vielleicht versuche ich es etwas besser zu strukturieren:

Die Systemzeit in OPNsense (VM) beginnt immer wieder vom VM-Host (Unraid) abzuweichen.
Ich habe hierzu etwas recherchiert. Offenbar verwendet OPNsense (FreeBSD) bestimmte Zeitzähler.
Meine ausgelesenen Werte wären:

Code: [Select]

root@ADL15-FW001:~ # dmesg | grep Timecounter
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
Timecounter "i8254" frequency 1193182 Hz quality 0
Timecounters tick every 10.000 msec

Code: [Select]

root@ADL15-FW001:~ # sysctl kern.timecounter
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 0
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: i8254(0) ACPI-fast(900) TSC-low(-100) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 19671
kern.timecounter.tc.i8254.mask: 65535
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 1961978
kern.timecounter.tc.ACPI-fast.mask: 16777215
kern.timecounter.tc.TSC-low.quality: -100
kern.timecounter.tc.TSC-low.frequency: 1909497435
kern.timecounter.tc.TSC-low.counter: 4174462623
kern.timecounter.tc.TSC-low.mask: 4294967295Unter Unraid wurden in der Konfiguration der VM bei Erstellung (automatisch) folgende Werte dazu gesetzt:

Code: [Select]

<clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>Die Werte für die Zeitzähler in der VM-Konfiguration unter Unraid und die die OPNsense nutzt müssen nach meinem Verständnis zusammenpassen.
Allerdings konnte ich noch nicht herausfinden welche Anpassungen genau an welcher Stelle hier vorzunehmen sind damit alles zusammenpasst.
Ich habe hierzu auch schon einen Thread im Unraid-Forum eröffnet.


Die chrony-Erweiterung lässt sich nicht aktivieren.
Bei mir war es leider so, dass ich auch nach einem Neustart nicht mehr auf das Web-Inferface gekommen bin.
Bzw. in einem weiteren Versuch konnte ich die Weboberfläche kurzzeitig nach dem Start erreichen. Sobald ich dann aber auf "Dienste" -> "chrony" bin war ich wieder ausgesperrt.


Der vom Provider zugewiesene IPv6-Präfix wird in der Übersicht der Schnittstellen unter "WAN" nicht mehr angezeigt.
Noch später am selben Abend als ich meinen Post hier eingestellt hatte wurde die Info plötzlich wieder angezeit. Von meiner Seite aus wurde hier nichts angepasst. Auch die Internetverbindung wurde nicht neu aufgebaut.

Ich vermute hier einfach mal, dass es zu den verschiedensten Problemen kommen kann wenn OPNsense außer Sync gerät und wahrscheinlich einige Probleme verschwinden würden wenn hier der Sync mit dem Host sauber laufen würde.


Ist mein Ansatz hier der richtige?
Weiß jemand welche Anpassungen ich hier machen könnte um den Fehler zu beheben?
Ist meine ntpd-Konfiguration ansonsten korrekt?
Gibt es einen Trick wie ich chrony dennoch aktivieren kann?

103

German - Deutsch / Re: Probleme mit NTP + kein IPv6-Präfix

« on: May 12, 2021, 07:07:15 pm »

Mir ist eben aufgefallen dass der Fehler seit Thread-Erstellung eben wieder aufgetreten ist.

im ntpd-Protokoll steht folgendes:

Code: [Select]

2021-05-12T19:00:03 ntpd[71141] receive: Unexpected origin timestamp 0xe4468813.3c7638f4 does not match aorg 0000000000.00000000 from server@2001:638:a000:1123:123::2 xmt 0xe4468813.6915f562

Code: [Select]

2021-05-12T18:59:56 ntpd[71141] kernel reports TIME_ERROR: 0x4041: Clock Unsynchronized
Außerdem ist mir unter "Schnittstellen" -> "Überblick" bei der WAN-Schnittstelle aufgefallen, dass dort kein vom Provider zugewiesener IPv6-Präfix mehr angezeigt wird.
Ich habe die PPPoE-Verbindung nochmal neu laden lassen, aber erhalte dennoch keinen Präfix mehr.
Das finde ich auch etwas merkwürdig.

Provider ist die Deutsche Telekom; mein Tarif ist Magenta Zuhause L (VDSL100); als Modem wird ein Draytek Vigor 166 im Bridge-Modus eingesetzt. PPPoE-Einwahl und VLAN7-tagging übernimmst die OPNsense.


Was stimmt hier nicht?

104

German - Deutsch / Probleme mit NTP

« on: May 12, 2021, 04:11:10 pm »

Hallo liebe OPNsense-Gemeinde,

ich habe ein Problem mit der Systemzeit in meinem Netzwerk.

Folgende Ausgangssituation:
OPNsense 21.1.5-amd64 auf Unraid 6.9.2 als VM
VM-Konfiguratioin unter Unraid: "Gerät": i440fx-5.1"; BIOS: "OVMF"; 2 logigische CPUs isoliert zugewiesen; 4GB RAM zugewiesen; CPU-Modus "Pathtrough"; 2 Ports einer 4-Port Intel I350-PCIe-Karte an OPNsense durchgereicht

In OPNsense unter "Netzwerk-Zeit" sieht es wie folgt aus:
Schnittstelle(n): "Nothing selected"
Zeitserver: insgesamt 4 Zeitserver eingetragen, 2 davon bevorzugt; alle 4 sind gültig und erreichbar
sonst sind die Standardeinstellungen gesetzt.

Die Zeitsynchronisation läuft immer wieder sauber durch. Die Clients können ihre Zeit auch problemlos von der OPNsense beziehen. Nach einiger Zeit scheint die Synchronisation jedoch nicht mehr zu funktionieren. Die Systemzeit der OPNsense weicht nach 24 Stunden bis zu 30 Minuten von der tatsächlichen Zeit ab.
Wird der ntpd-Dienst neu gestartet funktioniert dann wieder alles.

Ich habe jetzt gelesen, dass es unter virtuellen Installationen derartige Probleme geben kann, da die Hardware-Zeit der BIOS-Uhr nicht richtig durchgereicht werden kann, bzw. deren Virtualisierung Probleme bereitet.

In diesen Fällen wird dann wohl dazu geraten Statt ntpd "chrony" zu verwenden, da das in derartigen fällen wohl robuster ist.

Ich habe daher die Erweiterung "os-chrony" installiert, dann den Dienst ntpd-Dienst gestoppt, alle vorhandenen Einträge unter ntpd gelöscht und ntpd somit deaktiviert.


Dann habe ich in der Konfiguration zu chrony den Haken bei "Aktiviert" gesetzt, den Port von "323" auf "123" geändert, die gleichen Zeitserver wie zuvor unter ntpd genutzt eingetragen, und meine internen Netzwerke unter "erlaubte Netzwerke" hinterlegt.

Sobald ich nun auf "Speichern" klicke ist die Weboberfläche nicht mehr erreichbar. Auch nicht nach einem Neustart über die Konsole. Ich muss erst ein Backup einspielen damit ich wieder auf die Webkonfiguration gelange. Der Fehler lässt sich beliebig oft reproduzieren.

Zum Test habe ich bei meiner Vorgehensweise in chrony die Standardkonfiguration belassen und lediglich den Haken bei "Aktiviert" gesetzt. Auch dann war die Weboberfläche ab diesem Moment nicht mehr zu erreichen.

Wo liegt hier der Fehler?
Wie kann ich chrony nutzen und sicherstellen, dass die Zeit auf meinen Systemen synchron bleibt?