Clientul Windows NTP nu se sincronizează cu serverul Linux

Încerc să sincronizez ora a trei computere dintr-o rețea locală. Deși a avea cea mai mică deriva/eroare posibilă cu lumea/internetul ar fi grea, nu este concertul meu. Principala mea preocupare este să am cea mai bună sincronizare posibilă între cele trei computere.

Pentru a realiza acest lucru, am configurat una dintre cele două mașini Ubuntu (192.168.1.50) să acționeze ca un server ntp. Am făcut acest lucru editând fișierul de configurare a serverului ubuntu ntp în /etc/ntp.conf si adauga:

server 127.127.1.0 iburst
fudge 127.127.1.0 stratul 10

Apoi, am verificat dacă celălalt computer Ubuntu (192.168.1.71) este sincronizat cu acesta. Mai întâi am adăugat server controlstation preferă iburst până la sfârșitul /etc/ntp.conf și a repornit serviciul de timp cu sudo service ntp restart. După aceea, pot verifica dacă aceste două computere sunt sincronizate corect în timp prin rulare ntpdate -q 192.168.1.50:

server 192.168.1.50, stratul 2, offset 0,001271, întârziere 0,02599
 8 Mar 11:06:36 ntpdate[17648]: ajustați serverul de timp 192.168.1.50 offset 0,001271 sec

Acest lucru pare să funcționeze corect și 0,001271 offset este acceptabil pentru scopul meu. Următorul este să faceți același lucru cu Windows (192.168.1.201). Mai întâi verific dacă computerele sunt de fapt nesincronizate:

w32tm /stripchart /computer:192.168.1.50
12:10:01, d:+00.0010124s o:-00.4908814s [ *| ]
12:10:03, d:+00.0005757s o:-00.4907188s [ *| ]

Ceea ce are sens, deoarece clientul Windows este până acum sincronizat cu time.windows.com:

w32tm /query /status
Indicator de salt: 0 (fără avertizare)
Strat: 4 (referință secundară - sincronizare prin (S)NTP)
Precizie: -23 (119,209 ns per bifă)
Întârziere la rădăcină: 0,0386977s
Dispersia rădăcină: 8,2445365s
ReferenceId: 0x33917B1D (IP sursă: 51.145.123.29)
Ora ultimei sincronizări cu succes: 08.03.2022 12:13:23
Sursa: time.windows.com,9
Interval sondaj: 10 (1024s)

Am schimbat serverul de timp cu w32tm /config /update /manualpeerlist:192.168.1.50,0x8 /syncfromflags:MANUAL și a forțat o resincronizare w32tm /resync:

Se trimite comanda de resincronizare la computerul local
Comanda a fost finalizată cu succes.

Apoi, a verificat din nou diferența de timp dintre serverul ubuntu ntp și această mașină Windows:

w32tm /stripchart /computer:192.168.1.50
Urmărire 192.168.1.50 [192.168.1.50:123].
Ora curentă este 08.03.2022 12:22:01.
12:22:01, d:+00.0005075s o:-00.4568042s [ *| ]
12:22:03, d:+00.0010415s o:-00.4566323s [ *| ]
12:22:05, d:+00.0009737s o:-00.4569219s [ *| ]

Ceea ce arată că clientul Windows ntp nu este în mod clar sincronizat cu serverul ubuntu ntp. Totuși, dacă verific starea:

w32tm /query /status
Indicator de salt: 0 (fără avertizare)
Strat: 3 (referință secundară - sincronizare prin (S)NTP)
Precizie: -23 (119,209 ns per bifă)
Întârziere la rădăcină: 0,0314761s
Dispersia rădăcină: 8,2468633s
ReferenceId: 0xC0A80132 (IP sursă: 192.168.1.50)
Ora ultimei sincronizari cu succes: 08.03.2022 12:20:37
Sursa: 192.168.1.50,8
Interval sondaj: 10 (1024s)

Este clar că sursa este cea corectă (192.168.1.50) și că a fost sincronizată chiar înainte de interogare.

Sunt aceste mașini Windows conectate la un domeniu Active Directory?

dacă da, configurația implicită a politicii de grup va suprascrie orice configurație NTP manuală pe care o încercați.

Puteți configura în Politica de grup configurația personalizată NTP pentru mașinile client, dar este total nerecomandabil să utilizați NTP personalizat pentru stațiile de lucru client AD, deoarece acest lucru ar putea duce cu ușurință la deriva între clienții dvs. și controlerele dvs. de domeniu și dacă depășește magicul 5 minute. mark Kerberos explodează și autentificarea dvs. va începe să eșueze

Cea mai bună practică este ca rolul dvs. PDC Controller de domeniu să facă NTP pe internet, apoi toți clienții dvs. preiau prin PDC și alte controlere de domeniu

Ieșirea de stare de configurare nu arată de fapt nicio eroare sau motive pentru a crede că nu se sincronizează cu serverul NTP - ce te face să crezi că nu se sincronizează?

Este important de reținut că NTP nu se resincronizează în mod constant, ci sondajează la o anumită fereastră care încetinește treptat în timp pentru a menține încărcarea, spunând în prezent că își va sonda/sincroniza timpul la fiecare 1024 de secunde, ceea ce este puțin peste intervale de 16 minute.

De asemenea, este important de reținut că ceasurile CPU și ceasurile/cristalele CMOS de pe plăcile de bază vor avea toate variații foarte ușoare ale frecvenței, ceea ce contribuie la motivul pentru care în primul rând obțineți o variație de 456 ms, în timp ce nu pare că genial este încă. bine în tărâmurile foarte acceptabile, cu excepția cazului în care aveți de-a face cu foarte sensibile la timp (cum ar fi nevoie de o precizie mai mică de 1 s) sau bazate pe nucleu în timp real - pentru care probabil că nu ați folosi Windows în primul rând;)

De asemenea, rețineți că majoritatea implementărilor NTP încearcă din răsputeri să nu calce ceasul mașinii pe care rulează. În schimb, încearcă să accelereze ceasul pentru a ajunge în cele din urmă din urmă cu sursa de timp.Acest lucru este pentru a evita ca ceasul să sară înainte sau înapoi în timp, deoarece unor aplicații nu le place foarte mult acest lucru. Iar mai puțin de 0,5 secunde este cu siguranță sub pragul de creștere a ceasului, așa că aș paria că mașina va ajunge din urmă cu serverul NTP într-o zi sau cam asa ceva. De asemenea, rețineți că NTP (și nici PTP de altfel) nu oferă sincronizarea absolută a două mașini, este întotdeauna în limitele unei toleranțe. Nu-mi amintesc toleranțele realizabile de pe capul meu, dar sunt în jur de milisecunde cu NTP și micro/nanoscunde cu PTP.