Доброго дня шановні читачі та гості блогу сайт, як багато люди говорять про час, що він швидко або повільно біжить, і всі розуміють, що воно безцінно та важливо. Так і в інфраструктурі Active Directory, вона одна із найважливіших чинників, правильного функціонування домену. У домені всі один одному довіряють, і один раз авторизувавшись і отримавши всі тікети від Kerberos, користувач ходить куди завгодно, обмежуючись лише своїми правами. Так от якщо у вас не буде точного часу на ваших робочих станціях до контролера домену, то можете вважати, що у вас починаються серйозні проблеми, про які ми поговоримо нижче та розглянемо як їх усунути за допомогою налаштування NTP сервера в Windows.
Синхронізація часу в Active Directory
Серед комп'ютерів, що беруть участь у Active Directory, працює наступна схема синхронізації часу.
- Контролер кореневого домену в лісі AD, якому належить FSMО-роль емулятора PDC (назвемо його кореневим PDC), є джерелом часу для решти контролерів цього домену.
- Контролери дочірніх доменів синхронізують час із вищестоящих по топології AD контролерів домену.
- Пересічні члени домену (сервера та робочі станції) синхронізують свій час з найближчим до них доступним контролером домену, дотримуючись топології AD.
Кореневий PDC може синхронізувати свій час як із зовнішнім джерелом, так і з самим собою, останнє задано стандартною конфігурацією і є абсурдом, про що періодично натякають помилки в системному журналі.
Синхронізація клієнтів кореневого PDC може здійснюватися як з його внутрішнього годинника, так і з зовнішнього джерела. У першому випадку сервер часу кореневого PDC оголошує себе як "надійний" (reliable).
Далі я наведу оптимальну з моєї точки зору конфігурацію сервера часу кореневого PDC, при якій сам кореневий PDC періодично синхронізує свій час від достовірного джерела в інтернеті, а час клієнтів, що звертаються до нього, синхронізує зі своїм внутрішнім годинником.
Вводимо netdom query fsmo.У моєму прикладі роль PDC і NTP сервера належить контролеру dc7
Конфігурація NTP-сервера на кореневому PDC
Конфігурування сервера часу в Windows (NTP-сервера) може здійснюватися як за допомогою утиліти командного рядка w32tm, і через реєстр. Де можливо, я наведу обидва варіанти. Але на початку подивіться повністю ваші установки на комп'ютері, робиться це командою:
w32tm /query /configuration
EventLogFlags: 2 (Локально)
AnnounceFlags: 10 (локально)
TimeJumpAuditOffset: 28800 (локально)
MinPollInterval: 6 (локально)
MaxPollInterval: 10 (локально)
MaxNegPhaseCorrection: 172800 (локально)
MaxPosPhaseCorrection: 172800 (локально)
MaxAllowedPhaseOffset: 300 (локально)FrequencyCorrectRate: 4 (локально)
PollAdjustFactor: 5 (Локально)
LargePhaseOffset: 50000000 (Локально)
SpikeWatchPeriod: 900 (локально)
LocalClockDispersion: 10 (Локально)
HoldPeriod: 5 (Локально)
PhaseCorrectRate: 7 (локально)
UpdateInterval: 100 (локально)NtpClient (Локально)
Enabled: 1 (Локально)
InputProvider: 1 (локально)
CrossSiteSyncFlags: 2 (Локально)
ResolvePeerBackoffMinutes: 15 (Локально)
ResolvePeerBackoffMaxTimes: 7 (Локально)
CompatibilityFlags: 2147483648 (Локально)
EventLogFlags: 1 (Локально)
LargeSampleSkew: 3 (Локально)
SpecialPollInterval: 3600 (локально)
Type: NT5DS (Локально)NtpServer (Локально)
DllName: C:\Windows\system32\w32time.dll (Локально)
Enabled: 1 (Локально)
InputProvider: 0 (Локально)
ДоступніНаціональніModeCombinations: 1 (локально)VMICTimeProvider (Локально)
DllName: C:\Windows\System32\vmictimeprovider.dll (Локально)
Enabled: 1 (Локально)
InputProvider: 1 (локально)
Увімкнення синхронізації внутрішнього годинника із зовнішнім джерелом
Увімкнення NTP-сервера
NTP-сервер за замовчуванням увімкнено на всіх контролерах домену, однак його можна включити і на рядових серверах.
Завдання списку зовнішніх джерел для синхронізації
Прапор 0×8 на кінці означає, що синхронізація повинна відбуватися в режимі клієнта NTP через запропоновані цим сервером інтервали часу. Для того, щоб встановити свій інтервал синхронізації, необхідно використовувати прапор 0×1.
Завдання інтервалу синхронізації із зовнішнім джерелом
Час у секундах між опитуваннями джерела синхронізації, за замовчуванням 900с = 15хв. Працює лише для джерел, помічених прапором 0×1.
"SpecialPollInterval"=dword:00000384
Встановлення мінімальної позитивної та негативної корекції
Максимальна позитивна та негативна корекція часу (різниця між внутрішнім годинником та джерелом синхронізації) у секундах, при перевищенні якої синхронізація не відбувається. Рекомендую значення 0xFFFFFFFF, у якому корекція зможе виконуватися завжди.
"MaxPosPhaseCorrection"=dword:FFFFFFFF
"MaxNegPhaseCorrection"=dword:FFFFFFFF
Все необхідне одним рядком
w32tm.exe /config /manualpeerlist:"time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual / reliable:yes /update
Корисні команди
- Застосування внесених до конфігурації служби часу змін
w32tm /config /update - Примусова синхронізація від джерела
w32tm /resync /rediscover - Відображення стану синхронізації контролерів домену в домені
w32tm/monitor - Відображення поточних джерел синхронізації та їх статусу
w32tm/query/peers
Налаштування NTP сервера та клієнта груповою політикою
Якщо у нас з вами домен Active Directory, то безглуздо не використовувати групові політики, масового налаштуваннясерверів та робочих станцій, я покажу як налаштувати ваш NTP сервер у windows та клієнта. Відкриваємо оснастку "Редактор" групових політикПеред тим як налаштувати наш NTP сервер у Windows, нам необхідно створити WMI фільтр, який буде застосовувати політику, тільки до сервера майстра PDC.
Вводимо ім'я запиту, простір імен, матиме значення "root\CIMv2" та запит "Select * from Win32_ComputerSystem where DomainRole = 5". Зберігаємо його.
Потім створюєте політику на контейнері Domain Controllers.
У самому низу політики використовуєте ваш створений WMI фільтр.
Переходимо у гілку: Конфігурація комп'ютера > Політики > Адміністративні шаблони > Система > Служба часу Windows > Постачальники часу.
Тут відкриваємо політику "Налаштувати NTP-клієнт Windows". Задаємо параметри
- NtpServer: 0.ru.pool.ntp.org,0x1 1.ru.pool.ntp.org,0x1 2.ru.pool.ntp.org,0x1 3.ru.pool.ntp.org,0x1
- Тип: NTP
- CrossSiteSyncFlags: 2. Двійка означає, якщо цей параметр дорівнює 2 (Всі), можна використовувати будь-якого учасника синхронізації. Це значення ігнорується, якщо не встановлено значення NT5DS. Значення за замовчуванням: 2 (десяткове) (0x02 (шістнадцяткове))
- ResolvePeerBackoffMinutes: 15. Це значення, виражене в хвилинах, визначає інтервал очікування служби W32time перед спробою дозволу DNS-імені у разі невдачі. Значення за замовчуванням: 15 хвилин
- Resolve Peer BAckoffMaxTimes: 7. Це значення визначає кількість спроб дозволу DNS-імені, що здійснюються службою W32time перед перезапуском процесу виявлення. При кожній невдалій роздільній здатності DNS-імені інтервал очікування перед наступною спробою подвоюється. Значення за промовчанням: сім спроб.
- SpecilalPoolInterval: 3600. Це значення параметра NTP-клієнта, виражене за секунди, визначає частоту опитування налаштованого вручну джерела часу, який використовує особливий інтервал опитування. Якщо для параметра NTPServer встановлено прапорець SpecialInterval, клієнт використовує значення, задане як SpecialPollInterval, замість значень MinPollInterval та MaxPollInterval, щоб визначити частоту опитування джерела часу. Значення за замовчуванням: 3600 секунд (1 година).
- EventLogFlags: 0
Робимо окрему групову політику для клієнтських робочих машин, з такими параметрами.
- NtpServer: Адреса вашого контролера домену з участю PDC.
- Тип: NT5DS
- CrossSiteSyncFlags: 2
- ResolvePeerBackoffMinutes: 15
- Resolve Peer BAckoffMaxTimes: 7
- SpecilalPoolInterval: 3600
- EventLogFlags: 0
Мережевий протокол завдання часу NTP (Network time Protocol; Network Time Protocol Version 3 Specification, Implementation and Analysis, David L. Mills, RFC-1305, March 1992) служить реалізації синхронізації роботи різних процесів в серверах і програмах клієнта. Він визначає архітектуру, алгоритми, об'єкти та протоколи, що використовуються для зазначених цілей. NTP був вперше визначений у документі RFC-958, але з того часу кілька разів перероблений і вдосконалений (RFC-1119). Протокол використовує для транспортних цілей UDP. Метою протоколу є забезпечення максимально можливої точності та надійності, незважаючи на значний розкид затримок під час проходження через велике числопроміжних маршрутизаторів.
Протокол NTP забезпечує механізми синхронізації з точністю до наносекунд. Протокол пропонує засоби для визначення характеристик та оцінки помилок локального годинника та тимчасового сервера, який здійснює синхронізацію. Передбачені можливості роботи з ієрархічно розподіленими первинними еталонами, такими як радіо-годинник, що синхронізується.
Точність, досяжна за допомогою NTP, залежить від точності локальних годин і характерних прихованих затримок. Алгоритм корекції тимчасової шкали включає внесення затримок, корекцію частоти годин і ряд механізмів, що дозволяють досягти точності порядку декількох мілісекунд навіть після тривалих періодів, коли втрачено зв'язок з синхронізуючими джерелами.
Для наочності надаю архітектуру NTP
- Встановимо сервер часу:
Arch Linux: pacman -S ntp
Ubuntu, Debian: apt-get install ntp
- Відредагуємо файл конфігурації:
- У мене лістинг наступний:
logfile /var/log/ntp.log
driftfile /var/lib/ntp/drift
disable monitor
server 31.28.161.68 iburst
server 193.67.79.202 iburst
server 62.149.0.30 iburst
server 198.123.30.132 iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 10
restrict default ignore
restrict 127.0.0.1
- тепер трохи докладніше щодо кожного пункту:
logfile /var/log/ntp.log
Шлях куди ntp писатиме свій лог
driftfile /var/lib/ntp/drift
Шлях до дріфт-файлу
___________________________________________
disable monitor
Усунення вразливості, що дозволяє використовувати сервер синхронізації часу для проведення DDoS-атак шляхом багаторазового збільшення трафіку
___________________________________________server 31.28.161.68 iburst
Додаємо сервери, з яких буде проводиться синхронізація
Опція "iburst" рекомендується, з її допомогою надсилається шквал пакетів, якщо не вдається встановити з'єднання з сервером з першого разу. Навпаки, опцію "burst" не використовуйте ніколи без особливого дозволу, тому що Ви можете потрапити до "чорного списку".
___________________________________________
server 127.127.1.0
fudge 127.127.1.0 stratum 10
Ці два пункти призначені роботи сервера часу у разі втрати зв'язку з еталонними серверами. Параметром fudge ми визначаємо стратум для локального сервера.
___________________________________________
restrict default ignore
Забороняємо всім використовувати наш сервер часу
___________________________________________
restrict 127.0.0.1
Дозволяється використовувати наш сервер для локалхосту.
___________________________________________
restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap
Дозволяється використовувати наш сервер для мережі 10.*.
nomodify notrap - не дозволяти хосту/підмережі змінювати будь-які налаштування NTPD нашого сервера.
___________________________________________
- Зберігаємось, виходимо, наш сервер налаштований, залишилося перезапустити демон.
Arch Linux: systemctl restart ntpd
Ubuntu, Debian: service ntp restart
OpenSUSE: service ntp restart
- Чекаємо хвилин 5-10, залежно від вашої залізниці та дивимося
remote refid st t when poll reach delay offset jitter
==============================================================================
10.18.1.13 10.44.0.15 3 u 2 128 377 7.306 13.106 11.948
*10.18.0.53 198.123.30.132 2 u 62 128 377 7.156 10.279 4.308
10.18.0.52 79.53.154.33 3 u 61 128 377 7.469 1.791 4.898
127.127.1.0. LOCL. 10 l 56 64 377 0.000 0.000 0.001
- А значить наша таблиця така:
remote - імена віддалених ntp серверів;
refid - сервер, з яким здійснює синхронізацію віддалений сервер ntp (тобто ntp-сервер для remote);
st - Стратум (вага) віддаленого сервера. Чим менше значення - тим точніший час на цьому сервері;
t - тип бенкету (u = unicast, m = multicast);
when - вказує на те, як давно була проведена синхронізація із сервером;
poll - частота в секундах, з якою NTP демон синхронізується із бенкетом;
reach - Стан доступності сервера. Це значення стабілізується на рівні 377, якщо останніх 8 спроб синхронізації з віддаленим сервером були успішні;
delay - Затримка відповіді від сервера;
offset - різниця в мілісекундах між системним часом та часом віддаленого сервера; значення з мінусом - відставання, з плюсом - наш годинник поспішає;
jitter - Зміщення часу на віддаленому сервері.
Прохання також звернути увагу на спецсимволи у полі перед remote:
"*" - вказує на сервер, з яким останній раз була зроблена синхронізація;
"+" - сервер можна використовувати як сервер точного часу
"-" - Не рекомендується для використання.- Переглянути статус нашого сервера можна за допомогою:
synchronised to NTP server (10.44.0.16) at stratum 3
time correct to within 1170 ms
polling server every 64 s
- Іноді при синхронізації Windows клієнта на стороні сервера можемо спостерігати таке повідомлення:
18:09:16.326827 IP (tos 0x0, ttl 125, id 26677, offset 0, flags , proto UDP (17), length 76)
10.5.104.11.ntp > oto.ua.mti.ntp: NTPv3, length 48
симметричний активний, точний показник: годинник unsynchronized (192), Stratum 0 (unspecified), poll 10s, precision -6
Root Delay: 0.000000, Розмір dispersion: 1.015625, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3961667129.750000000 (2025/07/16 18:05:29)
Originator - Receive Timestamp: 0.000000000
Originator - Transmit Timestamp: 3961667129.750000000 (2025/07/16 18:05:29)
Це нам говорить про те, що віндовс не вірить нашому часу, занадто велике розбіжність у часі клієнта та сервера.
Максимальна позитивна та негативна корекція часу (різниця між внутрішнім годинником та джерелом синхронізації) у секундах, при перевищенні якої синхронізація не відбувається. Рекомендую значення 0xFFFFFFFF, у якому корекція зможе виконуватися завжди.
Синхронізація часу є важливим завданням, хоча не багато хто замислювався про це. Ну що поганого в часі, що втік на сервері? Чи знаєте ви, що багато проблем з годинником впливають на протоколи, пов'язані з криптографією? З цієї причини в Active Directory різниця в годинах більше 5 хвилин призводитиме до проблем автентифікації Kerberos.
Часові рівні. Strata.
Щоб зрозуміти пристрій NTP слід знати про концепцію strataабо stratum. Авторитетні джерела часу, такі як супутники GPS, цезієві атомні годинники, радіо хвилі WWVB - все це stratum 0. Вони авторитетні на тій підставі, що вони мають певний спосіб підтримки високоточного хронометражу. Можна, звичайно, скористатися звичайним кварцовим годинником, але знаючи, що за місяць з ними легко втратити 15 секунд, то краще їх не використовувати як мірила часу. Stratum 0це коли секунда не загубиться за 300 000 років!
Комп'ютери, які безпосередньо (не по мережі!) беруть час у stratum 0- це stratum 1. Оскільки завжди є затримки через передачу сигналу та витрати на встановлення часу, то комп'ютери stratum 1не такі точні як stratum 0, але в реального життяВідмінність досягає пари мікросекунд (1 мкс = 10 -6 с), що цілком допустиме відхилення.
Наступний рівень комп'ютерів, що беруть час по мережі stratum 1- це... барабанний дріб... інтрига... stratum 2! Знов-таки через різні затримки (мережні точно), stratum 2трохи відстає від stratum 1і вже точно від stratum 0. Насправді це різниця від кількох мікросекунд (1 мкс = 10 -6 з) до кількох мілісекунд (1 мс = 10 -3 з). Багато хто хоче синхронізуватися з шаром не далі stratum 2.
Як відомо зі схеми, stratum 4бере час у вищого stratum 3. stratum 5у stratum 4і так далі. stratum 16вважається найнижчим шаром і час там вважається несинхронізованим.
Щоб синхронізувати час за допомогою протоколу NTP, слід спочатку вручну виставити час. Неприпустима різниця між вашим точним часом і показаннями вашого годинника більше 1000 секунд. Якщо сервер часу бреше більше 1000 мілісекунд (1 секунда), то він буде виключений зі списку і будуть використовуватися інші замість нього. Цей механізм дозволяє відсіювати погані джерела часу.
Клієнт часу.
У файлі /etc/ntp.conf для клієнта важливі рядки Server. Їх може бути кілька – до 10 штук!
Скільки додавати? Слід мати на увазі:
- Якщо у вас тільки один сервер (один рядок server), то якщо даний сервер почне брехати, то ви сліпо слідуватимете за ним. Якщо його час втече на 5 секунд і ви втечете слідом за ним.
- Якщо додано 2 сервери (2 рядки server), то NTP помітить їх обох як false tickers. Якщо один з них буде брехати, то NTP не може зрозуміти хто бреше, тому що немає кворуму.
- Якщо додано 3 і більше сервера часу, то можна обчислити одного брехуна false tickers. Якщо серверів часу 5 або 6, то можна знайти 2 брехуни false tickers. Якщо серверів 7 чи 8, то 3 false tickers. Якщо серверів 9 та 10, то 4 false tickers.
Проект NTP Pool.
Є такий проект NTP Pool на адресу якого pool.ntp.org/zone/ru/ можна знайти рекомендовані для російських користувачів сервери часу.
server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org
server 2.ru.pool.ntp.org
server 3.ru.pool.ntp.org
Такі операційні системи, як Debian та Ubuntu, пропонують користувачам свої сервери часу.
server 0.debian.pool.ntp.org
server 1.debian.pool.ntp.org
server 2.debian.pool.ntp.org
server 3.debian.pool.ntp.org
server 0.ubuntu.pool.ntp.org
server 1.ubuntu.pool.ntp.org
server 2.ubuntu.pool.ntp.org
server 3.ubuntu.pool.ntp.org
Якщо викликати на вашому Linux комп'ютері, який використовує NTP, команду ntpq -pn
Remote refid st t when poll reach delay offset jitter ======================================== ====================================== +93.180.6.3 77.37.134.150 2 u 62 1024 377 53.658 -0.877 1.174 +85.21.78.23 193.190.230.65 2 u 1027 1024 377 54.651 0.167 1.531 *62.173.138.130 89.109.251.24 2 u 940 1024 377 52.796 -0.143 1.001 +91.206.16.3 194.190.168.1 2 u 258 1024 377 93.882 -0.680 2.196 -91.189.94.4 193.79.237.14 2 u 596 1024 377 100.219 1.562 1.482
Про що говорять назви стовпців:
- remote- Видалені сервери, з якими ви синхронізуєте час.
- refid- Вищий stratum для даного сервера.
- st- Рівень stratum. Від 0 (нам недоступно) до 16 (нам не бажано). Ідеально – 2.
- t- Тип з'єднання. " u" - unicast або manycast, " b- broadcast або multicast, " l" local reference clock, " s- симетричний вузол, A" - manycast сервер, " B" - broadcast server, " M- multicast сервер.
- when- час, коли востаннє сервер відповів нам. Параметр відображає число в секундах, але може у хвилинах, якщо число з mабо в годиннику, якщо h.
- poll- Частота опитування. Мінімум 16 секунд, максимум 32 години. Число має бути 2 n. Зазвичай у цьому параметрі спостерігається або 64 секунди або 1024.
- reach- 8-біт октету, що показує статус спілкування з віддаленим сервером часу: успішний або збійний. Якщо біти встановлені – то успішно, інакше – збій. Значення 377 – бінарно це 0000 0000 1111 1111.
- delay- значення в мілісекундах показує час між відправкою та отриманням відповіді (round trip time - RTT).
- offset- Зміщення в мілісекундах між вами та серверами часу. Може бути позитивним та негативним числом.
- jitter- Абсолютне значення в мілісекундах із зазначенням середньоквадратичного відхилення вашого усунення.
Перед IP адресою NTP сервера є символ - це tally code. Види tally code:
- " " - відкинуто як неприпустиме. Наприклад, немає зв'язку з ним або він в онлайн, він занадто високий ранг і не обслуговує таких як ви.
- "x"- відкинуто алгоритмом "перетину" (intersection algorithm). Алгоритм перетину готує список кандидатів партнерів, які можуть стати джерелами синхронізації та обчислюють довірчий інтервал для кожного з них.
- "." - відкинуто через переповнення таблиці.
- "-" - відкинуто алгоритмом кластеризації (cluster algorithm). Алгоритм кластеризації сортує список кандидатів за кодами шару та відстані синхронізації.
- "+" - Сервер включений алгоритмом "комбінування" (combine algorithm). Цей сервер - відмінний кандидат, якщо поточний сервер часу почне відмовляти вам.
- "#" - сервер є чудовим альтернативним сервером часу. Сервер з # можна побачити лише якщо у вас більше 10 записів server у /etc/ntp.conf
- "*" – поточний сервер часу. Його показання використовуються для синхронізації вашого годинника.
- "o"- сервер Pulse per second (PPS). Зазвичай це означає, що сервер часу використовує джерела часу типу GPS супутників та інші сигнали точного часу. Якщо малюється про, інші типи tally code вже відображатися не будуть.
У полі refidможуть бути такі значення:
- IP адреса - адреса віддаленого сервера часу.
- .ACST.- NTP manycast сервер.
- .ACTS.- Automated Computer Time Service з American National Institute of Standards and Technology.
- .AUTH.- помилка автентифікації.
- .AUTO.- помилка у послідовності Autokey.
- .BCST.- NTP broadcast сервер.
- .CHU.- Shortwave radio receiver від станції CHU в Ottawa, Ontario, Canada.
- .CRYPT.- помилка протоколу Autokey.
- .DCFx.- LF radio receiver від станції DCF77 в Mainflingen, Німеччина.
- .DENY.- У доступі відмовлено.
- .GAL.- European Galileo satellite receiver.
- .GOES.- American Geostationary Operational Environmental Satellite receiver.
- .GPS.- American Global Positioning System receiver.
- .HBG.- LF radio receiver від станції HBG в Prangins, Switzerland.
- .INIT.- Peer association initialized.
- .IRIG.- Inter Range Instrumentation Group time code.
- .JJY.- LF radio receiver від станції JJY в Mount Otakadoya, поряд з Fukushima або Mount Hagane на острові Kyushu, Japan.
- .LFx.- Звичайний LF radio receiver.
- .LOCL.- локальний годинник хоста.
- .LORC.- LF radio receiver від Long Range Navigation (LORAN-C).
- .MCST.- NTP multicast сервер.
- .MSF.- Anthorn Radio Station поряд з Anthorn, Cumbria.
- .NIST.- American National Institute of Standards and Technology.
- .PPS.- годинник Pulse per second.
- .PTB.- Physikalisch-Technische Bundesanstalt від Brunswick та Berlin, Germany.
- .RATE.- перевищено поріг опитування NTP.
- .STEP.- Зміна кроку NTP. Зміщення offsetменше 1000 мілісекунд, але більше 125 мілісекунд.
- .TDF.- LF radio receiver від станції TéléDiffusion de France в Allouis, France.
- .TIME.- NTP association timeout.
- .USNO.- United States Naval Observatory.
- .WWV.- HF radio receiver від станції WWV в Fort Collins, Colorado, United States.
- .WWVB.- LF radio receiver від станції WWVB в Fort Collins, Colorado, United States.
- .WWVH.- HF radio receiver від станції WWVH в Kekaha, на острові Kauai на Hawaii, United States.
По-перше, позбавтеся думки як би отримати час від stratum 1, мовляв вони ближчі за всіх до точного часу. Вони ближче до точнішого часу на планеті, тільки самі вони перевантажені і у них високі затримки RTT для звичайних серверів. Краще знайти нормальний stratum 2і не переживати із цього приводу. Не забувайте, що йдеться про мікросекунди та мілісекунди, що у звичайному житті - цілком достатньо.
По-друге, пам'ятайте, що підключення до найближчого сервера часу не завжди є ідеальним варіантом. Важливіша не територіальна близькість, а рівень stratum. Проект NTP Pool публікує список серверів лише рівня stratum 1і stratum 2і краще взяти до 10 серверів часу з цього списку, що буде просто чудово.
По-третє, якщо ви простий домашній користувач-клієнт, то рекомендовані вам сервери у вашій операційній системі будуть ідеальним варіантом, що не потребує зайвих рухів тіла.
Для великих контор, найкращим варіантомбуде підняти свій сервер часу для робочих комп'ютерів. Даний сервер отримуватиме точний час від серверів часу в Інтернеті та надаватиме його локальним комп'ютерам. На серверах Debian та Ubuntu достатньо розкоментувати рядок
Restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap
у конфігураційному файлі демона ntpd - /etc/ntp.conf
Користувачі з мережі 192.168/16 матимуть можливість брати з вашого сервера покази найточніших годин. Для внутрішніх серверів на базі Linux, які не є серверами часу та займаються своїми завданнями, замість запуску демона ntpd у клієнтському режимі - цілком достатньо вказати у файлі /etc/cron.daily/syncntpd. Рекомендується прочитати різницю між ntpdate і ntp і вирішити собі питання.
#!/bin/sh
/usr/sbin/ntpdate IP.адреса вашого сервера > /dev/null 2>&1
exit 0
і раз на добу, завдяки команді ntpdate, буде проведено синхронізацію часу. Щоб уникнути непорозумінь, не полінуйтеся перед використанням сервера часу та синхронізації всього і вся через протокол NTP - виставте вручну правильний час на всіх доступних вам серверах і робочих станціях. Якщо ваш несинхронізований час дуже відрізняється від правильного, то можна спочатку огрести багато непотрібних проблем.
По-четверте, NTP аж ніяк не пов'язаний, в якій країні та які часові пояси використовуються і як відбувається перехід на літній та зимовий час і чи робиться в цій країні такий перехід. Це обов'язок лежить на операційній системі, яку вам потрібно оновлювати, якщо в країні відбуваються зміни у справі. У системах Debian та Ubuntu за це відповідає пакет tzdata, який має бути актуальним.
По-п'яте, краще не піднімати свій NTP сервер на високонавантаженій системі.
У статті розглянемо налаштування NTP клієнта.
Встановлення часової зони
Для початку дивимося, яка у нас встановлена тимчасова зона. Для цього використовуємо команду .
# date П'ят березня 8 17:38:47 MSK 2019
Якщо тимчасову зону встановлено неправильно, то встановлюємо правильну тимчасову зону. Для цього створюємо файл /etc/localtime з відповідної часової зони з каталогу /usr/share/zoneinfo/. Наприклад, для Москви.
Ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
Налаштування синхронізації NTP-клієнта з NTP-сервером
Встановлюємо пакет ntp
Yum install ntp
Для синхронізації локальної клієнтської машини на Linux із NTP-сервером потрібно відредагувати файл /etc/ntp.conf. У прикладі вказується кілька серверів часу, що корисно у разі недоступності однієї з них. Або можете прописати інші зовнішні сервери, наприклад, pool.ntp.org
Server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst server 3.rhel.pool.ntp.org iburst
iburst: цей параметр підвищує точність синхронізації, замість одного пакета надсилається вісім. Коли сервер не відповідає, пакети надсилаються кожні 16 секунд, коли відповідає – кожні 2 секунди.
Server 192.168.1.1 prefer
prefer: якщо вказана опція, заданий сервер вважається кращим перед іншими, але якщо відповідь цього сервера значно відрізнятиметься від відповідей інших серверів, він буде ігноруватися. Замість 192.168.1.1 вкажіть ip адресу вашого сервера
Запуск служби NTP
Після зміни ntp.conf та завдання необхідних параметрів запустіть службу (демон) NTP. Залежно від налаштувань вона може працювати і як сервер, і як клієнт.
Systemctl start ntpd
і додайте його до автозавантаження
Systemctl enable ntpd
для перевірки часу наберіть команду
Перевірка стану NTP
Перевірити стан NTP можна за допомогою команди NTPQ. Якщо ви отримаєте помилку відмови в з'єднанні, сервер часу не відповідає, не запущена служба NTP на клієнті або закритий порт.
Sudo ntpq –p remote refid st t when poll reach delay offset jitter ==================================== ===================================== *elserver1 192.168.1.1 3 u 300 1024 377 1.225 -0.071 4.606
remote- Ім'я або адреса сервера часу. Перед ним вказано службовий символ, в даному випадку "*", що означає сервер, що використовується. "+" означає, що сервер придатний для оновлення, "-" - що непридатний, "x" - сервер недоступний;
refid- Вищий сервер ієрархії Stratum;
st- Рівень сервера в ієрархії Stratum;
t- тип з'єднання (u - unicast, одиночне з'єднання, b - broadcast, широкомовне з'єднання, l - локальний годинник);
when- Час, що минув з останньої відповіді;
poll- Період опитування в секундах;
reach– стан доступності (при поданні у двійковому вигляді 1 означає успішну спробу, 0 – збій. Після 8 успішних спроб встановлюється значення 377);
delay- Час подвійного обороту пакета;
offset– поточне усунення часу щодо сервера;
jitter- Середньоквадратичне відхилення часу.
Значення jitterмає бути низьким, якщо це не так, перевірте зсув щодо годинника у файлі похибки (driftfile). Якщо воно занадто велике, може знадобитися зміна сервера NTP. Наступна команда вручну синхронізує час із NTP-сервером:
Ручна синхронізація часу
Для опитування NTP-сервера та встановлення дати та часу вручну використовується команда ntpdate. Зазвичай це потрібно лише один раз.
Для початку відключіть службу ntp
Systemctl stop ntpd
Запустіть синхронізацію вказавши сервер, з якого потрібно синхронізувати час
Ntpdate 192.168.1.1
Запустіть службу ntp
Systemctl start ntpd
Після такої початкової синхронізації NTP-клієнт регулярно опитуватиме NTP-сервер для забезпечення відповідності локального часу точному часу.
Якщо ви знайшли помилку, будь ласка, виділіть фрагмент тексту та натисніть Ctrl+Enter.
Днями знову знадобилося налаштувати ntp і, як завжди, з'ясувалося, що за давністю років попереднього налаштування все забуто нафік. Тому пишемо собі нотатку на майбутнє, щоб наступного разу не шукати. Ну і моїм читачам дивишся у нагоді.
Встановлення
Платформою для установки нам послужить, як завжди, Gentoo. Служба ntp – net-misc/ntp.
Насамперед оновлюємо дерево портеджів:
Налаштування сервера.
Визначимося, у кого будемо брати час. Я пропоную використовувати сервера точного часу, Stratum 1 як ніяк.
ntp1.vniiftri.ruПараметри запуску демону ntpd визначаються у файлі /etc/conf.d/ntpd
ntp2.vniiftri.ru
ntp4.vniiftri.ru
# /etc/conf.d/ntpdТут -g -ключ дозволяє перейти на великий стрибок часу, -з -файл конфігурації служби ntp, щоб вказати pid-файл відмінний від використовуваного за замовчуванням можна використовувати ключ -p, наприклад:# Options to pass to the ntpd process
# Most people should leave this line alone ...
# however, if you know what you"re doing, feel free to tweak
NTPD_OPTS="-g -c /etc/ntp.conf"
NTPD_OPTS="-p /var/run/ntpd.pid -g -c /etc/ntp.conf"Налаштування служби ntp за замовчуванням проводиться у файлі /etc/ntp.conf, якщо вказали в попередньому пункті інший, то правимо той, який вказали
# /etc/ntp.confЗапускаємо ntpd
# Наш локальний сервер
server 192.168.0.1
Сервери в мережі
server 195.2.64.6
server ntp1.vniiftri.ru
server ntp2.vniiftri.ru
server ntp4.vniiftri.ru#Шляхи до службових файлів
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntpd.log# Дозвіл на доступ до нашого сервера
restrict default ignore # За замовчуванням доступ заборонено
restrict localhost # Локально можна все
restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap # По внутрішній мережі можна тільки читати час# Дозволяється синхронізуватися із зовнішніми серверами, інакше синхронізація не піде.
restrict 127.0.0.1
restrict 192.168.0.1
restrict 195.2.64.6
restrict ntp1.vniiftri.ru
restrict ntp2.vniiftri.ru
restrict ntp4.vniiftri.ru# Цей запис дозволяє присвоїти самому собі Stratum 3, щоб сервер довіряв сам собі
server 127.127.1.1
fudge 127.127.1.1 stratum 3
Додаємо ntpd до автозавантаження
Тепер потрібно почекати хвилин 10 – 20, оскільки синхронізація відбувається не відразу, а через деякий час.
Перевіряємо на сервері
отже, все нормально, синхронізація пішла. Докладніше розглянемо позначення отриманої таблиці.
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.0.1. INIT. 16 u - 1024 0 0.000 0.000 0.000
-ntp1.zenon.net 195.2.64.5 2 u 596 1024377 2.261 -0.104 0.680
*ntp1.vniiftri.r .PPS. 1 u 909 1024 377 4.266 -0.603 0.353
+ntp2.vniiftri.r .PPS. 1 u 562 1024 377 3.914 -0.453 0.457
+ntp4.vniiftri.r .PPS. 1 u 554 1024 377 4.487 -0.664 0.249
LOCAL(1) .LOCL. 3 l 229m 64 0 0.000 0.000 0.000
Поля таблиці:
remote- імена віддалених ntp серверів
refid- сервер, з яким синхронізує віддалений сервер ntp
st- Стратум (рівень) віддаленого сервера. 1 - найвищий, 16 - звичайна машина/клієнт.
t- тип бенкету (u = unicast, m = multicast, l = local)
when- вказує на те, як давно була проведена синхронізація із сервером
poll- частота в секундах, з якою NTP демон синхронізується із бенкетом
reach- стан доступності сервера, це значення стабілізується на рівні 377, якщо останніх 8 спроб синхронізації з віддаленим сервером були успішні
delay- затримка (у мілісекундах) відповіді від сервера
offset- різниця в мілісекундах між системним часом та часом віддаленого сервера; значення з мінусом - відставання, з плюсом - втікання
jitter- Зміщення часу на віддаленому сервері
Значки у рядках таблиці:
* - бенкет, з яким була виконана синхронізація востаннє
+ - придатний для оновлення сервер
- - непридатний для оновлення сервер
х- сервер не відповідає
Перевіряємо на клієнта:
25 Oct 17:28:04 ntpdate: adjust time server 192.168.0.1 offset -0.016567 secОднак, можна отримати таке повідомлення:
25 Oct 17:29:14 ntpdate: no server suitable for synchronization foundЩоб зрозуміти що за нісенітниця виконуємо:
Дивимося відповідь:
192.168.0.1: Server dropped: strata too highЦе означає, що рівень довіри дуже малий (stratum=16, найнижчий рівень), тобто сервер не довіряє, щоб віддавати час. Необхідно або зачекати, або змінити список серверів, із якими він синхронізується. Оскільки в конфізі у нас прописано, що наш сервер stratum 3, то таке повідомлення ми навряд чи побачимо.
server 192.168.0.1, port 123
stratum 16, precision -8, leap 11, trust 000
Налаштовуємо клієнтів.
LINUX
Клієнти у мене теж Gentoo, в основному конфігурація клієнта прописується у файлі /etc/conf.d/ntp-client. Тут не мудрий, залишаємо все як є, тільки вказуємо наш сервер у параметрах синхронізації:
# /etc/conf.d/ntp-clientДодаємо в автозавантаження:# Command to run to set the clock initially
# Most people should just leave this line alone ...
# however, if you know what you"re doing, and you
# want to use ntpd to set clock, change this to "ntpd"
NTPCLIENT_CMD="ntpdate"# Options to pass to the above command
# This default setting should work fine but you should
# change the default "pool.ntp.org" to something closer
# to your machine. See http://www.pool.ntp.org/ or
# try running `netselect -s 3 pool.ntp.org`.
NTPCLIENT_OPTS="-s -b -u 192.168.0.1 "
# rc-update add ntp-client defaultСлід мати на увазі, що служба ntp-client синхронізує час лише один раз, при запуску системи, тому для машин, які працюють тривалий час без перезапуску, робимо таке:
Створюємо в папці /etc/cron.hourly файл, що виконується з наступним вмістом
#!/bin/shВсе, тепер наша машина буде синхронізуватися з ntp щогодини.
NTPCLIENT_OPTS="-s -b -u 192.168.0.1"Ntpdate $NTPCLIENT_OPTS >> /dev/null 2>&1
WINDOWS 2003 Server
Всі рухи тіла виконуємо в командному рядку.
#w32tm /config /syncfromflags:manual /manualpeerlist:192.168.0.1Далі, у командному рядку вказуємо пріоритетний NTP сервер, перезапускаємо службу точного часу та примусово синхронізуємо час:
#w32tm /config /update
#net time /setsntp:192.168.0.1В результаті мають отримати:
#net stop w32time && net start w32time
#w32tm / resync
Команда синхронізації надіслана на локальний комп'ютер...Через деякий час можна перевірити журнал подій системи. Якщо все налаштовано та відпрацювало правильно, то в журналі буде інформаційне повідомленнявід джерела W32Time з кодом (ID) 37 та текстом "NTP-клієнт постачальника часу отримує правильні дані про час від 192.168.0.1", а потім з кодом 35 та текстом "Служба часу виконує синхронізацію системного часу з джерелом часу 192.168.0.1".
Команда виконана успішно.
UPD
WINDOWS 2012 Server
Тут все аналогічно Windows 2003 Server, але робимо все Windows PowerShellзапущеною від імені адміністратора.
Вказуємо який сервер ntp використовувати для синхронізації:
PS C:\> w32tm /config /syncfromflags:manual /manualpeerlist:192.168.0.1 /syncfromflags:MANUALДалі, у командному рядку перезапускаємо службу точного часу та примусово синхронізуємо час:
PS C:\> w32tm /config/update
PS C:\> Service-Stop w32timeВ результаті мають отримати:
PS C:\> Service-Start w32time
PS C:\> w32tm / resync
Надсилання команди синхронізації на локальний комп'ютерПеревіряємо:
Команда виконана успішно.
На виході мають отримати щось подібне:
Індикатор перешкод: 0(попереджень немає)Роутери
Втрата: 3 (вторинне посилання - синхронізована за допомогою (S)NTP)
Точність: -6 (15.625ms за такт часу)
Затримка кореня: 0.0356903
Дисперсія кореня: 7.8069513s
Ідентифікатор опорного часу: 0xC0A86301 (IP-адреса джерела: 192.168.0.1)
Час останньої успішної синхронізації: 22.03.2016 16:21:25
