Справочная информация

Справочная информация

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

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

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

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

В составе архива и будет присутствовать необходимый компонент 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).

Пояснения по 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 ответить затрудняется. Что ж, надо помочь. Укажите для своей сети широковещательный адрес, например:

Настройка синхронизации времени АДУ RCE2700 от внешнего сервера времени

Для корректной работы системы сбора статистики необходимо, чтобы время на всех компьютерах (микроЭВМ) в ЛВС было одинаковое.

Проверка времени МикроЭВМ выполняется следующим образом.

Синхронизация АДУ RCE от сервера точного времени

Синхронизация АДУ от внешнего источника осноавна на настройке врешнего NTP сервера стандартными средствами операционной системы через файл /etc/ntp.conf.

Следует помнить, что для безопасности системы требуется закрыть возможность обращения к компьютеру АДУ аппаратным файрволом или маршрутизатором.

Для выполнения нсатройки следует внести изменения в файл /etc/ntp.conf:

#azimut_ntp_conf
driftfile /var/lib/ntp/ntp.drift
#restrict -4 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
server 192.168.1.171 iburst rpefer
server 127.127.1.0
fudge 127.127.1.0 startum 8

Рекомандации по настройке безопасности (пример)

restrict default kod notrap nomodify nopeer noquery
restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
restrict 127.0.0.1
restrict ::1

• 192.168.1.171 — адрес ntp-сервера
• restrict 127.0.0.1 — разрешает лбюые действия на локальной машине
• restrict default — задает значение по умолчанию для всех рестриктов.
• kod — узлам, которые часто отправляют запросы сначала отправить поцелуй смерти (kiss of death), затем отключить от сервера.
• notrap — не принимать управляющие команды.
• nomodify — запрещает команды, которые могут вносить изменения состояния.
• nopeer — не синхронизироваться с хостом.
• noquery — не принимать запросы.
• restrict 192.168.0.0 mask 255.255.255.0 — разрешить синхронизацию для узлов в сети 192.168.0.0/24.
• IP адреса127.0.0.1 и ::1 позволяют обмен данные серверу с самим собой.

Введите ваш запрос для начала поиска.

2021.11.01 2021.10.30 2021.10.30 2021.10.24 2021.10.05 2021.10.05

Частые вопросы:

Глиссада на разных высотах
Угол глиссады при удалении (в метрах) на разных высотах

Копирование файлов через SSH
Копирование файлов через SSH

Конфигуратор moccof
Скрипт конфигуратор moccof

Аналоги FSL3
Измерение параметров приёмоответчика DME/NL2700 с помощью анализатора спектра

О режиме "Защита ПРД" в ILS2700
Режим «Защита ПРД» в передатчиках Loc, GP

Синхронизация времени

Синхронизация времени в Linux возможна про протоколу NTP, описанному в RFC 5905, и протоколу TIME, описанному в RFC 868. В настоящее время, в подавляющем большинстве случаев, используется протокол NTP. Кроме того, в случае выключения компьютера, либо его перезагрузки, важна синхронизация системного времени с аппаратными часами реального времени материнской платы компьютера (RTC). В ALT есть несколько пакетов, обеспечивающих синхронизацию по протоколу NTP. Использовать одновременно несколько способов не следует. Так же существует дистрибутивонезависимое MINI-HOWTO на эту тему [1] .

Содержание

tzdata [ править ]

Пакет содержит множество описаний временны́х зон, нужная из которых копируется в /etc/localtime (либо это может быть символическая ссылка на соответствующий файл). Только этот файл определяет системную временну́ю зону. Для дистрибутивов ALT с sysvinit копирование может быть выполнено командой

Сама зона, в этом случае, определяется по значению переменной ZONE из /etc/sysconfig/clock.

NTP [ править ]

пакет openntpd [ править ]

Используется по-умолчанию в большинстве дистрибутивов ALT. Отличается высокой безопасностью и как следствие — некоторыми недостатками, самый неприятный из которых — это медленный старт, доходящий в некоторых случаях до суток. Сам демон имеет название ntpd, как и аналогичный из пакета ntp, однако не является совместимым с ним ни по параметрам запуска, ни по средствам контроля, ни по конфигурационному файлу.

пакет ntp [ править ]

Пакет является эталонной реализацией протокола ntp и имеет долгую историю. Считается не очень безопасным ввиду лидерства по количеству закрытых за историю CVE. В ALT пакет состоит из нескольких подпакетов. Непосредственно к синхронизации имеют отношение два, а третий полезен для контроля состояния ntpd.

ntpd [ править ]

Собственно сам демон, который может работать как в качестве клиента, так и в качестве сервера.

ntpdate [ править ]

Утилита, позволяющая однократно посмотреть время на каком-либо NTP-сервере (не обязательно ntpd) и/или синхронизировать с ним системное время. Если запущен ntpd, требуется использовать ключ -u при запуске.

ntpq [ править ]

Утилита, позволяющая посмотреть статус работающего ntpd, как локального, так и удалённого.

пакет chrony [ править ]

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

пакет systemd-timesyncd [ править ]

Является клиентом SNTP, не может быть сервером NTP.

TIME 868 [ править ]

пакет xinetd [ править ]

Встроенный сервер TIME 868 имеет демон xinetd. Чтобы служба заработала, надо в /etc/xinetd.d/time-tcp и /etc/xinetd.d/time-udp заменить «disable = yes» на «disable = no». Так же, не следует забывать про основной /etc/xinetd.conf, в котором, по-умолчанию, присутствует параметр «only_from = 127.0.0.1».

пакет rdate [ править ]

TIME 868 клиент

пакет netdate [ править ]

TIME 868 клиент

DAYTIME 867 [ править ]

Упоминается в контексте Samba. надо понять и дописать, для чего

Синхронизация системного времени с RTC [ править ]

Linux kernel [ править ]

При наличии синхронизации с NTP-сервером ядро каждые 11 минут обновляет время в RTC. Начиная с 3.10, из ядра выпилили код, который пытался обновлять в RTC только минуты и секунды, чтобы обновление работало независимо от часового пояса (но в этом случае не могло быть исправлено расхождение более чем на 15 минут) [2] . В результате, при использовании синхронизаторов, умеющих сообщать ядру о наличии синхронизации, ядро получило возможность выставить значение RTC в UTC в соответствии с текущим значением времени, что внесло некоторую путаницу.

Проверить, что функция синхронизации может быть активирована, можно посредством команды

пакет hwclock [ править ]

При запуске однократно синхронизирует RTC с системными часами, либо наоборот. В зависимости от параметров в RTC может быть установлено время в UTC, либо локальное. В момент исполнения hwclock создаёт файл /etc/adjtime, в котором записано отклонение RTC от системного времени и какое время (локальное, либо UTC) записано в RTC. При загрузке системное время выставляется относительно RTC по данными из adjtime. Несоответствие значения временной зоны в RTC и в файле adjtime (UTC/LOCAL) приводит к сдвигу системного времени при загрузке. В некоторых случаях (например, при использовании ntpd) можно просто обнулить содержимое /etc/adjtime после использования ( >/etc/adjtime ).

другие ОС [ править ]

Другие ОС тоже могут корректировать значение времени в RTC. Если на компьютере установлено более одной ОС, необходимо производить настройки таким образом, чтобы все ОС корректировали время в RTC одинаковым образом.

Как сделать сервер времени (NTP) на Arduino

GPS/GLONASS приёмник с UART

Модуль с часами реального времени DS1307

И, конечно же, нам понадобится модуль с сетевым интерфейсом или т.н. Ethernet-шилд. Этот модуль позволит подключить Arduino к локальной сети или к компьютеру по Ethernet.

Ethernet-шилд с микросхемой Wiznet W5100

В качестве альтернативы можно использовать Wi-Fi модуль, разумеется. Лишь бы ваши устройства, время на которых необходимо синхронизировать с сервером времени, находились в одной локальной сети с сервером времени на Arduino.

Теперь соединим все наши части воедино. Для этого сначала соберём «бутерброд» из Arduino и сетевого шилда, который выполнен в виде мезонинной платы. Далее подключим модуль часов DS1307 к выводам A4 и A5, а это шина I2C, как мы помним. Следовательно, пин A4 – это SDA, пин A5 – SCL. Приёмник сигналов ГНСС необходимо подключить к UART. Для этого можно подключить его к стандартным выводам RX и TX Arduino (пины 0 и 1, соответственно). Но тогда мы не сможем одновременно работать с приёмником и отлаживаться с выводом отладочных сообщений в последовательный порт. Поэтому рекомендую реализовать программный UART с помощью штатной библиотеки SoftwareSerial. Для этого подключим GPS приёмник к любым цифровым выводам (кроме 0 и 1), например, к 10 и 11.

Общий вид NTP сервера на Arduino

Не забудем питание и землю, разумеется. И модуль часов, и приёмник питаются одним напряжением, равным 5 вольтам.

2 Скетч NTP сервера для Arduino

Напишем скетч для Arduino, в котором реализуем функциональность сервера времени с поддержкой протокола NTP и с минимальным использованием сторонних библиотек.

Формат пакета NMEA с данными о времени

В конце статьи приложена программа для тестирования связи с NTP сервером.

Скетч сервера времени NTP и Arduino (разворачивается)

Проверка NMEA пакетов осуществляется в функции decodeTime().

Несколько слов о функции dec2hex(). В ней несколько извращённо число переводится из десятичного представления в 16-ное. Точнее, так. Модуль часов показывает время в виде, например, 16:52:08. Но здесь каждое из этих чисел не десятичное, а 16-ное. То есть, в действительности это время в RTC хранится так: 0x16:0x52:0x08. А с GPS-приёмника мы получаем время в десятичном формате. И чтобы записать те же 16 часов в модуль RTC, нужно преобразовать десятичное 16 в шестнадцатеричное 0x16, что является десятичным 22. А полное время 0x16:0x52:0x08 будет в десятичном представлении 22:82:08. Хм, 82 минуты, странно, да? 🙂 Но такое уж надо сделать преобразование, чтобы модуль часов реального времени запомнил правильное время.

3 Программа для тестирования NTP сервера на Arduino

В приложении к статье имеется архив с программой тестирования NTP .

Главное окно программы тестирования NTP/SNTP

Всё, что требуется для проверки NTP сервера – это ввести адрес сервера и нажать кнопку «Отправить запрос». Соответственно, нужно знать адрес вашего NTP сервера на Arduino. Можно выбрать сервер из списка предложенных в меню («Выбрать сервер»).

Программа также позволяет запустить локальный NTP сервер . Время она будет брать из операционной системы. Данная возможность пригодится для каких-то отладочных целей.