Переключение синхронизации времени с systemd на ntp

При необходимости отказа от синхронизации с серверами времени через systemd выполните в терминале команды (даются в одну строку, чтобы выполнялись пакетным образом).

sudo apt install -y ntp && sudo systemctl restart ntp

В процессе выполнения указанной выше составной команды пакет systemd-timesyncd удаляется автоматически.

Проверить автоматический запуск службы ntp можно командой

  systemctl is-enabled ntp  

Ответ enabled является положительным. 

Указания серверов времени для синхронизации задаются в файле  /etc/ntp.conf  

В Linux Mint по умолчанию указаны следующие:

pool 0.ubuntu.pool.ntp.org iburst

pool 1.ubuntu.pool.ntp.org iburst

pool 2.ubuntu.pool.ntp.org iburst

pool 3.ubuntu.pool.ntp.org iburst

# Use Ubuntu's ntp server as a fallback.

pool ntp.ubuntu.com

Первые 4 строки указывают на пул серверов времени ubuntu.pool.ntp.org. При невозможности синхронизировать время ни с одним из указанных адресов синхронизация будет осуществлена с пулом серверов pool ntp.ubuntu.com

Эти значения можно изменить, указав предпочитаемые вами пулы адресов или конкретные серверы времени. Вы можете воспользоваться информацией с этого ресурса.

 

Бывает, что провайдер Интернет (как в моём случае) автоматически перенаправляет запросы с пулу ubuntu.pool.ntp.org на региональные серверы точного времени. В таком случае производить изменения в файле  /etc/ntp.conf  нет необходимости. Сведения об этом можно получить по запросу в терминале

  ntpq -p , например:

В пользу того, что провайдер перенаправляет запросы к пулу ubuntu.pool.ntp.org на региональные серверы точного времени говорят малые значения в столбце delay (время ответа). Либо информацию об этом можно получить по наименованию серверов времени в столбце remote.

Пояснения по приведенному выше рисунку:

remote – имя удаленного NTP-сервера. Если дать запрос ntpq -p -n , то вместо имён серверов будут отображены их IP-адреса.

refid – указывает, откуда каждый сервер получает время в данный момент. Это может быть имя хоста или что-то вроде .GPS., указывающее на источник глобальной системы позиционирования (Global Positioning System).

st – Stratum (уровень) это число от 1 до 16, указывающее на точность сервера. Единица означает максимальную точность, 16 означает, что сервер недоступен. 

poll – интервал между опросами (в секундах). Значение будет изменяться между минимальной и максимальной частотой опросов. В начале интервал будет маленьким, чтобы синхронизация происходила быстро. После того как часы синхронизируются, интервал начинает увеличиваться, чтобы уменьшить трафик и нагрузку на популярные сервера времени.

reach – восьмеричное представление массива из 8 бит, отражающего результаты последних восьми попыток соединения с сервером. Бит выставлен, если удаленный сервер ответил.

delay – количество времени (в секундах) необходимого для получения ответа на запрос "который час? ".

offset – наиболее важное поле. Разница между временем локального и удаленного серверов. В ходе синхронизации это значение должно понижаться (приближаться к нулю), указывая на то, что часы локальной машины идут все точнее.

jitter – дисперсия, то есть мера статистических отклонений от значения смещения (поле offset) по нескольким успешным парам запрос-ответ. Меньшее значение дисперсии предпочтительнее, поскольку позволяет точнее синхронизировать время.

Значение знаков перед именами серверов:

x – фальшивый источник по алгоритму пересечения;

. – исключён из списка кандидатов из-за большого расстояния;

- – удалено из списка кандидатов алгоритмом кластеризации;

+ – входит в конечный список кандидатов;

# – выбран для синхронизации, но есть 6 лучших кандидатов;

* – выбран для синхронизации;

o – выбран для синхронизации, но используется PPS;

пробел – слишком большой уровень, цикл или явная ошибка.

Служба ntpd сама отсеивает источники времени слишком выбивающиеся "за рамки разумного". Через некоторое время после запуска ntpd выберет наиболее достоверные источники данных и будет синхронизироваться с ними. Список эталонных NTP серверов регулярно пересматривается службой. Например, по этой ссылке указаны сведения по непонятному узлу hbars.site (см. рисунок).

Своего рода платой за переход синхронизации времени c systemd на ntp будет являться некоторый рост (до нескольких секунд) времени загрузки вашей системы. Лично у меня он составил порядка 3 секунд. Увидеть конкретное значение можно при выводе результата запроса в терминале

  systemd-analyze blame  (смотрите строку, содержащую ntp).

В связи с этим возникает вопрос: а зачем может возникнуть необходимость переключения с systemd-timesync на ntp?

Как указано в комментариях 31 и 33 на unix.stackexchange.com, далее – цитирование:

Systemd-timesyncd – это клиент SNTP, который менее точен, чем NTP. Читатели не должны вводить себя в заблуждение, думая, что systemd-timesyncd – это легковесный NTP-клиент.

systemd-timesyncd не дисциплинирует часы: часы не обучаются и не компенсируются, а внутренний дрейф часов с течением времени не уменьшается. У него есть рудиментарная логика для настройки интервала опроса, но без дисциплинирования хост навсегда останется с неравномерным временем, поскольку systemd-timesyncd подталкивает или тянет с любым интервалом, который, по его мнению, требуется для краткосрочного дрейфа. Он также не может оценить качество удаленного источника времени. Вы вряд ли получите точность намного выше 100 мс. Этого достаточно для простых устройств конечного пользователя, таких как ноутбуки, но это определенно может вызвать проблемы для распределенных систем, которым нужна более высокая точность времени.

Соответственно, если в Cinnamon вы делали лаунчер (кнопку запуска) для проверки состояния синхронизации времени (подробности), то строку

Exec=sh -c 'timedatectl timesync-status | cat - /dev/tty'

необходимо изменить на

Exec=sh -c 'ntpq -p | cat - /dev/tty'

✔   Примечание. При создании лаунчера необходимо отметить, чтобы он запускался в терминале.

Если вы это не сделали, то откройте свой лаунчер, расположенный по пути
/home/ваш_домашний_каталог/local/applications

в текстовом редакторе и внесите в него строку Terminal=true

Если нужно, чтобы у вас отобразилось окно терминала на определённое количество секунд, например, 25, то сделайте следующее:

1) создайте исполняемый файл timesync.sh с содержанием:

#!/bin/bash
sh -c 'ntpq -p | cat - /dev/tty' &
sleep 25
exit

2) в созданном лаунчере (см. выше) измените

Exec=sh -c 'timedatectl timesync-status | cat - /dev/tty'

на Exec=полный_путь_к_timesync.sh

Перенаправление запросов времени на локальный сервер времени MikroTik

Данный материал является дополнением к публикации на тему установки сервера времени MikroTik для локальной сети.

Возобновление интереса к серверу времени MikroTik было обусловлено возникшим интересом к процессу синхронизации времени на системах Ubuntu и Linux Mint, функционирующих в рамках домашней сети.

Проверка работы служб синхронизации времени (клиентов NTP) производилась командой ntpq -p, после выполнения которой в окне терминала выводится ответ, например :

Строго говоря, там имеется несколько столбцов. Их интерпретация:

remote – адрес сервера времени, с которым синхронизируется компьютер;
refid – вышестоящий сервер (от которого узел remote получает время);
st – уровень сервера (stratum);
t – пир (unicast или multicast);
when – когда последний раз сверялось время;
poll – периодичность синхронизации с этим сервером;
reach – состояние работоспособности. Если удалось произвести синхронизации восемь раз в подряд становится равным 377;
delay – время задержки;
offset – разница между нашим временем и временем на сервере; положительное – наши часы спешат, отрицательное – отстают;
jitter – смещение времени на удаленном сервере;

Значки в начале строк:

* – с этим источником клиент ntp произвёл последнюю синхронизацию времени;
+ – источник является кандидатом при очередных выборах сервера для синхронизации времени клиентом ntp;
– – источник не рекомендован для синхронизации времени;
x – источник не доступен.

Как следует из результата вывода, запросы на серверы из пула ntp.ubuntu.com, которые перечислены в файле /etc/ntp.conf, перенаправляются на ресурсы регионального географического пула серверов ntp (строки в столбце refid). При этом клиент службы ntp по своему алгоритму периодически опрашивает пул серверов ntp с целью выбора наилучшего для синхронизации времени, вследствие чего значение в строке * может изменяться в зависимости от времени запроса ntpq -p

На MikroTik устанавливается и настраивается сервер, обслуживающий ЛВС:

Значение строки Broadcast Addresses указывает на широковещательный адрес ЛВС.

Далее создаётся правило, которое все запросы к серверу времени от узлов локальной сети будет перенаправлять на сервер времени MikroTik:

Через некоторое время можно наблюдать, работает ли созданная схема по счётчику в IP/Firewall или наглядно в графическом виде:

После запросов, осуществлённых на системе Linux Mint 18x (в частности, Linux Mint 18.3) с некоторым интервалом можно видеть результаты вывода команды ntpq -p :

Видно, что если при первом запросе клиент ntp показывает, что все серверы пула ntp.ubuntu.com получают время от вышестоящего сервера точного времени 62.149.0.30, то уже при втором запросе появляется новый вышестоящий сервер точного времени 31.28.161.71

62.149.0.30 и 31.28.161.71 являются источниками точного времени для клиента ntp MikroTik:

Периодически из этих серверов выбирается лучший. Подробности здесь.

С течением времени клиент ntp MikroTik может посчитать, что источник времени 31.28.161.71 более предпочтителен:

А сервер времени MikroTik скорректированное по указанным выше источникам точного времени выдаёт его клиентам локальной сети. Результаты вывода команды ntpq -p как раз и подтверждают факт того, что в качестве пула серверов времени выступает именно сервер времени MikroTik. Тем более, что это также будет подтверждаться значением времени задержки ответа от сервера точного времени, передаваемому клиенту, которое отображается с столбце delay (см. пояснение выше):

При отсутствии на MikroTik сервера ntp задержка ответа (от регионального пула серверов ntp) составляет порядка 2,3-2,5  Приводимые значения столбца delay соответствуют времени отклика от самого MikroTik (на рисунке ниже он соответствует узлу сети router.vot):

Полный ответ с отображением всех столбцов приводится ниже:

Интересно отметить, что на момент запроса на рис. выше провайдер или не осуществлял свой редирект на региональный пул серверов ntp или в это время производились какие-то их "выборы". Звёздочка (расшифровку см. выше) указывает на узел chilipepper.can... , который является одним из узлов пула ntp.ubuntu.com (Cannonical). Однако со временем ситуация "возвращается на круги своя".

Указанные клиенту SNTP MikroTik Primary NTP Server и Secondary NTP Server являются серверами точного времени ntp.time.in.ua и ntp2.time.in.ua, которые, в отличие от пула серверов ntp, имеют постоянные (статические) адреса IP. Именно по этой причине они и были выбраны в качестве источников точного времени для клиента SNTP MikroTik. Как указано на сайте time.in.ua, сервер времени является официальным и активным участником проекта pool.ntp.org

Аналогичными источниками точного времени c постоянными адресами IP являются также серверы времени colocall: ntp1.colocall.net и ntp2.colocall.net, имеющие адреса 62.149.2.62 и 62.149.2.126 соответственно.

Ради интересами были также сделаны запросу к серверу точного времени https://net.dn.ua/time/ , который наглядно показывает смещение часов компьютера. Полученные результаты можно считать более чем удовлетворительными:

Следует отметить, что по сравнению с эталонным источником время на компьютере будет постоянно "дрожать" (так называемый дрифт), поэтому смещение даже в 0,05 сек для домашнего компьютера можно считать хорошим показателем.

При запросе на Linux Mint 19x (в частности, Linux Mint 19.2) появились отличия. Вероятно, это связано с тем, что в Ubuntu 18x / Linux Mint 19x служба времени стала постепенно переводиться под управление systemd.

Из рисунка видно, что служба времени сверяет часы системы только с двумя серверами точного времени, которые получила от сервера dhcp. Данные серверы перечислены в файле /run/ntp.conf.dhcp

Всё верно. В приводимом примере настройки MikroTik сервер DHCP выдаёт адреса двух серверов точного времени:

А поскольку на MikroTik производится "перенаправление" запросов времени, то в приведенном выше рисунке значения столбца refid соответствуют наилучшему на момент запроса вышестоящему серверу ntp2.time.in.ua клиента SNTP MikroTik.

Клиент SNTP в MikroTik

  Начиная с версии прошивки 6.27 в MikroTik имеется соединение с облаком Cloud (IP – Cloud), позволяющем синхронизировать время на MikroTik, который не имеет энергонезависимого источника питания.

Детальных сведений в сети на русском языке о синхронизации времени через Cloud мне найти не удалось. Единственная найденная мной информация на Wiki MikroTik указывает, что:

а) точность устанавливаемого времени при выключенном клиенте NTP может составить несколько секунд: approximate time (accuracy of several seconds, depends on UDP packet latency, useful when NTP is not available);

б) опросы производятся каждые 60 секунд, а ожидание ответа от Cloud составляет 15 секунд: Router checks for outgoing IP address change: every 60 seconds
Router waits for cloud server response: 15 seconds

в) при включённом режиме Cloud зашифрованные пакеты upd передаются на порт 15252 узла cloud.mikrotik.com: UPD When enabled '/ip cloud' will send encrypted packets to hosts UDP/15252 port that resolves from cloud.mikrotik.com

Если на MikroTik нужен сервер NTP, синхронизация времени в Cloud отключена (галочка в поле "Update Time" отсутствует), а клиент DHCP не настроен или не получает адресов серверов NTP от провайдера (Use Peer NTP),

то имеется необходимость настройки клиента NTP (SNTP Client).

Когда клиент DHCP получает адреса DNS и NTP серверов от вышестоящего MikroTik, то ничего делать не надо, достаточно включить SMTP Client.

Встроенный в MikroTik клиент SNTPклиент получает синхронизацию от серверов времени NTP. При его активизации (System – SNTP Client) вводятся адреса IP основного и дополнительного серверов точного времени NTP, например:

Если вместо адреса IP водить имена конкретных серверов, то клиент распознает их адреса IP и автоматически подставит необходимые значения.

В процессе работы клиент опрашивает основной и дополнительный серверы, выбирает из них наилучший и синхронизирует с ним своё время. После успешной синхронизации времени повторный цикл "опрос – выборы – синхронизация" проводится через 64 секунды, затем интервал между циклами возрастает (128, 256, 300 секунд), пока не достигнет значения в 900 секунд.

Клиент SNTP MiroTik имеет недостаток. Дело в том, что адреса IP серверов точного времени могут меняться. В частности, в течение суток при пингах сервера времени timeserver.ru были возвращены значения 185.22.183.74 и 185.22.183.73  Клиент же SNTP MikroTik такие изменения не отслеживает, продолжая использовать предыдущий адрес IP. Поэтому может возникнуть ситуация, при которой синхронизация времени произведена не будет и в поле (см. рис. выше) Last Bad Packet From будет указан IP сервера NTP, с которым ему синхронизироваться не удалось.

Можно, конечно, периодически пингом опрашивать доступность введённых IP серверов NTP и при изменении их IP вносить новые адреса, а можно доверить решение данного вопроса скрипту автоматической коррекции адресов серверов IP.

Сам скрипт заимствован с одного из комментариев то ли к публикации на сайте, то ли одного из форумов (сейчас уже и не вспомню). Надеюсь, что автор комментария не станет мне выставлять претензию на "нарушение его авторских прав", тем более что, по его же словам, текст скрипта "//честно стибрен с официальной вики".

Текст скрипта следующий:

# Change the following line as needed as progName should match script name
:local progName "SetNtpServers";

# Array of NTP pools to use (check www.pool.ntp.org) one or a maximum of two, a primary & secondary
# Modify the following line and array variable based on your locale (default is north america).
:local arrNtpSystems ("0.us.pool.ntp.org", "1.us.pool.ntp.org");
# Alternatively the US related pool below can be used.
#:local arrNtpSystems ("0.us.pool.ntp.org", "1.us.pool.ntp.org");
#
# No modification is necessary beyond this line.
:put "$progName: Running...";
:log info "$progName: Running...";
:set arrNtpSystems [ :toarray $arrNtpSystems ];
:if (( [ :len $arrNtpSystems ] < 1 ) or ( [ :len $arrNtpSystems ] > 2 )) do={
:put "$progName: ERROR NTP Systems array (\$arrNtpSystems) must be either one or two DNS names.";
:log info "$progName: ERROR NTP Systems array (\$arrNtpSystems) must be either one or two DNS names.";
} else={
:local arrRosNtpSetting ("primary-ntp", "secondary-ntp");
:local i 0;
:foreach strNtpSystem in ($arrNtpSystems) do={
:local ipAddrNtpSystem [ :resolve $strNtpSystem ];
:local strRosNtpSetting [ :pick $arrRosNtpSetting $i ];
:local strCurrentNtpIp [ /system ntp client get $strRosNtpSetting ];
:put "$progName: NTP server DNS name $strNtpSystem resolves to $ipAddrNtpSystem.";
:log info "$progName: NTP server DNS name $strNtpSystem resolves to $ipAddrNtpSystem.";
:put "$progName: Current $strRosNtpSetting setting is $strCurrentNtpIp.";
:log info "$progName: Current $strRosNtpSetting setting is $strCurrentNtpIp.";
:if ( [ :toip $ipAddrNtpSystem ] != [ :toip $strCurrentNtpIp ] ) do={
:put "$progName: Changing $strRosNtpSetting setting to $ipAddrNtpSystem.";
:log info "$progName: Changing $strRosNtpSetting setting to $ipAddrNtpSystem.";
:local strCommand [ :parse "/system ntp client set $strRosNtpSetting=\"$ipAddrNtpSystem\"" ];
$strCommand;
} else={
:put "$progName: No changes were made for the $strRosNtpSetting NTP setting.";
:log info "$progName: No changes were made for the $strRosNtpSetting NTP setting.";
}
:set i ($i + 1);
}
}
:put "$progName: Done.";
:log info "$progName: Done.";

Обратите внимание на строку

       :local arrNtpSystems ("0.us.pool.ntp.org", "1.us.pool.ntp.org");

В ней указаны серверы NTP. Вы можете указать свои серверы NTP или пулы серверов NTP.

Какие адреса серверов NTP использовать? Можно их поискать. Например, при просмотре результатов русскоязычного поиска меня заинтересовал ntp.time.in.ua (подробности), в описании которого указано, что он имеет 1-й уровень точности. А сервер в Донецке уровня stratum2 на своей странице даже покажет смещение часов компьютера.

Можете указать целые пулы серверов NTP, для чего кликните на регион и на странице найдите страну своего пребывания:

Например, для Российской Федерации найдены записи:

0.ru.pool.ntp.org
1.ru.pool.ntp.org
2.ru.pool.ntp.org
3.ru.pool.ntp.org

Результирующий текст скрипта (без воды в виде комментариев) будет следующим (пример):

:local progName "SetNtpServers";
:local arrNtpSystems ("0.ru.pool.ntp.org", "1.ru.pool.ntp.org");
:put "$progName: Running...";
:log info "$progName: Running...";
:set arrNtpSystems [ :toarray $arrNtpSystems ];
:if (( [ :len $arrNtpSystems ] < 1 ) or ( [ :len $arrNtpSystems ] > 2 )) do={
:put "$progName: ERROR NTP Systems array (\$arrNtpSystems) must be either one or two DNS names.";
:log info "$progName: ERROR NTP Systems array (\$arrNtpSystems) must be either one or two DNS names.";
} else={
:local arrRosNtpSetting ("primary-ntp", "secondary-ntp");
:local i 0;
:foreach strNtpSystem in ($arrNtpSystems) do={
:local ipAddrNtpSystem [ :resolve $strNtpSystem ];
:local strRosNtpSetting [ :pick $arrRosNtpSetting $i ];
:local strCurrentNtpIp [ /system ntp client get $strRosNtpSetting ];
:put "$progName: NTP server DNS name $strNtpSystem resolves to $ipAddrNtpSystem.";
:log info "$progName: NTP server DNS name $strNtpSystem resolves to $ipAddrNtpSystem.";
:put "$progName: Current $strRosNtpSetting setting is $strCurrentNtpIp.";
:log info "$progName: Current $strRosNtpSetting setting is $strCurrentNtpIp.";
:if ( [ :toip $ipAddrNtpSystem ] != [ :toip $strCurrentNtpIp ] ) do={
:put "$progName: Changing $strRosNtpSetting setting to $ipAddrNtpSystem.";
:log info "$progName: Changing $strRosNtpSetting setting to $ipAddrNtpSystem.";
:local strCommand [ :parse "/system ntp client set $strRosNtpSetting=\"$ipAddrNtpSystem\"" ];
$strCommand;
} else={
:put "$progName: No changes were made for the $strRosNtpSetting NTP setting.";
:log info "$progName: No changes were made for the $strRosNtpSetting NTP setting.";
}
:set i ($i + 1);
}
}
:put "$progName: Done.";
:log info "$progName: Done.";

При указании серверов точного времени рекомендуют использовать региональные пулы адресов серверов NTP. Хотя причина данной рекомендации больше обусловлена тем, что региональные серверы NTP просто географически ближе. А так разницы нет. Главное, чтобы какой-нибудь сервер NTP "не банил" Ваш IP.  Меня, например, смутила такая запись на странице https://ntp-servers.net/servers.html:

"При использовании наших NTP серверов, старайтесь не отправлять слишком много запросов за короткий промежуток времени, в противном случае ваш IP адрес может быть заблокирован на срок не менее 30 суток с момента начала блокировки."

Как понимать высказывание "слишком много запросов"? Запросы с моего MikroTik с интервалами 64, 128, 256 c. (см. пояснение выше) это "слишком много" или нормально?

При вводе имён серверов точного времени необходимо вводить так, как они указаны. Например:

:local arrNtpSystems ("ntp.time.in.ua", "ntp2.time.in.ua");

то есть без 0. и 1. перед их именами. В противном случае при запуске скрипта получите его бесконечное выполнение, связанное с невозможностью распознавания их адресов IP.

Создайте скрипт (System – Scripts)

укажите ему имя (в приводимом примере timeservers), а в поле Source вставьте текст скрипта.

Далее вызовите планировщик заданий "System – Sheduler", в котором определите с какого времени и с какой периодичностью производить запуск скрипта timeservers (или определённого Вами наименования скрипта):

В поле On Event впишите  /system script run имя_вашего_скрпта

Периодичность (Interval) установите такую, которую считает нужной. В приводимом примере она указана как 1d:00:00:00, то есть каждые 24 часа (раз в сутки). Если это нужно делать, например, каждые 4 часа, то укажите 00:04:00:00  То есть, формат представления состоит из 4 групп цифр – дней:часов:минут:секунд

После отработки скрипта в протоколе работы MikroTik (Log) должны появиться записи, касающиеся результатов выполнения созданного скрипта:

Если будут присутствовать строки "No changes made for the primary-ntp NTP settings" и "No changes made for the secondary-ntp NTP settings", то это означает, что адреса IP при их очередном распознавании не изменились и никаких изменений в IP адреса серверов точного времени клиента SNTP MikroTik внесено не было.

А в разделе System – SNTP Client можно посмотреть результат последней синхронизации времени. На рисунке ниже видно, что состоялись "выборы" и с наилучшим сервером произведена синхронизация часов MikroTik, в ходе которой осуществлена коррекция на 779 микросекунд.

Обратите внимание, что при добавлении сервера NTP такой подробной картинки в клиенте SNTP Вы наблюдать не будете. Вместо SNTP Client у Вас будет отображаться NTP Client c уведомлением о том, что время синхронизировано (synchronized).

Может возникнуть вопрос: зачем а настройках SNTP Client указано значение 192.168.224.81 в поле Server DNS Names, которое в приводимом примере соответствует адресу сервера DNS MikroTik в локальной сети.

Если Вами используется Peer DNS Names, то это поле можно и не заполнять. Но если Вы не используете имени серверов, предоставляемых провайдером, предпочитая для распознавания имён использовать другие DNS интернета, а в статических адресах DNS сервера MikroTik такие значения как time.windows.com, ntp.ubuntu.com, time.google.com указывают на определённые адреса IP, не совпадающие с их действительными значениями (например, ближайшим сервером NTP), то есть вероятность получить невозможность синхронизации времени клиентским компьютером (server-ip-mismatch).

Второй причиной ввода значений в поля Server DNS Names является ситуация, при которой сервер DNS MikroTik не используется, поэтому для распознавания имён серверов точного времени требуется указание адресов серверов DNS, используемых для преобразования имён серверов NTP в адреса IP. Это отражено в Wiki MiroTik.

В протоколе MikroTik работа скрипта помечена записями SetNtpServers. Чтобы установить своё наименование измените его в самой первой строчке скрипта:

       :local progName "SetNtpServers";

Альтернативная синхронизация времени в Windows

На домашнем компьютере возникла проблема, когда при после установки системы время на компьютере не синхронизировалось через Интернет. На запрос о принудительной синхронизации имела место ошибка:

Можно было бы, конечно, вручную подкорректировать время, но из природной ленности хотелось, чтобы эту работу выполнила сама операционная система. Ситуация патовая, прямо как в анекдоте:

Сижу, жду синхронизации времени, а оно всё не синхронизируется и не синхронизируется ...

Но нашлись люди, нашлись ...
При ... приютили, подогрели, обобрали.
М-м-м ... Под ... Подобрали, обогрели ...

(из к/ф "Ирония судьбы или с лёгким паром", СССР)

Вот и в моём случае нашлось решение вопроса, представляющее собой клиент SP TimeSync. SP TimeSync представляет собой программу с многоязычным интерфейсом, предназначенную для синхронизации часов компьютера с любыми атомными часами (серверами точного времени) в Интернет. Для этих целей используется высокоточный сетевой протокол времени (NTP), который позволяет достичь точности синхронизации до нескольких миллисекунд в зависимости от характеристик источника времени и задержек распространения сигнала по сети.

На официальном сайте программы в разделе загрузок имеются 32-битная и 64-битная версии. В настройках программы имеется возможность указания источника точного времени для синхронизации, возможности автостарта при загрузке системы, указания порта, а также периодичности синхронизации в секундах, минутах, часах и днях.

После установки при команде "Получить время" синхронизация прошла на "ура":

При указании в настройках (см. выше) "Запускать со свёрнутым окном" программа запускается в виде на рисунке ниже. Для активации окна просто щёлкните по ней.

Желающие могут установить себе собственный бесплатный сервер NTP, с которым будут синхронизировать своё время другие компьютеры сети. Страничка на русском языке находится здесь, а сайт разработчика расположен здесь.

Сервер NTP (сервер точного времени) для ЛВС на MikroTik

Содержание заметки:

– настройка NTP на MikroTik;
– настройка периода синхронизации времени в Windows.

После повышения своей квалификации (или добавления извилины, так как осталась только одна извилина, и то – след от фуражки) посетила меня параноидальная идея создания в рабочей ЛВС узла точного времени, так как в наше время без знания точного времени жить, как говорят, "не комильфо" (происходит от франц. comme il faut "как надо, как следует"). Кроме того, это нужно было для поддержания мании собственного величия   

Итак, для решения вопроса необходим клиент NTP, который будет получать точное время от узлов Интернет, и сервер NTP, который будет раздавать это время компьютерам в сети. Если на оборудовании MikroTik 1100AH2 необходимые компоненты уже присутствуют, то в панели управления MikroTik RB951 и MikroTik RB2011 таких компонентов системы не оказалось. Следовательно, их необходимо добавить.

Обращаемся на узел загрузок ПО MikroTik RouterOS и в разделе "Download MikroTik software products" находим необходимое нам ПО. Так как ниже рассматривается RB951 и RB2011, то подходит самая первая секция из перечисленных:

Заходим. Качаем Extra packages:

В составе архива и будет присутствовать необходимый компонент ntp-6.29.1-mipsbe.npk. 6-29-1 означает версию программного продукта и на момент написания этой заметки версия 6.29.1 была самой свежей.

Теперь берём этот интересующий нас компонент npk и бросаем на сам MiktoTik:

Чтобы система "поняла", что ей необходимо добавить компонент(ы), перезагрузите MikroTik. После перезагрузки в меню System появятся вкладки клиента и сервера NTP:

Клиент NTP требует только ввести адреса серверов точного времени. При этом MiktoTik сам понял, какие IP необходимо поставить, так как я вводил адреса серверов точного времени ближайших ко мне.  У Вас они будут свои.

Примечание.  При настройке клиента NTP на пулы адресов серверов точного времени может потребоваться периодическая коррекция их адресов IP. В этом вопросе может помочь скрипт, запускаемый расписанию. Читайте об этом в публикации Клиент SNTP в MikroTik.

После галочки в поле "Enabled" клиент работает и получает точное время. Теперь очередь за сервером NTP.

Так как решено было не трогать настройку компьютера в целях изменения источника для точного времени, то в сервер DNS MiroTik была внесена статическая запись time.widows.com (IP – DNS – Static).

Как альтернативный вариант можно использовать псевдоним доменного имени узла time.windows.com, который будет указывать на сервер NTP (пример):

Теперь включается сервер NTP. В руководствах написано, что делать нужно так:

Пояснения по Broadcast, Multicast, Manycast

Broadcast mode. Клиенты NTP "слушают" широковещательные сообщения, рассылаемые сервером NTP. После получения первого широковещательного сообщения клиент синхронизирует часы локального узла с использованием режима unicast mode. После этого клиент NTP переходит в режим ожидания прихода следующего широковещательного сообщения. Широковещательные сообщения NTP отправляются на широковещательный адрес сети каждые 64 секунды.

В режиме unicast mode клиент NTP client соединяется с указанный сервером NTP. В настройках клиента NTP адрес IP сервера NTP должен быть определён как адрес первого или второго сервера NTP. Клиент синхронизирует своё время с сервером NTP. Далее каждые 64–1024 секунды клиент запрашивает время с сервера NTP. Режим unicast mode является единственным, который использует параметры настроек "первый" и "второй" серверы NTP.

Multicast mode работает аналогично режиму broadcast mode. При этом вместо широковещательных сообщений на адрес, например, 255.255.255.255 сообщения multicast принимаются с адреса 224.0.1.1. То есть, для доставки пакетов используются multicast-адреса сетей класса D адресного пространства IP-адресов. Для клиентов и серверов задается адрес multicast-группы, которую они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Manycast mode функционирует как режим unicast mode только с неизвестными адресами IP серверов NTP. Для обнаружения сервера NTP клиент отправляет сообщение multicast на адрес, например, IP 239.192.1.1. Другими словами, используются адреса multicast-групп (сети класса D). Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых multicast-адресов.
Если сервер NTP настроен на то, чтобы "слушать" эти сообщения multicast (стоит галочка в поле Manycast), то он "отвечает" на такие сообщения.
После получения клиентом ответа клиень переходит в режим unicast mode и синхронизируется с ответившим ему сервером NTP. Одновременно с этим клиент продолжает поиск большего (ударение на букву о) числа серверов NTP, периодически отправляя сообщения multicast каждые 64 секунды.
Этот режим является нововведением 4-й версии протокола NTP. В manycast mode подразумевается поиск клиентом среди своих сетевых соседей manycast-серверов, получение от каждого из них образцов времени (с использованием криптографии) и на основании этих данных выбирается 3 «лучших» manycast-сервера, с которыми клиент будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.


В настройках сетевого экрана, может быть, придётся разрешить (Action = Accept) получение пакетов NTP по протоколу UDP с порта источника 123:

Для сетевых экранов ОС Windows рекомендуют открывать на входящие и исходящие соединения по порту 123 UDP "от" и "на", хотя может и являться "перестраховкой".

Чтобы не лезть в настройки каждого компьютера с целью изменения источника точного времени (для Windows) можно внести в DNS соответствующую запись. Обусловлено это тем, что time.windows.com является высоконагруженным узлом, что может привести к периодическим отказам синхронизации времени на компьютерах под управлением Windows.

Такое действие будет оправдано, если пользователи клиентских компьютеров не будут предпринимать действия по изменению адресов серверов DNS в настройках своих сетевых соединений. Для исключения такой возможности произведите настройку принудительного перенаправления запросов DNS на сервер DNS MikroTik – подробности.

При первом запуске обновления времени Вы можете получить сообщение о том, что операция успешно не завершена вследствие превышения времени ожидания. Однако при повторных попытках время на компьютере синхронизировалось.

Если вдруг всё равно высвечивается ошибка,

то можно предпринять некоторые шаги, которые не соответствуют инструкции производителя и касаются перевода работы сервера NTP в режим Broadcast Mode. Однако это можно делать лишь в том случае, если MikroTik и клиентские компьютеры расположены в пределах адресного пространства одной сети, в которой доступны широковещательные пакеты.

В одной из публикаций написано, что автор указывал все галочки, как он говорит, "не парясь". Но это будет не совсем правильным действием, к тому же может и не привести к ожидаемому результату:

Лирическое отступление с долей иронии

Сразу стали посещать "умные" мысли о перенаправлении запросов на самом MikroTik или добавлении правил в брандмауэр компьютера ... Пока не вспомнил, как частенько отвечал на "умные" вопросы по сотовому телефону:
– Привет, а ты где?
Заметьте, главное, что его интересует: где я. Начинаю предполагать, что знание моих значений на сетке координат определяет: следует ли далее продолжить беседу или уже пора нажать на кнопку завершения вызова. А если я ушёл в нирвану?
– Я тут.
– А тут это где?
– А тут – это не там.
– А там это где?
– А там – это не здесь.
– А здесь – это где?
– А здесь Вам не тут ... (из армейских афоризмов)
– ??? (собеседник задумался, даже стала слышна работа мысли ...)

Аналогичная ситуация: на вопрос "ты где?" сервер NTP ответить затрудняется. Что ж, надо помочь. Укажите для своей сети широковещательный адрес, например:

  Пояснение.  В приведенном выше примере указана сеть с маской 24, т.е. 255.255.255.0

Если Ваши сети сегментированы, то для других масок у Вас будут другие значения, например,

/25 – 127 (255.255.255.128)

/26 – 63 (255.255.255.192)

/27 – 31 (255.255.255.224)

/28 – 15 (255.255.255.240)

/29 – 7 (255.255.255.248)

или в большую сторону

/23 – 511 (255.255.254.0)

/22 – 1023 (255.255.252.0)

Время стало синхронизироваться:

Отлично! Но для чистоты эксперимента перепроверим на следующий день:

Можно также сделать перенаправление запросов от узлов ЛВС на сервер NTP MikroTik.

Заключительные замечания касаются периодичности обращения системы Windows к серверу точного времени. Как умолчанию, этот промежуток времени составляет 7 дней. Но его можно изменить. Нажимаем клавиши Windows + R и в появившемся окне запуска пишем regedit (запуск редактора реестра). Альтернативный вариант: "Пуск – Все программы – Стандартные – Выполнить".

Перейдите в ветку HCLM\SYSTEM\:CurrentControlSet\services\W32Time\TimeProviders\NtpClient

Найдите параметр SpecialPollInterval. он как раз и определяет, с какой периодичностью клиент обращается к серверу точного времени. Значение параметра установлено в секундах.

Впишите желаемый интервал. Например, себе установил 21600 секунд = 6 часов (1 минута = 60 секунд, 1 час = 60 минут = 3600 секунд, 1 сутки = 24 часа = 86400 секунд):

Если у Вас нет в сети сервера точного времени, а стабильность связи с узлом time.windows.com оставляет желать лучшего, то Вы можете указать сервер точного времени или своей страны или ближайший доступный или выбранный пул адресов проекта ntppool.org.

На практике у меня встречалась "неразрешимая" проблема с синхронизацией времени на Windows 7. Кому интересно – читать здесь.