Данный материал является дополнением к публикации на тему установки
сервера времени 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.
