Ich habe zu Hause einen Breitbandanschluss von Airtel (ISP). Derselbe ISP ist auch mein Mobilfunkanbieter. Ich habe einen DIR 615-Router, der mit einem Breitbandanschluss von Airtel verbunden ist, sowie einen Windows 10-Desktop und einen Laptop.
Wenn ich Airtel Broadband verwende, können beide Windows 10-PCs die Zeit nicht mit verschiedenen Internet-NTP-Servern synchronisieren. Es wird eine Zeitüberschreitung angezeigt. Ich habe über 10 – 12 NTP-Server ausprobiert. Andere Geräte wie meine Linux-VM und der DIR 615-Router können die Zeit jedoch über dieselbe Breitbandverbindung mit denselben NTP-Servern ordnungsgemäß synchronisieren. Wenn ich jedoch unter Windows 10 zu VPN wechsle und den ISP umgehe, kann der Windows 10-PC die Zeit erfolgreich mit verschiedenen NTP-Servern synchronisieren.
Wenn ich außerdem Anwendungen von Drittanbietern wie Nistime32bit.exe verwende, synchronisieren diese die Zeit erfolgreich mit NTP-Servern auf demselben Windows 10-PC über Airtel Broadband. Ich habe es sowohl auf den Ports TCP 13 als auch UDP 123 versucht. Wenn ich jetzt ein mobiler Hotspot von Airtel bin, synchronisieren beide Windows 10-PCs die Zeit ordnungsgemäß, ohne dass ein Timeout-Fehler auftritt. Es ist kaum zu glauben, dass der ISP ausgehende Ports blockiert, da Router und Linux-VM im selben Netzwerk und sogar Apps von Drittanbietern auf Windows 10-PCs ordnungsgemäß synchronisiert werden. Dennoch treten auf Windows 10-PCs mit dem integrierten Prozess von Windows 10 Fehler auf. Es ist kaum zu glauben, dass es ein Problem mit beiden Windows 10-Betriebssystemen gibt, da sie über den mobilen Hotspot ordnungsgemäß synchronisiert werden. Der W32time-Dienst läuft auf beiden PCs einwandfrei.
Ich habe meinen ISP um Hilfe gebeten, aber er reagiert nicht.
Weiß jemand, was hier wirklich passiert? Was kann ich noch versuchen, um das Problem zu beheben und wo könnte es liegen? Ich habe die Ereignisanzeige überprüft, es gibt eine Menge Ereignisse, aber nichts Sinnvolles gefunden.
Die Firewall ist sowohl im Router als auch in Windows 10 vollständig AUSGESCHALTET. Dieselben Ergebnisse, wenn ich den Router umgehe und eine direkte PPPoE-Verbindung von meinem PC zum ISP herstelle.
Bearbeiten, nachdem Kommentare angezeigt und geantwortet wurde.
Ich habe mehrere Server ausprobiert, darunter auch einige in meinem Land, aber das Verhalten ist das Gleiche. Breitband – Fehler, VPN – Erfolg, mobiler Hotspot – Erfolg. Router mit Breitband – Erfolg, Linux-VM mit Breitband – Erfolg.
Vielen Dank @user1686 für die ausführliche Antwort. Das war das fehlende Glied im Puzzle.
Alle ISPs in meinem Land arbeiten und verhalten sich gleich. Sie alle blockieren eingehende Ports unter 1024. Ich war der Meinung, dass die NTP-Synchronisierung vom Client zum Server erfolgt, wusste aber nichts über die symmetrische 123 < -- > 123 von Windows, sodass sogar die eingehende 123 eine Rolle spielt.
Ich habe jetzt getestet, dass mein ISP eingehende UDP 123 tatsächlich blockiert, indem er Magic Packets sendet, um meinen PC aus der Ferne zu starten. Wenn ich es beispielsweise an UDP 4000 (geroutet zu UDP 9 im Router) sende, wird es über mein mobiles Internet an die öffentliche Breitband-IP aktiviert, aber bei UDP 123 (geroutet zu UDP 9) schlägt es fehl. Ich habe auch ein kleines Dienstprogramm namens SimplePort Tester (PCWinTech.com) verwendet, um erneut zu überprüfen, dass eingehende UDP 123 tatsächlich nicht zugänglich ist.
Ich habe versucht, die Zeit auf meiner Windows XP-VM zu synchronisieren, in der Annahme, dass sie möglicherweise älteres NTPv3 verwendet, aber die Zeitsynchronisierung über Breitband schlug sogar fehl. Es sieht also so aus, als ob sogar XP damals 123 < -- > 123 verwendet hat.
Ich werde meinen ISP davon überzeugen, eingehendes UDP 123 zumindest für einige Zeit zum Testen zu öffnen, aber die Chancen, dass mein Antrag überhaupt berücksichtigt wird, sind sehr gering!
Antwort1
Die meisten NTP- und SNTP-Clients arbeiten im „Client/Server“-Modus. Dies ist dasselbe wie bei anderen UDP-Clients – der Computer sendet eine NTP-Abfrage von einem temporären Port an den NTP-Port 123 des Servers und erhält eine Antwort von Port 123 an diesen temporären Port zurück. Dies ist höchstwahrscheinlich das Verhalten Ihres Linux-NTP-Clients.
Der in Windows integrierte NTP-Client verwendet jedoch den „symmetrischen“ Modus, in dem er Pakete sendetvom lokalen Port 123an den Port 123 des Servers. Die Antworten kommen ebenfalls vom Remote-Port 123 an den lokalen Port 123.
(Diese symmetrische Portnutzung ist gewissermaßen einzigartig für NTP und kommt häufiger in Peer-to-Peer-Situationen vor, wenn zwei NTP-Server miteinander synchronisiert werden. Ich bin nicht sicher, warum Windows dies tut, aber es könnte daran liegen, dass Windows Server als Teil der AD DC-Funktionalität als echter NTP-Server fungieren kann.)
Das Problem mit dem „symmetrischen“ Modus ist jedoch, dasszu einer Netzwerk-Firewall,Diese eingehenden Antworten auf Ihren Port 123 sind völlig nicht zu unterscheiden 1 von eingehendenAnfragenzu Port 123.
Viele ISPs setzen Firewalls auf Netzwerkebene ein, um bestimmte „riskante“ Protokolle zu blockieren, z. B. solche, die leicht zur DDoS-Verstärkung missbraucht werden können, und NTP ist leider eines dieser Protokolle. Ein ISP blockiert daher vorsichtshalber alle UDP-Pakete, die an Port 123 seiner Kunden eingehen, in der falschen Annahme, dass dies nur die Kunden daran hindert, einen NTP-Server zu betreiben.
Alternativ könnte der ISP dies in der Annahme tun, dass alle Kunden persönliche Router mit NAT haben und viele Router den lokalen Port ausgehender Pakete tatsächlich neu zuweisen – selbst wenn also ein Computer ein Paket 123→123 sendet, könnte der Router es in 61473→123 übersetzen und das Problem tritt nicht auf. Allerdings führen nicht alle Router diese Art der Neuzuordnung durch (diese Art von NAT führt häufig zu Störungen bei Spielen).
Vorschläge:
Wenn Ihr Router Ihnen die Wahl zwischen „Cone NAT“ und „Symmetric NAT“ lässt, versuchen Sie, auf Letzteres umzuschalten und prüfen Sie, ob es hilft (und nein, der Begriff hat eigentlich überhaupt nichts mit symmetrischem NTP zu tun).
Andernfalls müssen Sie möglicherweise weiterhin NTP-Clients von Drittanbietern verwenden, die im Client-Modus arbeiten und bei denen dieses Problem nicht auftritt.
Es gibt ein MicrosoftKB-Artikelüber die Angabe des zu verwendenden Modus, aber während es die Modusbits im NTP-Header beeinflusst,nichtWindows tatsächlich dazu bringen, einen anderen Quellport zu verwenden. Schade.
(NTPv3 hat festgelegt, dass der Quellportnichtim Client-Modus 123 sein, aber NTPv4 verbietet dies nicht mehr. Das könnte der Grund sein, warum Windows problemlos 123→123 verwendet, unabhängig davon, welche Modus-Flags im NTP-Header angegeben sind.)
1 Eine Stateful Firewall, wie die auf Ihrem Heimrouter,dürfenAbfragen von Antworten unterscheiden, indem zuvor gesehene ausgehende Pakete verfolgt werden. Aber während Stateful Firewalls an kleineren Netzwerkgrenzen üblich sind, vermute ich, dass sie sich nicht leicht auf die Ebene des gesamten ISPs skalieren lassen, da die Suche nach dem Status für jedes Paket eine verringerte Leistung bedeutet. Wenn der ISP also einestaatenlosFirewall ist die Aussage immer noch wahr – die beiden Arten von NTP-Paketen sind im symmetrischen Modus nicht mehr zu unterscheiden.