Каква е разликата между NTP протокола за синхронизиране на времето и SNTP? NTP - атомен часовник на всяка маса Време в Linux.

Защо се нуждаете от точно време?

Кой изобщо се нуждае от това точно време? Разбира се, ние, потребителите, се нуждаем от него, за да закъснеем по-малко. Представете си модерно летище - стотици пилоти и диспечери трябва да използват часовници без грешки, за да работят. Системата за регистриране на стоки в складове, болници, жп каси и много други институции изискват времето на всички обекти в системата да бъде горе-долу еднакво. Особено компютрите. Те изпълняват много услуги и програми, за нормалното функциониране на които е необходимо точно време и като правило по-точни от нас, хората обикновено се нуждаят. Системните услуги, компонентите за сигурност и дори простите приложни програми могат да бъдат много критични за точността на часовника. Най-яркият пример за такива услуги е протоколът за удостоверяване на Kerberos. Така че, за да работи, е необходимо на компютрите, до които се осъществява достъп чрез този протокол, системното време да се различава с не повече от 5 минути. Освен това точното време на всички компютри прави много по-лесно анализирането на регистрационни файлове за сигурност при разследване на инциденти в локалната мрежа.

NTP протокол

NTP (Network Time Protocol) е протокол, предназначен да синхронизира времето в мрежа. Това е набор от доста сложни алгоритми, предназначени да осигурят висока точност (до няколко микросекунди) и отказоустойчивост на системата за синхронизация на времето. И така, протоколът предполага едновременна синхронизация с няколко сървъра.

Има няколко версии на този протокол с някои разлики. Третата версия на този протокол е стандартизирана през 1992 г. като RFC 1305. Четвъртата (най-новата в момента) версия въвежда някои подобрения (автоматична конфигурация и удостоверяване, подобрени алгоритми за синхронизация) в сравнение с третата, но все още не е стандартизирана в RFC .

Освен това, в допълнение към NTP, има SNTP (Simple Network Time Protocol). На ниво пакет двата протокола са напълно съвместими. Основната разлика между двете е, че SNTP няма сложните системи за филтриране и многоетапна корекция на грешки, открити в NTP. По този начин SNTP е опростена и лесна за прилагане версия на NTP. Предназначен е за използване в мрежи, които не изискват много висока точност на времето, а при внедряването от Microsoft Corporation осигурява точност в рамките на 20 секунди в рамките на предприятието и не повече от 2 секунди в рамките на един сайт. SNTP е стандартизиран като RFC 1769 (версия 3) и RFC 2030 (версия 4).

Моделът на NTP синхронизация приема йерархична структура. Първото ниво на йерархията съдържа така наречените "основни" времеви сървъри (Първа страта). Те се намират на различни места по света и имат най-точно време. Такива сървъри са сравнително малко, тъй като точното време на тях се поддържа с помощта на скъпо специализирано оборудване (радиоканал, сателитен канал). Сървърите от второ ниво (втора страта) се синхронизират със сървъри от първо ниво с помощта на NTP протокол. Вече има много повече от тях, но те вече са донякъде несинхронизирани (от 1 до 20 милисекунди) спрямо "основните" сървъри. Освен това може да има сървъри от третото, четвъртото и следващите нива:

С прехода към всяко ниво грешката спрямо основния сървър леко се увеличава, но общият брой сървъри се увеличава и следователно натоварването им намалява. Следователно, вместо да се използват първични сървъри с най-точно време като външен източник на синхронизация, се препоръчва използването на вторични сървъри като по-малко натоварени.

За синхронизация на времето в OS Windows 2000 / XP / 2003 се използва SNTP протокол. Този протокол се поддържа от системната услуга Windows Time, включена в операционната система MS Windows 2000 / XP / 2003. Отличителна черта на тази реализация е, че услугата Windows Time поддържа удостоверяване на домейн при достъп до сървър за референтно време, което е важно от гледна точка на сигурността.

Има няколко опции за услугата SNTP, включена в Windows:

• Йерархичен (NT5DS). Това е по подразбиране за всички компютри, присъединени към домейна. Времевата синхронизация на работни станции и сървъри на домейни се извършва според йерархията. По този начин работните станции и сървърите-членове се синхронизират с контролера на домейна, който е удостоверил влизането, домейн контролерите с PDC емулатора операция master, който от своя страна се синхронизира с контролера на домейна на по-високото ниво на йерархията. Трябва да се отбележи, че този ред за синхронизиране се използва "по подразбиране" и може да бъде отменен ръчно или чрез групови политики. Как да направите това ще бъде описано по-долу.
• Принудително синхронизиране с избрания NTP сървър (NTP). В този случай източникът на референтното време за услугата Windows Time се задава ръчно или чрез групови правила.
• Деактивирайте синхронизацията (NoSync). Този режим е необходим за смесена схема за отчитане на времето, при която продукт на трета страна се използва за синхронизиране с външен източник, а Windows Time се използва за поддържане на времето в домейна.

По този начин, в случай на работна група, синхронизирането на времето все пак ще трябва да се конфигурира ръчно. Например, един от компютрите може да бъде конфигуриран да се синхронизира с външен сървър чрез SNTP, а останалите могат да бъдат конфигурирани да се синхронизират с него. Стъпките, необходими за това, ще бъдат описани по-долу.

Препоръчително е да използвате йерархична SNTP синхронизация за домейна. В повечето случаи осигурява разумна точност за системното време в рамките на гората на домейна. В допълнение, той автоматично гарантира сигурността на времевите актуализации, благодарение на поддръжката си за удостоверяване с Active Directory. За да поддържате "правилно" време на домейн, трябва да синхронизирате домейн контролера от най-високо ниво, който притежава ролята на PDC емулатор, с външен NTP сървър. В нашия пример, Linux машина с работещ ntpd демон ще действа като такъв сървър.

Конфигуриране на SNTP в Windows

За конфигуриране на услугата Windows Time се използват две помощни програми:

• Нетно време
• W32tm

Нетното време се използва главно за конфигуриране на услугата за време, докато w32tm се използва за наблюдение и диагностика на работата. Въпреки това, в Windows XP / 2003, помощната програма w32tm е претърпяла значителни промени и може да се използва за конфигуриране на услугата за време. Конфигурацията на NTP ще бъде извършена по-нататък на примера на Windows XP / 2003.

Така че, за да посочите "ръчно" източника на синхронизация, използвайки нетно време, достатъчно е да напишете в командния ред:

et time / setsntp: space_time_server_list

За да получите информация за текущия сървър за време:

нетно време / querysntp

Можете да разберете времето на домейн контролер по следния начин:

нетно време / домейн: име на домейн

И за да синхронизирате времето с домейн контролера по следния начин:

Нетно време / домейн: име_на домейн / набор

Системната помощна програма w32tm може да направи същото и още:

• w32tm / resync - Използвайки тази команда, можете да принудите локален или отдалечен компютър да синхронизира системния си часовник със сървъра за време, който използва.
• w32tm / config - Тази команда се използва за конфигуриране на услугата Windows Time. С негова помощ можете да посочите списъка на използваните сървъри за време и вида на синхронизация (йерархична или избрана от сървърите).

Например, за да замените стойностите по подразбиране и да конфигурирате синхронизиране на времето с външен източник, можете да използвате командата:

w32tm / config / syncfromflags: manual / manualpeerlist: PeerList

И за да може Windows Time да приложи новите настройки, вместо да рестартирате услугата, можете да използвате командата:

w32tm / config / update

Освен това в w32tm са налични следните параметри, свързани с наблюдението на времето на компютрите:

• w32tm / монитор - използвайки тази опция, можете да разберете как системното време на този компютър се различава от времето на домейн контролера или други компютри.
• w32tm / stripchart - Графично показва разликата във времето между текущия и отдалечения компютър.
• w32tm / register - Регистрира услугата Windows Time като услуга на този компютър. Тази опция може да бъде полезна на компютри, които не са включени в домейна, тъй като услугата за време е спряна на тях по подразбиране.

По-подробна информация за параметрите на нетното време и помощните програми w32tm може да се получи с помощта на /? или като отворите съответния раздел на Центъра за помощ и поддръжка MS Windows XP / 2003.

Както може би се досещате, настройките на услугата за време на Windows се съхраняват в системния регистър на Windows под HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ W32Time \.

В основата на раздела се определят параметрите на самата услуга, в подключа Config - настройките, свързани с работата на самия SNTP протокол, режимът на синхронизация се определя в подключа Parameters. Настройките на SNTP клиента и сървъра се намират съответно в подключовете TimeProviders \ NtpClient и TimeProviders \ NtpServer. Нека разгледаме основните стойности, които определят конфигурацията на NTP клиента и сървъра:

• Тип - определя режима на работа на NTP клиента (NTDS5 - йерархичен, NTP - "ръчен", NoSync - не се синхронизира, AllSync - всички видове синхронизация са налични);
• Enabled - определя дали този компонент е активиран (клиент или сървър);
• CrossSiteSyncFlags - определя дали е възможно да се синхронизира времето с източник извън домейна, ако се използва йерархична синхронизация (0 - не е позволено, 1 - само с PDC емулатора, 2 - с всички);
• EventLogFlags - определя дали съобщенията от Windows Time ще бъдат регистрирани или не (много полезна функция при отстраняване на грешки).

Друга възможност за конфигуриране на услугата за време на Windows е да използвате групови правила. Настройките са дефинирани в GPO на следния адрес: "Конфигурация на компютъра -> Административни шаблони -> Система -> Windows Time Service".

Ако имате инсталиран Windows 2000 Server и не сте намерили такава настройка, не се отчайвайте, просто трябва да актуализирате административните шаблони. За да направите това, копирайте всички .adm файлове от папката system32 \ GroupPolicy \ Adm на всяка машина с инсталиран Windows XP на сървъра, който е домейн контролер. След това, дефинирайки GPO, щракнете с десния бутон върху „Административни шаблони“ и изберете „Добавяне/Премахване на шаблони...“ Изтрийте изброените там шаблони и добавете копираните. След като щракнете върху OK, шаблоните ще бъдат актуализирани и можете да конфигурирате услугата за време, като използвате групови правила:

Лесно е да се види, че тук са главно всички онези настройки, които могат да се променят в системния регистър. Това не е изненадващо, тъй като по този начин работят повечето групови политики.

В Windows XP има друг начин да зададете времеви сървър, който може да бъде много удобен за настройка на синхронизация на домашен компютър или компютър, който е член на работна група:

NTP сървър за Linux - външна синхронизация за Windows домейн

Както бе споменато по-горе, протоколът NTP е по-устойчив на грешки, така че е по-добре да използвате NTP сървър като източник на референтно време за външна синхронизация. Освен това контролерът на домейн от най-високо ниво не винаги има достъп до интернет през UDP порт 123, който се използва за NTP работа. Достъпът може да бъде отказан от съображения за сигурност, което е обичайна практика в големите организации. В такива случаи, за да разрешите този проблем, можете да инсталирате свой собствен сървър за време в DMZ, който е конфигуриран да синхронизира с външен източник и да го използвате като референтен източник на време за синхронизиране на контролера на домейн от най-високо ниво. Всеки компютър е доста подходящ като такъв компютър, а не непременно модерна машина с * nix-подобна ОС, например Linux, инсталирана в минимална конфигурация, без X сървър и други потенциално уязвими неща.

Има много програми за синхронизиране на времето за Linux. Най-известните са Xntpd (NTP версия 3), ntpd (NTP версия 4), Crony и ClockSpeed. В нашия пример ще използваме ntp сървъра ntpd, включен в Redhat 9, предоставен в пакета ntp-4.1.2-0.rc1.2.i386.rpm.

Пакетът включва няколко програми, предназначени за работа с NTP.

Ето основните от тях:

• Ntpd - ntp демон, който поддържа точно време във фонов режим;
• Ntpq е помощна програма, предназначена за анкетиране на NTP сървъри, които поддържат стандартния протокол за запитване NTP режим 6. Може да се използва за откриване и промяна на текущото състояние на сървъра, ако настройките му позволяват това;
• Ntptdc - помощна програма, с която можете да анкетирате демона ntpd и да получите статистика за работата му;
• Ntpdate е програма за настройка на текущото системно време с помощта на NTP протокола.

Удостоверяването е стандартна функция на NTP. В този случай могат да се използват както симетрични алгоритми (DES), появили се във втората версия на протокола, така и асиметрични алгоритми с публичен ключ, които са иновация на четвъртата версия.

В случай на използване на симетрична схема за удостоверяване, клиентът и сървърът избират произволен идентификатор и един от 65534 ключа, дефинирани от стандарта. При използване на асиметрични алгоритми се използва така наречената схема Autokey, чиято отличителна черта е, че няма нужда от предварително разпределение на публичните ключове на сървърите.

За да конфигурирате удостоверяване в ntpd, има помощните програми ntp-genkeys, ntpq и ntpdc.

Цялата NTP функционалност за отчитане на времето е внедрена в демона ntpd. Конфигурира се по обичайния UNIX начин - чрез редактиране на конфигурационния файл ntp.conf, намиращ се в папката / etc.

Нека зададем следните опции за NTP сървъра.

Първо ще посочим сървърите, с които ще се извърши синхронизиране на времето:

сървър ntp.nasa.gov # Сървър от ниво 1 в nasa.org
сървър ntp1.demos.net # Сървър от stratum 2 на demos.net

ограничи ntp.research.gov маска 255.255.255.255 nomodify notrap noquery

Тук маската 255.255.255.255 се използва за ограничаване на достъпа до нашия сървър от страна на сървъра ntp.nasa.gov. Сега нека дефинираме списък с възли в нашата локална мрежа, на които искаме да разрешим достъп до нашия NTP сървър, за да получим времето:

ограничи 192.168.1.0 маска 255.255.255.0 notrust nomodify notrap

Също така се нуждаем от Linux машината, за да имаме пълен достъп до ресурсите на своя сървър:

ограничи 127.0.0.1

И сега най-важното: трябва да се уверим, че забраната по подразбиране, която има по-висок приоритет, е коментирана:

#restrict игнориране по подразбиране

След запазване на файла ntp.conf конфигурацията може да се счита за завършена, но може да се случи, че след стартиране на демона времето все още няма да бъде синхронизирано. Въпросът е, че NTP първоначално е проектиран като протокол за отчитане на времето, а не протокол за настройка на времето. Следователно, ако разликата между показанията на часовника е достатъчно голяма (повече от няколко минути), синхронизацията няма да се извърши. В този случай има смисъл първоначално да зададете времето ръчно, като използвате командата ntpdate (можете също да добавите командата ntpdate към скриптовете за стартиране на машината):

# ntpdate clock.vsu.ru
17 февруари 23:44:54 ntpdate: сървър за време на стъпка 198.123.30.132 отместване 25,307598 сек

17 февруари 23:45:05 ntpdate: коригира време сървър 198.123.30.132 отместване 0,002181 сек
# ntpdate clock.vsu.ru

Демонът ntp се стартира чрез скриптовете за инициализация. Ако програмата е инсталирана от rpm пакет, тогава най-вероятно всички проблеми, свързани с автоматичното й стартиране, вече са разрешени. За да проверите това, можете да използвате командата:

# chkconfig -списък ntpd
ntpd 0: вкл. 1: изкл. 2: изкл. 3: вкл. 4: изкл. 5: вкл. 6: изкл.

Ако не виждате този ред, значи ntpd не е конфигуриран да стартира автоматично. За да коригирате това, въведете:

# chkconfig – включено ниво 035 ntpd

За управление на NTP (старт, стартиране, рестартиране, състояние) се използва стандартен скрипт за инициализация:

# /etc/init.d/ntpd старт

За да видите статистика за синхронизиране на сървъра, можете да използвате следната команда:

# ntpq -p
дистанционен refid st t, когато анкетата достигне закъснение, компенсира трептене
==============================================================================
* тик.usnogps.na .USNO. 1 u 38 64 377 220,00 0,149 7,08
-navobs1.wustl.e. PSC. 1 u 55 64 377 193,47 6,857 4,81
-ntp-nasa.arc.na .GPS. 1 u 43 64 377 254,88 7,471 9,58
-ntp0.NL.net .GPS. 1 u 144 512 377 122,54 12,515 13,75
-ntp2.ien.it .IEN. 1 u 558 1024 377 133,94 14,594 41,99
+ хронометрист.isi. .GPS. 1 u 13 64 377 245,30 3,454 15,08
+ news-zero.demos ntp0.usno.navy. 2 у 16 ​​64 377 37,51 -3,239 11,14
МЕСТНО (0) МЕСТНО (0) 10 л - 64 377 0,00 0,000 10,01

NTP сървър/клиент режими на работа

Клиентски сървър

Този режим е най-често използваният в Интернет. Схемата на работа е класическа. Клиентът изпраща заявка, на която сървърът изпраща отговор за известно време. Клиентът се конфигурира с помощта на директивата сървър в конфигурационния файл, където е посочено DNS името на сървъра за време.

Симетричен активен/пасивен режим

Този режим се използва, когато се извършва синхронизация на времето между голям брой равни машини. В допълнение към факта, че всяка машина е синхронизирана с външен източник, тя се синхронизира и със своите съседи (peer), като им действа като клиент и времеви сървър. Следователно, дори ако машината "загуби" външен източник, тя все още може да получи точно време от своите съседи. Съседите могат да работят в два режима - активен и пасивен. Работейки в активен режим, самата машина прехвърля времето си към всички съседни машини, изброени в секцията за партньори на конфигурационния файл ntp.conf. Ако съседите не са посочени в този раздел, тогава машината се счита за в пасивен режим. За да предотвратите нападателя да компрометира други машини, представяйки се като активен източник, е необходимо да използвате удостоверяване.

Режим на излъчване

Този режим се препоръчва за случаите, когато малък брой сървъри обслужват голям брой клиенти. В този режим сървърът периодично изпраща пакети, използвайки адреса на подмрежата за излъчване. Клиент, конфигуриран да синхронизира по този начин, получава излъчвания пакет на сървъра и се синхронизира със сървъра. Характеристика на този режим е, че времето се доставя в рамките на една подмрежа (ограничение на разпръскващия пакет). Освен това, удостоверяването трябва да се използва за защита срещу натрапници.

Режим на мултикаст

Този режим много прилича на излъчване. Разликата е, че множествените адреси на мрежи от клас D в IP адресното пространство се използват за доставка на пакети. За клиенти и сървъри се задава адресът на групата за мултикаст, който те използват за синхронизиране на времето. Това прави възможно синхронизирането на групи от машини, разположени в различни подмрежи, при условие че свързващите ги рутери поддържат IGMP и са конфигурирани да предават мултикаст трафик.

Многокаст режим

Този режим е нов за четвъртата версия на NTP протокола. Това означава, че клиентът търси многокаст сървъри сред своите съседи на мрежата, получава времеви проби от всеки от тях (използвайки криптография) и въз основа на тези данни избира три „най-добри“ многокаст сървъра, с които клиентът ще се синхронизира. В случай на повреда на един от сървърите, клиентът автоматично актуализира своя списък.

За да предават времеви проби, клиентите и сървърите, работещи в режим на много предаване, използват адреси на групи за множествено предаване (мрежи от клас D). Клиенти и сървъри, използващи един и същ адрес, образуват една и съща асоциация. Броят на асоциациите се определя от броя на използваните множествени адреси.

Често задавани въпроси

Защо времето не се синхронизира след командата net time / setsntp: server?

Уверете се, че услугата w32time е настроена на тип стартиране Автоматично.
Уверете се, че UDP порт 123 на NTP сървъра, който използвате, е наличен.
Уверете се, че времето между клиент и сървър не се различава твърде много.

Може ли SNTP клиент да се синхронизира с NTP сървър?

Да, може, тъй като SNTP е подмножество на NTP и е напълно съвместим с него.

Мога ли да използвам NTP сървър на трета страна под Windows 2000 / XP / 2003?

Да, можете да използвате всеки сървър, платен или безплатен. Първо трябва да деактивирате съответните компоненти (клиент или сървър) на Windows Time Services.

Защо NTP клиентът не работи на компютъра с инсталиран MS SQL Server?

Най-вероятно проблемът е, че SQL Server по някакъв начин заема UDP порт 123. Като решение можете да предложите да стартирате NTP клиента преди MS SQL Server.

След стартиране на ntpd демона работи 10-20 минути, след което спира. Какъв може да е проблемът?

Уверете се, че времето между клиента и сървъра не се различава твърде много (не повече от 5 минути). В противен случай, принудително синхронизиране с ntpdate.

Възможно ли е да се синхронизира времето в OS Windows NT4, 95, 98, Me?

Възможно е с помощта на програми на трети страни, например NetTime, Automacahron, World Time5, ntpd Windows NT порт.

Когато се опитам да вляза в домейн на Windows, получавам съобщение, че времето между контролера на домейна и работната станция е твърде различно, въпреки че синхронизацията е фино настроена.

Най-вероятно проблемът е, че времето се е заблудило (нулиране на CMOS, хакерски саботаж) и услугата не може да бъде удостоверена с помощта на протокола Kerberos. За да разрешите този проблем, трябва или ръчно да зададете часа, или да не използвате този тип удостоверяване при актуализиране на часа.

Първо, нека решим защо трябва да синхронизираме времето на оборудване, като комутатори, рутери, защитни стени и т.н.

Това се прави предимно с цел проследяване на регистрационните файлове, когато се е случило това или онова събитие. И можете да си представите каква ще е ползата от логовете, ако времето не е синхронизирано.. правилно - няма.

протокол NTPработи на базата на протокола UDP, през 123 порт.

Този протокол има определена йерархия за синхронизиране на системи, с други думи нива.

Ниво 1 е присвоено на система, която се синхронизира с часовник с висока точност, като GPS.

Системата, която ще се синхронизира от ниво 1, ще има ниво 2 и т.н.

Така можем да определим колко точно времето има станцията, с която синхронизираме.

В нашата ситуация имаме машина в мрежата с точното време, конфигурирах я на базата на FreeBSD, от тази машина основното мрежово устройство ще отнеме време (синхронизиране) и по този начин ще стане основно за други мрежови устройства (в идеологията, cisco ще ntp master).

Бих искал да отбележа факта, че NTP предава време само във формат UTC (Гринуич), всяка часова зона се конфигурира директно върху парчето желязо.

Нека да разгледаме пример за проста настройка на NTP.

Първо, синхронизираме времето на нашия основен рутер (който ще се разпространява до други мрежови устройства). За да направите това, отидете в режим на глобална конфигурация:

ntp сървър 10.0.100.254

където 10.0.100.254 в нашия случай е FreeBSD машина с точно време.

Това е достатъчно за минимално персонализиране.

Сега нека проверим дали успяхме да се свържем със сървъра за време и да получим времето от него, за това използваме командата:

трябва да види нещо подобно:

Звездичката срещу ip на нашия ntp сървър ни казва, че всичко е наред, връзката поне е установена.

Сега да видим дали времето е синхронизирано?

Времето е получено, сега трябва да зададете часовата зона, от която се нуждаете. По същия начин, в режим на глобална конфигурация, правим:

часовник часова зона MSK / MSD 3

Всичко е страхотно.

Нека да преминем към настройката на нашия рутер в главен режим.

За тази настройка ни трябва този рутер да е главен и да посочи нивото (в cisco се нарича стратен номер), същият, за който говорих в началото, ще посоча петото ниво.

Сега нека се опитаме да конфигурираме ntp на друго устройство за настройка, така че да се синхронизира с нашия основен рутер, това се прави по същия начин като настройката на синхронизация със сървъра FreeBSD тук по-горе.

предпочитан ntp сървър 10.0.100.1

където 10.0.100.1 е нашият главен рутер.

предпочитаттова е ключова дума, която показва, че този ntp сървър е приоритет (тоест можете да напишете, че можете да синхронизирате не от един сървър, а от няколко, това се прави така, че ако един не е наличен или времето е твърде различно от останалите, което показва кои някои проблеми, устройството може да превключи към друг сървър за време, и предпочитание прави този сървър по-предпочитан от други.)

ние също така посочваме часовата зона, от която се нуждаем.

часовник часова зона MSK / MSD 3

Ние проверяваме:

Всичко е страхотно, всичко работи.

Сега нека разгледаме въпроса за сигурността.

Като начало, нека разгледаме въпроса за ограничаването с помощта на ACL, кой може да синхронизира и кой не.

Всичко е доста стандартно и прозрачно.

Създайте съответния ACL на сървъра за време:

списък за достъп 20 забележка ДОСТЪП до NTP Syncсписък за достъп 20 разрешение 10.0.100.3

сега ще свържем този списък за достъп към ntp.

ntp група за достъп, обслужваща само 20

Ако всичко е конфигурирано правилно, тогава връзката с ntp север ще бъде установена и синхронизацията ще бъде успешна.

Можете също така допълнително да регистрирате списък за достъп на клиенти. Кои сървъри за време може да се свържете. Това се прави по подобен начин:

списък за достъп 20 забележка ДОСТЪП SYNC към NTP Servсписък за достъп 20 разрешение 10.0.100.1

Свържете списъка за достъп до NTP

ntp партньорска група за достъп 20

Сега нека разгледаме сигурността, базирана на удостоверяване.

Всичко също е доста прозрачно.

Достатъчно е да добавите следното към ntp конфигурацията:

ntp ключ за удостоверяване 1 md5 15060E1F10243F34 7ntp удостоверяванеntp доверен ключ 1

ASW-M # отстраняване на грешки ntp?регулирайте настройките на NTP часовникаудостоверяване NTP удостоверяванесъбития NTP събитияloopfilter NTP контурен филтърпакети NTP пакетиparams параметри на NTP часовникаrefclock NTP референтни часовнициизберете избор на NTP часовниксинхронизиране на NTP часовник синхронизациявалидност валидност на NTP партньорски часовникASW-M # отстраняване на грешки ntp

От известно време задачата да се установи точното време е изправена не само пред човек. Много системи, създадени от него, за правилното функциониране трябва постоянно да имат на разположение много точен часовник, а тяхната точност трябва да бъде много по-висока от часовниците, използвани от хората в ежедневието. В допълнение към действителната точност на часовника, неговата синхронизация с универсалната времева скала е също толкова важна. В крайна сметка, дори и в мащаб UTC(Координирано универсално време, което е в основата на гражданското време), промените се правят периодично под формата на скокна секунда поради несъответствия с атомното време (например във време, когато нашата планета все още е била обитавана от първите динозаври, продължителността на деня беше около 22 часа).

Като ярки примери за системи, които използват много точни и надеждни методи за изчисляване на текущото време, изобщо не е необходимо да си представяме комплекси, които контролират движението на космически кораб или услуги за контрол на въздушното движение - въпреки че, разбира се, изискванията за точността на часовниците на всички елементи на такива системи са на най-високо ниво. Часовник, който е стабилен и синхронизиран с универсалното време, също е необходим в системи, които изпълняват по-прости задачи. Те включват например научни и индустриални комплекси, които обработват данни в реално време от различни устройства. Добавете и всичко останало, свързано с финансите - това е провеждането на банкови транзакции, системите за таксуване за мобилни оператори и интернет доставчици, които таксуват трафика, който обслужват. Всичко това са примери за системи, чието внедряване е невъзможно без използването на часовници, които са синхронизирани и съобразени с универсалното време. В компютърните мрежи протоколът за удостоверяване на клиента също използва сравнението на времето на сървъра с часовника на клиента.

Развитието на комуникациите в наше време значително опрости задачата за получаване на точно време. Сега имаме „над главата“ (по-точно в орбити около Земята) има няколко десетки спътника на глобални системи за позициониране, чиито бордови часовници са практически стандарти за време. Сигналите, които изпращат, могат да се използват за много точно синхронизиране на часовниците. В компютърните мрежи синхронизацията обикновено се извършва със сървъри за време с помощта на протокола NTP(Протокол за мрежово време) или неговата "олекотена" версия - SNTP(Simple Network Time Protocol) в случаите, когато максималната функционалност за използване на пълен NTP не е необходима.

NTP използва йерархична система от нива или слоеве. NTP сървърът има най-високо ниво ( слой 1), ако получава данни директно от точен източник на време. Сървърите, които синхронизират часовниците си със сървъра от 1-ва страта, са в този модел на по-ниско ниво (страт 2) и т.н. NTP протоколът, за разлика от SNTP, осигурява по-висока точност на синхронизация, използвайки сложни алгоритми за изчисляване на времето за предаване на пакети на мрежата и може да извършва проверка на грешки и филтриране на UDP пакети.

Най-общо казано, протоколът SNTP работи доста просто и обикновено се извършва на три етапа:

• Клиентът, който трябва да получи време, изпраща UDP пакет, съдържащ SNTP заявка до общия порт 123 на NTP сървъра, и преминава в режим на изчакване за отговор. В тази заявка той поставя времеви печат на собствения си часовник.
• Когато се получи заявка, сървърът отговаря с UDP пакет, съдържащ SNTP съобщение, изпращайки го до клиента от порт 123. Пакетът записва полученото времеви печат на клиента и времевия печат на самия сървър.
• При получаване на отговор клиентът може да използва времевата марка, която сам е създал при изпращане на заявката, за да потвърди коректността на отговора, опитвайки се да се увери, че е изпратен точно към заявката на този клиент (ако пакетът е изпратен до заявка от друг източник, вероятността да съдържа същото времеви печат, изключително ниска). След това извлича стойността на времевата марка за предаване, трансформира я според прогнозната латентност, причинена от преминаването на пакета през мрежата, и използва резултата, за да настрои системния си часовник.

Пакетните формати и за двата протокола са еднакви, което позволява на NTP сървъра да работи както с NTP, така и с SNTP клиенти.

Структура на NTP рамка

NTP сървърите, като правило, имат само един отворен "out" порт - UDP 123. При тази конфигурация администраторът не трябва да се тревожи твърде много за сигурността на сървъра, тъй като той е практически неуязвим за атаки от злонамерени програми. Въпреки това е много важно да се гарантира наличността на сървъра от 1-ва страта за клиенти, в противен случай се губи самият смисъл на неговата работа. Основният проблем е броят на заявките, които NTP сървърът може да обработи. Самите заявки обаче могат да бъдат генерирани по много любопитни причини.

Най-известните случаи на NTP вандализъм

В средата на май 2003 г. служителите на университета Медисън откриха рязко нарастващ интернет трафик, който беше насочен към публичните NTP сървъри на университета. Трафикът беше NTP заявки, състоящи се от 76-байтови пакети, изпратени до UDP порт 123. Тези пакети обаче имаха необичайно свойство: въпреки че идваха от различни източници, всички те бяха изпратени от порт номер 23457.

За защита на сървърите беше променена конфигурацията на рутерите, което блокира само тази част от входящите заявки към NTP сървъри, нормалните заявки продължиха да се обслужват нормално. Блокиран е само целия UDP трафик, съдържащ заявки към NTP сървъра, изпратени от порт 23457 към порт 123. В този момент служителите просто смятат, че са изправени пред разпределена атака на отказ на услуга ( DDoS атака, от англ. Distributed Denial of Service), организиран от много произволни адреси и спря там, като се предположи, че наводнението ще отшуми в рамките на няколко часа, както обикновено се случва при атаки от ниско ниво.

Месец по-късно се оказа, че потокът от входящ NTP трафик се е увеличил значително, достигайки огромни стойности - 250 хиляди пакета в секунда, с обем над 150 Mb / s. Внимателно деблокирайки някои интерфейси, служителите започнаха да проверяват UDP пакетите, включително тяхното съдържание. Изглежда, че са валидни заявки за SNTP версия 1, въпреки че високата им интензивност от всеки хост беше неясна. Например, по време на единичен период на проследяване, множество клиенти генерираха приблизително една заявка в секунда. Това би било изключително странно за правилно функциониращ SNTP клиент. Приложенията, базирани на SNTP, задават само собствен системен часовник с необходимата прецизност, така че хостът да има добра представа за текущото време.

Искането на време всяка секунда е просто нелепо и далеч от обичайното поведение на NTP клиент. Ако случаен минувач попита за времето на вашата улица, това е нормално. Но ако той започне да се интересува от времето всеки път веднага след като отговорите, и още някои хора се присъединят към него? Ако това продължи седмици? Стана ясно, че е необходимо да се справят с причините за случващото се.

Нито един от източниците на заявка не беше в LAN на кампуса. Това означаваше, че за разследване на причините за инцидента ще е необходима помощта на администраторите на отдалечените сървъри. От най-активните IP адреси бяха избрани два клиента, разположени в мрежи на други университети. До мрежовите администратори беше изпратен имейл с описание на проблема и с молба да разберат какви OS и SNTP клиенти могат да работят на тези хостове и кои услуги могат да изпращат заявки от тях чрез UDP порт 23457.

Получените отговори съдържаха информация, че източникът на трафик са производствени рутери Netgear(по-специално, един от тях е идентифициран като модел MR814). Сега събитията започнаха да придобиват някакъв смисъл. Голям брой хостове, използващи един и същ порт, могат да бъдат обяснени с вградения SNTP клиент с програмиран номер на порт. Служителите на университета Медисън започнаха да събират информация за продуктите на Netgear, претендиращи за поддръжка на NTP. След проверка на кода се оказа, че в някои от тях производителят просто програмно е „пришил“ информация за NTP сървърите. В допълнение към IP адресите от диапазоните, запазени за локални мрежи, те съдържаха IP адреси с глобална маршрутизация, сред които беше публичният NTP сървър на Медисънския университет. Проблемът се влоши от факта, че от глобалните IP адреси, посочени в кода, само университетът беше истинският NTP сървър и вграденият клиент на рутера, след като не получи отговор на SNTP заявката, започна да генерира нови заявки всяка секунда.

След като най-накрая идентифицираха причините за наводнението на NTP, служителите на университета се обърнаха към производителя на рутера. Netgear трябваше да признае грешката си. Оказа се, че по това време вече са продадени повече от седемстотин хиляди такива устройства. Простите изчисления показват, че те са били потенциално способни да генерират 426 Mbps трафик (700 000 UDP пакета в секунда, всеки с дължина 76 байта), насочен към същия NTP сървър.

За решаване на проблема беше сформирана група с участието на представители на университета, производителя и независими експерти. Коригираните версии на софтуера бяха пуснати сравнително бързо за устройства, съдържащи грешки в кода. Разбира се, това не реши всички проблеми - в края на краищата пускането на нова версия на фърмуера от производителя не означава замяната му от всички потребители, повечето от които дори не подозираха за подобни проблеми. Въпреки това университетът реши да продължи да обслужва дефектните устройства Netgear, като им даде възможност да синхронизират системния часовник (независимо дали това решение е свързано със сумата от $375 000, която Netgear плати на университета в Медисън, се казва, че „подобрява сигурността на безжичната мрежа и развиват мрежата на кампуса." , авторът не е известен със сигурност).

През същата година подобен инцидент се случи в Австралия. Този път участниците бяха Националната лаборатория за измервания на Австралийската организация за научни и промишлени изследвания (Commonwealth Scientific and Research Organization, CSIRO) и базиран в Калифорния производител на мрежово оборудване SMC мрежи... Максимално натоварване на CSIRO NTP сървъри (1-ви слой, източник - цезиев часовник, иначе наречен " атомен") Беше оценено на 200 kbit / s. Блокирането на трафик, повечето от който идваше от чужбина, доведе до факта, че SMC устройствата, при липса на отговор от NTP сървъра, започнаха да изпращат заявки два пъти в минута. В крайна сметка CSIRO реши да промени адресите на своите времеви сървъри (след като предварително уведоми партньорите си) и доставчиците просто започнаха да блокират заявки от източници, разположени извън Австралия.

Последният най-известен проблем от този вид се случи през 2005 г. и за първи път беше наречен „ NTP вандализъм“, което по-късно беше прието като общ термин за случаи на злоупотреба с NTP сървъри. След това „черната марка“ отиде в датския сървър от 1-ва страта, свързан към националната датска мрежа за обмен на интернет (DIX). Сървърът беше собственост на един от разработчиците на FreeBSD - Полу-Hoening Campu(Poul-Henning Kamp) и въпреки че не е собственост на правителствени или академични институции, съществува на нестопанска основа. Правилата за използване изрично посочват, че само NTP сървъри от втория слой, разположени в Дания и приложения, които изискват изключително точно време, могат да го използват за синхронизация на времето.

Концернът е действал като вандал D-Link... Според собственика на NTP сървъра, 75% до 90% от заявките са генерирани от рутери, произведени от D-Link. Когато броят на такива пакети надхвърли три милиона на ден, доставчикът поиска от Kamp да заплати разходите, причинени от значителното увеличение на трафика, възлизащи на 54 000 DKK (приблизително 8 800 USD) на година.

Както и при Медисънския университет, Камп се обърна към D-Link, надявайки се на решение на проблема и възстановяване на причинените от него финансови разходи. За разлика от Netgear, D-Link отрече изобщо да е имало проблем, обвинявайки Кампа в изнудване в отговор. Конфронтацията продължи почти шест месеца, докато Камп не разкри всички подробности около инцидента. Накрая през април 2006 г. страните постигнаха мирно споразумение. Беше обявено, че съществуващите продукти на D-Link ще получат оторизиран достъп до сървъра Kampa NTP, а следващите ще спрат да го използват (финансовата страна на споразумението е неизвестна, но според някои оценки, поддържане на собствени сървъри за време, способни да обслужването на такъв трафик би струвало на D- Link около $ 1000 на месец).

Технически решения

Всички тези случаи накараха разработчиците на мрежови протоколи да се замислят как в допълнение към прилагането на различни политики за достъп, подобни проблеми могат да бъдат избегнати в бъдеще. Едно от решенията бяха промените, направени в четвъртата версия на NTP протокола, която се появи в началото на 2006 г. и описана в RFC 4330. Те включват разширяване на семантиката на полетата на NTP пакета, така че сървърът да може да изпраща специален контролен пакет с романтичното име " целувката на смъртта"(Kiss-o" -Death, KoD). В такъв пакет заглавките се попълват по специален начин - второто поле съдържа стойността 3, полето, указващо сървърния слой, е настроено на 0, а идентификаторът на връзката съдържа 4-байтов код, указващ причината за изпращането му (на практика досега се използва само RATE кода - превишаване на честотата на заявките).

Изпращането на такъв пакет до клиента означава, че сървърът е открил нарушение от страна на клиента на правилата за достъп до него и клиентът ще бъде прекратен. След като го получи, клиентът трябва да спре да изпраща заявки и да опита, ако е необходимо, да намери друг NTP сървър. Ако клиентът не може да намери друг наличен NTP сървър, той трябва да намали скоростта на заявка към стария сървър според експоненциално намаляващ алгоритъм.

Документът представя и препоръчителните принципи, според които „правилният“ NTP клиент трябва да формира интервали от време, които определят честотата на заявките към сървъра, и да се използват елементи от мрежовата инфраструктура (включително DNS и DHCP). Ако се планира да се посочат директни адреси на NTP сървъри във вградения код на устройството, силнопрепоръчително е да направите това само след споразумение със собствениците им.

По принцип подобни иновации са доста разумни, но всяка осезаема полза от тях ще бъде възможна само когато поразителенброят на NTP сървърите и клиентите в глобалната мрежа ще отговаря напълно на изискванията на четвъртата версия на NTP протокола. Уви, в близко бъдеще няма причина да се надяваме на развитието на събитията по този начин (между другото, една от „следите“, благодарение на които Camp стигна до заключението, че източникът на атаките са рутери на D-Link беше, че всички те използваха SNTP версия 1).

Проектът pool.ntp.org може да се отбележи като техническо решение, което може значително да намали пиковото натоварване на сървърите за време. Това е голям виртуален клъстер от географски разпределени ntp сървъри (към момента на писане на тази статия включва 1742 сървъра от всички континенти). Самият проект стартира през 2003 г., като плод на дискусия за значителните разходи, необходими за поддръжка и експлоатация на надеждни сървъри за време, способни постоянно да обслужват значителен брой заявки. Идеята зад него е много подобна на рекурсивния механизъм на функциониране на DNS сървърите. Ако само сървър от формата 0.pool.ntp.org е посочен като сървър, предоставящ точното време, тогава истинският сървър, с който ще се синхронизира времето, ще бъде произволно избран при всяка клиентска заявка от списъка на сървърите, включени в басейна. Потребителите на пула обаче могат самостоятелно да избират сървъри за регионално време, посочвайки континенталната зона или дори зоната на конкретна държава (като правило, колкото по-близо е сървърът, толкова по-точно се извършва синхронизацията), например - 0.ru. pool.ntp.org за Русия. Трябва да се помни, че някои държави не са представени в пула, а някои са представени от един или два сървъра (например Малайзия). Ползването на пула е безплатно, с изключение на обслужващи компании, произвеждащи хардуерни и софтуерни продукти, чиито NTP заявки се планира да се обслужват с помощта на ресурсите на pool.ntp.org.

Самата идея за стартиране на публична услуга за синхронизация с точен часовник, без да се гарантира нейната стабилност и надеждност при екстремни натоварвания, едва ли има смисъл. Историята знае много примери за починали NTP сървъри с декларирания 1-ви слой, "отчитащи" време, което се различава от реалното с десетки (!) Секунди или просто става недостъпно за заявки. Услуга, която ви позволява да синхронизирате часовници с точен източник на време, е точно случаят, когато концепцията за надеждност е толкова важна, колкото и точността на предоставените данни. Ето илюстрация на действителната работа на Mobatime Systems NTP сървър:

Статистика на заявките за NTP сървър на Mobatime Systems

Това е доста поразителен пример за вандализъм на NTP - на 1 април 2009 г. 75 хоста бяха блокирани, изпращайки повече 12 милионазаявки на ден. Подобна интензивност на атаката продължи 3 дни, като естеството й трудно може да се обясни с тривиални грешки в кода на устройството или с неправилната им конфигурация. За да се предпази от подобни атаки, Mobatime NTP сървърът използва алгоритми за филтриране на входящия трафик. Този защитен механизъм ви позволява да отрежете лавинообразен поток от "отломки", които могат да доведат системата до пълен отказ за кратко време.

Въпреки това, такава защита ще стане практически безполезна, ако количеството данни в предавателния канал се доближи до неговата честотна лента. При такова натоварване изпращането на данни до легитимни, деблокирани клиенти просто ще стане невъзможно поради изчерпването на ресурсите на комуникационния канал. Единственият изход от ситуацията, който гарантира почти пълно изключване на случаите на NTP вандализъм, може би е създаването на непубличен сървър за време с ограничен достъп. Разполагайки с надежден източник на време (например приемник на данни, предавани от GPS системата), такъв NTP сървър ще бъде стабилен доставчик на услуга за точно време.

Списък на материалите, използвани при подготовката на публикацията (на английски език):

• Описание на протокола RFC 4330 SNTP v4
• Дефектни маршрутизатори наводняват Интернет времеви сървър на Университета на Уисконсин – Доклад за инцидента с университета в Медисън, публикуван от неговия сътрудник Дейв Плонка.
• Мрежовите устройства почти свалят атомния часовник - статия за инцидент в CSIRO
• Когато фърмуер атакува! (DDoS от D-Link) - Статия от Ричард Клейтън, който участва в изясняване на обстоятелствата около атаката срещу NTP сървъра Paul-Hoening Camp
• Материали от сайта на организацията pool.ntp.org
• Помогнете за спасяването на застрашените сървъри за време - статия на Анди Лестър на pool.ntp.org

Не знам! Просто искам да поддържам времето си точно! Моля, кажете ми какво да правя?

MSK-IX NTP сървър е публичен сървър за време, поддържан от MSK-IX. Сървърът за време е предназначен за синхронизация с референтния източник на вътрешните часовници на компютрите и мрежовото оборудване (сървъри, рутери, смартфони и др.) с помощта на NTP протокола.

MSK-IX NTP сървърът принадлежи към най-високото ниво на точност (Stratum One Time Servers) в йерархичната система от часови нива. Като референтен времеви сигнал се използва сигналът на глобалните сателитни навигационни системи ГЛОНАСС (приоритет) и GPS.

MSK-IX NTP Server е реализиран като група от сървъри, разположени в Москва, Санкт Петербург, Екатеринбург и Новосибирск. Използването на мрежова технология anycast гарантира висока надеждност и бърза реакция на системата в цялата страна.

MSK-IX сървърите също са включени в международния пул от NTP сървъри POOL.NTP.ORG, широко използвани в настройките на операционната система.

Как да започна да използвам услугата NTP сървър?

Използвайте следните опции, когато конфигурирате хардуера си:

Как да настроя peering с мрежата на сървъра MSK-IX NTP?

За да съкратите мрежовия маршрут до MSK-IX NTP сървъра, използвайте услугата Route Server или установете директен пиринг с мрежата MSK-IX DNS Cloud. Peer-to-peer комуникацията се установява при допълнителна заявка по споразумението за свързване към MSK-IX без допълнително заплащане.

За целите на сравнението стойността на кода на слоя от нула се счита за по-висока от всяка друга стойност. Имайте предвид, че максималната целочислена стойност, кодирана като пакетна променлива, е ограничена от параметъра ntp .maxstratum.

Период на размяна (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll). Това е целочислена променлива със знак, която показва минималния интервал между предадените съобщения, измерен в секунди и представен като степен 2. Например, стойност 6 показва минимален интервал от 64 секунди.

точност (sys.precision, peer.precision, pkt.precision). Това е целочислена променлива със знак, представляваща точността на часовника в секунди и изразена като най-близката степен на 2. Стойността трябва да бъде закръглена до най-близката степен на 2, например 50 Hz (20 ms) или 60 Hz (16,67 ms) линейна честота) ще бъде присвоена стойност от -5 (31,25 ms), докато на кристална честота от 1000 Hz (1 ms) ще бъде присвоена стойност от -9 (1,95 ms).

Основна латентност (sys.rootdelay, peer.rootdelay, pkt.rootdelay). Този номер с фиксирана точкасъс знак, който показва размера на общото циклично закъснение (RTT) спрямо основната честотна референтна честота, изразено в секунди.

Основна дисперсия (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion). Този номер с фиксирана точкапо-голямо от нула, което показва максималната стойност на временната грешка спрямо основния стандарт в секунди.

Идентификатор на референтния часовник (sys.refid, peer.refid, pkt.refid). Това е 32-битов код, който идентифицира специфичен референтен часовник. В случай на слой 0 (неопределен) или слой 1 (първичен референтен източник), това е 4-октетов ASCII низ, подравнен вляво и допълнен с нули, ако е необходимо, например:

В случай на слой 2 и по-горе (вторична препратка), това е 4-октетният IP адрес на избрания за синхронизация партньор.

Референтна времева марка (sys.reftime, peer.reftime, pkt.reftime) - местно време във формат на времеви печати, съответстващи на момента на последната корекция на показанията на часовника. Ако локалният часовник не е синхронизиран, променливата съдържа нула.

Основно времеви печат(peer.org, pkt.org) - местно време във формат на времеви печат, съответстващ на момента, в който е изпратено последното NTP съобщение. Ако партньорът е недостижим, променливата се настройва на нула.

Печат за час на получаване(peer.rec, pkt.rec) - местно време във формат на времеви отпечатък, което съответства на момента на пристигане на последното NTP съобщение, получено от партньора. Ако партньорът е недостижим, променливата се настройва на нула.

Печат за време на предаване(peer.xmt, pkt.xmt) - местно време във формат на времеви печат, съответстващ на момента, в който е изпратено NTP съобщението.

Системни променливи

Следните променливи се използват от операционната система за синхронизиране на локалния часовник.

Променлива местен часовник(sys.clock) съдържа локалния часовник във формат на времеви отпечатък. Местното време се получава от хардуерния часовник на конкретен компютър и се увеличава дискретно с конструктивно определени стъпки.

Променлива Базов часовник(sys.peer) е селектор, който идентифицира източника на часовник, който да се използва. Това обикновено е указател към структура, съдържаща партньорски променливи. Стойност нула показва, че в момента няма източник на часовник.

Партньорски променливи

По-долу са изброени всички партньорски променливи, които се използват за контрол и прилагане на процедурите за измерване.

Конфигурационен бит(peer.config) - малко, показващо, че асоциацията е създадена въз основа на информация за конфигурацията и не трябва да се прекратява, когато партньорът стане недостъпен.

Актуализиране на времевата марка(peer.update) - местно време във формат на времеви отпечатък, отбелязващ момента, в който е получено последното NTP съобщение. Променливата се използва за изчисляване на дисперсията на изместването във времето.

Достъпен регистър(peer.reach) - смяна регистър ntp .window битове, използвани за определяне на състоянието на достъпност на партньора. Въвеждането на данни се извършва от страната на най-малките битове (вдясно). Партньорът се счита за достъпен, ако поне един бит от този регистър е 1.

Партньорски таймер(peer.timer) – Целочислен брояч, използван за контрол на интервала между последователно изпратени NTP съобщения. След задаване на стойността на брояча, съдържанието му намалява с 1 (1 секунда), докато достигне нула. Това се нарича процедура за прехвърляне. Имайте предвид, че работата на този таймер не трябва да зависи от местния часовник.

Пакетни променливи

Номер на версията(pkt.version) Цяло число, указващо номера на версията на подателя. NTP съобщенията винаги се изпращат с текущата стойност на версията ntp .version и ще бъдат приети само ако кодовете на версията съвпадат ( ntp .версия). Изключения са разрешени само при промяна на номера на версията.

Променливи на филтъра за часовник

Когато се използват филтри и алгоритми за избор, допълнително се включват следното променливи на състоянието.

Регистър на филтрите(peer.filter) - смяна регистър ntp каскади. shift, където всеки етап съхранява измерените стойности на закъснението, изместването и изчислените стойности на дисперсията, съответстващи на едно наблюдение. Тези три параметъра се въвеждат от страната на висок ред и се изместват към битовете от нисък ред (вдясно). Когато се получат нови резултати от наблюдение, старите резултати се губят.

Коректен брояч на данни(peer.valid) - Целочислен брояч, показващ валидни шаблони, оставащи във филтърния регистър. Използва се за определяне на състоянието на наличност и за контрол на увеличаването и намаляването на периода на изпращане.

пристрастие(peer.offset) - номер с фиксирана точкасъс знак, указващ стойността на изместването на часовника на партньора спрямо местния часовник в секунди.

Закъснение(peer.delay) - номер с фиксирана точкасъс знак, указващ общото циклично забавяне (RTT) на часовника на партньора спрямо локалния часовник, като се отчита времето за разпространение на съобщението и отговора в мрежата в секунди. Имайте предвид, че променливата може да приема както положителни, така и отрицателни стойности, в зависимост от точността на часовника и натрупаната грешка при изместване.

Дисперсия(връстник. дисперсия) - число с фиксирана точка, показваща максималната грешка на часовника на партньора спрямо локалния часовник, като се вземе предвид забавянето на мрежата в секунди. Разрешени са само стойности, по-големи от нула.

Настроики

Параметрите за всички реализации, работещи в Интернет, са описани по-долу. Необходимо е да се договорят стойностите на тези параметри, за да се премахне ненужното излишък и да се стабилизират партньорските асоциации. Посочените параметри са приложими за всички асоциации.

Номер на версията ( ntp .версия) - номер на текущата версия на NTP (3).

Порт NTP ( ntp .порт) е стандартният номер на порт (123), присвоен на NTP протокола.

Максимален брой слоеве ( ntp .maxstratum) е максималният номер на слоя, който може да се използва при кодиране на партидна променлива. Този параметър обикновено се тълкува като дефиниращ безкрайност (недостижим за протокола за маршрутизиране на подмрежата).

Максимална възраст за гледане ( ntp .maxage) - максималният интервал в секунди, през който референтният часовник ще се счита за правилен след последното съгласуване.

Максимален провал ( ntp .maxskew) е максималната грешка при изместване, свързана с повреда на локалния часовник по време на ntp .maxage, в секунди. Съотношението на ntp .maxskew към ntp .maxage се интерпретира като максимален отказ, причинен от всички фактори.

Максимално разстояние ( ntp .maxdistance) е максималното допустимо разстояние между партньорите при синхронизиране с помощта на алгоритъма за избор.

Минимален период за изпращане по пощата ( ntp .minpoll) - минималният период на изпращане, разрешен за всеки от партньорите в Интернет. Този период се изразява в секунди и е степен от 2.

Максимален период на изпращане ( ntp .maxpoll) - максималният период на изпращане, разрешен за всеки от партньорите в Интернет. Този период се изразява в секунди и е степен от 2.

Минимум избрани часове ( ntp .minclock) е минималният брой партньори, необходими за синхронизация (при използване на алгоритъма за избор).

Най-любими часове> ( ntp .maxclock) - максималният брой партньори, необходими за организиране на селекцията (при използване на алгоритъма за избор).

Минимална дисперсия ( ntp .умът се разсейва) - минималната стойност на увеличението на дисперсията за всеки от слоевете в секунди (при използване на алгоритъма за филтриране).

Максимална дисперсия ( ntp .maxdisperse) - максимална дисперсия в секунди, като се вземат предвид загубените данни (при използване на алгоритъма за филтриране).

Размер на регистъра за наличност ( ntp .прозорец) - размер на регистъра за достъпност (peer.reach) в битове.

Размер на филтъра ( ntp .shift) - размерът смяна регистърфилтър часовник (peer.filter) в каскади.

Тегло на филтъра ( ntp .filter) - и излъчване:

Симетрично активен (1)... Компютър, работещ в този режим, периодично изпраща съобщения, независимо от достъпността или слоя на своя партньор. При работа в този режим компютърът обявява намерението си да се синхронизира и да бъде синхронизиран от партньор.

Симетрично пасивно (2)... Този тип асоциация първоначално се създава при пристигането на съобщение от симетрично активен партньор. Той продължава, докато партньорът е достъпен и функционира в слой под или равен на дадения компютър. В противен случай асоциацията се разпада. Асоциацията обаче ще съществува, докато не бъде изпратено поне едно съобщение като отговор. При работа в този режим компютърът обявява намерението си да се синхронизира и да бъде синхронизиран от партньор.

Компютър, работещ в клиентски режим, понякога изпраща NTP съобщение до компютър, работещ в сървърен режим, например веднага след рестартиране и периодично след това. Сървърът отговаря чрез промяна на адреси и номера на портове, попълване на необходимата информация и изпращане на съобщение обратно до клиента. Сървърите не трябва да съхраняват информация за състоянието между клиентските заявки, докато клиентите могат да променят интервала между NTP съобщенията, за да отговарят на местните изисквания. В тези режими механизмът на протокола, описан в тази статия, може да бъде значително опростен без забележима загуба на точност или надеждност, особено при работа във високоскоростна локална мрежа.

В симетричните режими разликата между клиента и сървъра практически изчезва. Симетрично пасивен режим е предназначен за използване от временни сървъри, работещи в близост до базовите възли (долния слой) на синхронизиращата подмрежа и с относително голям брой партньори. В този режим не се изисква предварително идентифициране на партньор, тъй като асоциацията с неговите променливи на състоянието се създава само когато се получи NTP съобщение. Освен това запомненото състояние може да се използва по-късно, когато партньорът стане недостижим или работи на по-високо ниво и поради тази причина ще бъде неподходящ като източник на синхронизация.

Симетрично активният режим е предназначен за използване от времеви сървъри, работещи близо до крайни възли (най-високи асоциационният слой, ако е съществувал, ще бъде елиминиран поради недостижим партньор.

Режимът на излъчване е проектиран да работи във високоскоростни локални мрежи с голям брой работни станции, където не се изисква висока точност. В типичен сценарий един или повече временни LAN сървъри периодично изпращат излъчвани съобщения до работни станции, които след това определят времето въз основа на предварително определено закъснение на разпространение от порядъка на няколко милисекунди.

Обработка на събития

От гледна точка на протокола NTP, значителни събития възникват, когато изтичат таймерите на партньора (peer. Timer), един от които е специално насочен към този партньор в активна асоциация, както и когато се получи NTP съобщение от различни партньори . Събитието може да възникне в резултат на команда на оператор или открита грешка, като отказ на първичен стандарт.