Комментарии 440
Еее, дело раскрыто. Спасибо, что отписались.
Ну такое. Что-то мне подсказывает, что в воскресенье вечером кто-то из Яндекса, лениво листая комментарии, нашел штук 10 отсылок, решил посмотреть в код, обалдел и быстро на изоленту все примотали :)
Может и так, но кто в этом признается? Главное, что публично сказали "мы накосячили, исправляемся".
Сложно назвать это косяком. Есть сервис, они его использовали. Я бы не сказал что запросы раз в 5 секунд, причем только в случае сбоя обращения к основному серверу, - это что-то прямо нечто. Никто же не оценивал нагрузочную способность вторичных стратум-серверов.
По идее, гарантированность доступности таких вещей вообще должно не сообщество обеспечивать, а это задача государственного и/или корпоративного значения. Яндекс вот правильные выводы сделал)
Я бы не сказал что запросы раз в 5 секунд, причем только в случае сбоя обращения к основному серверу, - это что-то прямо нечто.
А я бы сказал, что это фееричный косяк проектирования, который оправдать можно только в одном случае - если человек, который это писал, вообще не предполагал, что этот код может пойти в прод, а не останется в лабораторных условиях.
Так-то подобная времянка и в лабораторных условиях непонятно зачем нужна. Если только для тестов и отладки. Но устройств и интернете всё равно на порядки больше, чем колонок. И случайно созданный колоночный ботнет, появившийся в результате этого такого кода, выявил узкое место в инфраструктуре синхронизации, часть которой получается держится по сути на энтузиастах.
Запросы раз в пять секунд от десятков (сотен?) тысяч этих станций к stratum 2,3 серверам энтузиастов, собранным из г.на и палок запущенным на роутерах и домашних каналах. Ага-ага.
Есть сервис, они его использовали.
Сервис есть. И правила его использования есть. Сервис использовали, на правила положили.
Хотел расширить вышепрозвучавший тезис от @nevzorofff- в правилах чётко сказано:
не выкидывайте грязных трюков с параметрами burst и minpoll — все, чего вы добьетесь, это гибель нашего проекта, раньше или позже
а интервал опроса в 5 секунд - это явный "грязный трюк с minpool", так что всё-таки "косяк".
Вчера в netflow логах ещё видел сотни пользователей, генерирующих запросы к ntp каждые 5 сек. Сегодня их уже не осталось. Похоже что да, апдейт докатился до всех. УРА! Нагрузка на пул стабилизировалась, это вижу и сам, об этом в телеге мне отписался администратор ещё одного сервера :)
Остались вопросы:
Я.девайсы примерно каждые 20-30 сек ресолвили DNS-записи [0-5].ru.pool.ntp.org (я видел это своими глазами) + люди писали что колонка периодически запрашивает SOA зоны. Зачем ей это? Может тоже баг?
В твоём топике на хабре также были озвучены предложения к Яндексу:
выделить сервера для общего пула
зарегистрировать в пуле свою vendor-зону для своих дейвайсов (см https://www.ntppool.org/ru/vendors.html). Хотя тут есть и плюсы и минусы. Без зоны есть плюс в том что трафик запросов ходит до ближайших серверов (иногда это будет сервер прямо у провайдера) а не в интернеты на сервера Яндекса.
Вопросы по пулу и трафику в целом:
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp. Это спуфинг или ковровые блокировки ntp-протокола? По идее блокировки делались бы drop'ом без отправки icmp.
Вендор-зона требует от коммерческих компаний отчислений пулу - а с этим из РФ, как понимаете, есть некоторые проблемы.
Про SOA записи, возможно клиенты пытаются получить AAAA для IPv6, а ее нет.
Отчего так много icmp port unreachable? Это спуфинг или ковровые блокировки ntp-протокола?
Судя по высокому объёму подобного трафика, это всё-таки результат спуфинга — для DRDoS-атаки на чью-то инфраструктуру. Никакого отношения к умным колонкам не имеет, если только они не взломаны и не являются частью ботнета, генерирующего фейковые запросы от имени чужого IP-адреса.
Про icmp:
Допустим, как вариант, ваш сервер отправляет ответный пакет на ip и порт вопрошающего клиента. Если у клиента истёк тайм-аут ожидания ответа на запрос, то порт закрывается. Пакет на закрытый порт заставит уст-во клиента отправить "icmp port unreachable" в вашу сторону.
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp
Сейчас наблюдаю у себя, что 47% ответов моего ntp-сервера приводят к icmp port unreachable. На спуфинг не особо похоже, вряд ли спуферы стали бы с такой дотошностью имитировать поведение клиента. Так что, скорее "ковровые блокировки ntp-протокола". Когда станции DDoSили, могли на скорую руку, например, наконфигурировать statefull NAT таким образом, что сейчас он просто не знает куда кидать ответ и кидает его кому попало, а тот честно говорит - это не мое (icmp port unreachable)
Читал тот пост, о котором речь. Было интересно, но малопонятно. Но с этим постом стало ясно, почему моя станция лайт выкачала за 4 часа 5,26 гигабайт трафика, в конце октября.
Тайна стиральной машины раскрыта! =)
Мне больше интересно - из месяца с небольшим, который ушел на разбирательства, сколько времени потребовалось на осознание проблемы (фактически - достучаться до кого-то понимающего, что произошло), и сколько на решение.
Добавим второй вопрос, из-за чего не договорились об собсвенном пуле, как у убунты есть свой ubuntu.pool.ntp.org
Третий вопрос, из-за чего не поставили свои NTP сервера? Тогда бы сейчас не было это-го поста и не было кучи вопросов. А так фактически устроенный DDOS на чужую инфру.
Задним числом все умные, но в реальной жизни никто не будет думать о выделении отдельных серверов времени под экспериментальную железку и никто не будет думать о синхронизации времени как о дорогой операции которая может положить сервера.
Это классический щит хэппенс за который тебя будут упрекать люди которые сами сделали бы точно такую же ошибку, но обладая послезнанием считают что всё очевидно и надевают на себя белый фрак.
Где она экспериментальная? Заполонила уже всю Россию.
Не согласен насчёт "никто".
В фирме, занимающейся разработкой промышленной продукции, должен быть отдел метрологии, и он в данном случае плохо выполнил свою работу. Синхронизация времени – недорогая операция, но правильный порядок её выполнения, как и всякого другого измерения, регламентирован федеральным законодательством. Если бы Яндекс правильно выполнял измерение времени, то он не пользовался бы для этого анонимными часами, и до падения общественного пула дело бы не дошло, а Яндекс бы гораздо раньше положил сервер той или иной уполномоченной организации и получил бы от неё по голове, о чём широкие пользователи не узнали бы. Притом, что, как написано в статье, синхронизация времени критически важна для Яндекса, выполнять её абы как – некрасиво.
Я, может, испорчен некоторым профессиональным опытом в этой области, но для меня ваш довод звучит примерно как "кто ж знал, что бензин нельзя разбавлять ослиной мочой". Вот именно этим инженер и отличается от выпускника курсов "Питон за 48 часов". Он должен понимать, что наводнение страны миллионом синхронизирующихся друг с другом коробочек образует новое качество системы.
А Яндексу надо бы задуматься не просто о серверах NTP, а о поддержании у себя вторичных эталонов времени на базе атомных часов. Это на самом деле недорого в таких масштабах, но нужно для выполнения тех функциональных задач, на которые он претендует. Фирма, в которой я работаю, намного меньше Яндекса, но поддерживает собственные атомные эталоны.
Яндекс, у вас есть главный метролог? Он согласовывал ТУ на колонку, имеющую функцию часов?
Но зачем? Зачем для Яндекс-станций отдел метрологии? Вы ещё предложите их на поверку регулярно носить...
Яндекс-станциям не требуется юридически значимое время. Им даже не требуется точное время. Им требуется чтобы их часы не сильно расходились друг с другом (для взаимодействия друг с другом), и хотя бы примерно соответствовали общемировому времени (для работы TLS и всяких будильников).
Использование NTP пула более чем удовлетворяет этим требованиям, нужно было лишь соблюдать правила самого пула.
А Яндексу надо бы задуматься не просто о серверах NTP, а о поддержании у себя вторичных эталонов времени на базе атомных часов.
Не нужно. Вот если ставить у себя атомные часы - то отдел метрологии и правда может потребоваться. А поднять сервер NTP и включить его в пул может любой админ, и это будет вполне рабочим решением.
А поднять сервер NTP и включить его в пул может любой админ, и это будет вполне рабочим решением.
... до тех пор, пока не выяснится, что оказание услуг российским гражданам в виде предоставления времени является предметом санкций правительства США. Уж гораздо более логичная цепочка будет, чем с приёмом коммитов в ядро Linux.
Я уж даже не вспоминаю о том, что вендоры, использующие в своих продуктах ntp.org, вроде как должны платить за это деньги администрации ntp.org.
Учитывая, что услуги предоставляются энтузиастами и безвозмездно, а пул лишь балансирует нагрузку - любые санкции тут будут выглядеть как "назло маме отморожу уши". Но да, политики и правда могут так поступить, особенно когда уши чужие.
Однако, даже если и правда случатся NTP-санкции, держать свой NTP сервер всё ещё проще чем свой отдел метрологии.
Так этот свой сервер всё равно должен где-то брать время предыдущего стратума.
Так у того же пула можно взять время. Пул может отказать в регистрации префикса из-за санкций - но не может ничего поделать с обращением по общему адресу, который pool.ntp.org (потому я и сравниваю ситуацию с отмороженными на зло маме ушами), или с прямым указанием IP адреса.
Да, такое решение поддерживать сложнее чем вендорный префикс, но ничего невозможного.
Ну и всегда можно взять время у тех самых "уполномоченных организаций".
Теоретически ничто не мешает заблокировать pool.ntp.org для запросов с российских ip, по примеру intel.com и других.
Ещё как мешает. У интела свои сервера, и блокировка сделана на стороне серверов. А у pool.ntp.org все сервера - волонтёрские, и управляются они вовсе не пулом.
Единственное что может сделать пул - подкрутить свой geo-dns чтобы запросы из России не резолвились. Однако, обходится такая блокировка настолько просто, что даже не все российские пользователи её заметят. И уж точно она не станет проблемой для опытного админа.
Эту всю историю про волонтёрские серверы мы уже прошли с одним обиженным финном. Оказывается, когда надо, они волонтёрские, а когда надо - это американское юрлицо.
Обиженный финн может сколько угодно настраивать блокировки на своём сервере, но до тех пор, пока так не поступят более половины владельцев серверов - результаты их стараний никто не заметит.
И нет, все волонтёры сразу вот никак не могут оказаться американским юрлицом. Хотя бы потому что многие из них вообще не в Америке.
Если вы не согласитесь с условиями использования ntp.org, на ваш сервер просто не будут форвардить запросы из пула. Т.е. работать-то вы сможете, но в зону DNS ntp.org входить не будете.
Вы имеете в виду, что пул может начать давить на волонтёров, чтобы они блокировали запросы из России на уровне файервола?
Что-то мне подсказывает, что большинство владельцев серверов либо забьют на эти указания, либо со словами "ну, раз не хотите - значит, и не надо" сами выведут сервер из пула.
Ну и вообще даже интересно как эти условия будут проверяться. Пулу же для этого понадобится монитор в России, а сервер для него приобрести не получится из-за тех же санкций...
вчера тоже про это думал. Ask Bjørn Hansen (админ/вледелец пула) по-моему живёт в США.
В связи с инцидентом и самизнаетечем, Яндекс может родить аналогичный проект национального масштаба. Правда смысла в этом немного, если только у операторов потом сделать pool.ntp.org CNAME pool.ntp.рф но хайджекинг записей это невесело
Яндекс не может поднять S1 и брать время с GNSS?
P.S. Такое наверное даже с могу себе позволить
Не удивлюсь если это не просто.
GNSS-приемник в датацентре - чуть сложнее чем дома.
А еще - как минимум в Москве и Питере - есть блуждающие пространственно-временные аномалии (обычно создающие телепорты в ближайший аэропорт) и это тоже придется учитывать.
GNSS-приемник в датацентре - чуть сложнее чем дома.
Масштабы Яндекса и меня в финансовых и технических ресурсов тоже несопоставимы
Но да, я допускаю что в ДЦ это может быть несколько сложнее
Профессиональный приёмник времени все эти тонкости учитывает и не берёт в обработку время, если волшебным образом перенёсся куда-то.
В описании Сервер точного времени Метроном-PTP-1U есть "Антенна ГЛОНАСС/GPS 40дБ (кабель до 150м)", что должно хватить на любую конфигурацию датацентра.
попробуйте согласовать "нарушение электромагнитной целостности машинного зала" - потом прокладку кабеля по трассам ДЦ и вывод Внешнего антенно-фидерного устройства....
Удивительно сколь много нового узнают Люди о том что это оказывается очень зарегулированная и очень даже непростая Область пресечения интересов ФСБ, ФАПСИ и еще нескольких многобуквенных организаций.... и Метрология и ГОСТы и приказы ФСБ, ФСТЭК и еще нескольких столь же милых Абревиатурных контор для вас станут настольными документами на ДЛИТЕЛЬНЫЙ и зело болезненный период времени...
Молчу про ситуацию когда в ЦОДе присутствует соответствие 152ФЗ.... а если там еще и "....вплоть до 1-го класса включительно...." - тут уже проще ЦОД сменить....
Однако - опыт, грабли....
Сервер времени с приемником может находиться вне ЦОД.
"При наличии желания есть тысяча возможностей, при отсутствии желания есть тысяча причин."
Не пугайте, пожалуйста, 152ФЗ - под него любой сервер 1С:Бухгалтерия/1С:ЗУП попадают, и ничего - видел, как стойка с парой серверов стоит в общем (на несколько фирмочек) тамбуре, практически на лестнице, так как "шумит сильно".
конечно - до первой реально проверки или утечки все забивают.... вон счас штрафы в ~1000 раз подняли посмотрим как дёргаться будут...
и да 1c: ЗУП это в пределе 3-ий класс, ну в самом максимуме второй.... хоть и непонятно нафига такой геморрой работодателю...
когда у цода и/или Маш. залов всё сделано под 152-ой фз - никто вам не даст ничего менять в составе, т.к. это опять деньги на замеры, согласования документы итп итд..... тем более ставить столь "чувствительные" штуки как антенно-фидерные устройства.... там одно согласование и сертификация для контроля ПЭМИН - это геморрой на полгодика... особенно если железка не дай-то бог хоть чуть-чуть импортная, а ИС в машзале проходит как часть КИИ.....
по-моему аппаратный сервер типа Meinberg'а стоит условно 100-300тыр (сейчас может и миллион, но есть наши аналоги), он умеет в GNSS (спутники) и содержит TCXO/OCXO который способен продолжительное время поддерживать точный ход, даже если спутники пропали или выдают чушь. Ну в конце концов цезиевые/рубидиевые источники можно купить у того-же ВНИИФТРИ.
Ставим N штук в кластер, на них завязываем уже машины с ntpd/chrony способные держать гигабиты трафика. Поехали.
Я когда отлаживал приложение-трекер, встречал и телепорт в какой-то населённый пункт в юго-восточной Азии - оказалось, некоторые китайские глушилки (уж не знаю, кто ими пользуется, но пользуется явно не один человек, т.к. на автобазе, где я занимался отладкой, полёты к побережью Жёлтого моря случались регулярно) забивают эфир на сотни метров.
О том и речь.
С GPS/ГЛОНАСС можно получить время Stratum1 без проблем.
Вопрос, кстати. по поводу этого:
Вычисления координат сравнительно сложные, требуют хорошего сигнала итд итп. Поэтому чип сравнительно дорогой.
1) А бывают чипы, которые всего этого не считают, а просто тупо выдают наружу то время, что услышали ну с миллисекундной точностью. Для бытовых нужд - вроде бы как вполне достаточно.
Чип дешевле не получится?
2) GPS, как я понимаю, не единственный радиосигнал, что время дает. Альтернативы - аналогично - не дешевле будут?
Если для личных целей, то модули с погрешностью привязки с микросекундной точностью обойдутся по цене одного похода в магазин за продуктами или ещё дешевле если будет только GPS, без ГЛОНАСС и BeiDou. Точно не скажу, покупал года три назад.
Если для целей метрологии, то цены совершенно другие, но и точности на порядки выше.
В серьезных местах ставят рубидиевые или водородные стандарты частоты.
Например, водородный стандарт Ч1-1007 синхронизируется с UTC(SU) с погрешностью не более 50 нс (0,000 000 05 с), а также может подстраиваться автоматически. За год автономного хранения, т.е. без синхронизации, уход его шкалы в худшем случае составит 16 мкс (0,000 016 с). ССхтоит как два китайских автомобиля. Антенна, приемник и кабель 5 в комплекте. Задержка в кабеле также учитывается.
Остальные варианты, в основном, между этими двумя
Если для личных целей, то модули с погрешностью привязки с микросекундной точностью обойдутся по цене одного похода в магазин за продуктами или ещё дешевле если будет только GPS, без ГЛОНАСС и BeiDou.
Не, все равно дорого. Вопрос (праздный, впрочем) о том, что такого можно впаять в дешевые но слишком умные часы (они же - очередная умная колонка) так, чтобы их вообще можно было не подводить. Ни по NTP, ни каким-нибудь другим способом.
так, чтобы их вообще можно было не подводить. Ни по NTP, ни каким-нибудь другим способом.
Зависит от того, какая точность вам нужна. Технически, если вас устраивает погрешность в несколько секунд достаточно обычного кварца и возможности установить время вручную. А вот если вам нужно точнее, и еще чтобы не устанавливать время в ручную, то такого, чтобы работало прямо везде, включая подвалы без окон, где не принять никакой радиосигнал -- ничего не впаяешь.
Вопрос (праздный, впрочем) о том, что такого можно впаять в дешевые но слишком умные часы (они же - очередная умная колонка) так, чтобы их вообще можно было не подводить. Ни по NTP, ни каким-нибудь другим способом/
Любой потребительский GPS-ресивер. Они все умеют получать "условно точное время".
зачем яндексу для потенциального сервера NTP точность выше миллисекунды?) там сетевые пинги больше будут, да и для Алисы точность даже в несколько секунд будет вполне приемлемой
Радиостанция RWM? её вроде не забанили и санкциям не подвергли
Было бы неплохо, но как-то немного информации нашёл по ней и совсем не нашёл устройства для приёма сигнала и подключения к серверу.
Или хотя бы ПО, которое можно установить на сервер и к звуковой карте подключить КВ-приёмник.
Есть отечественные аналоги: РБУ и РТЗ. Хотя, может уже и нет - их до 2024 обещали ликвидировать зачем-то
Это как с Курском. Ликвидировали СВ/ДВ вещание и оказалось что в условиях ЧС оповещать население нечем. И вообще вести иновещание на сопредельное государство.
Правда в 2021 году Росстандарт был против:
Росстандарт выступил против планируемой ликвидации радиостанции, транслирующих сигналы точного времени. Сейчас такие радиостанции находятся в ведении РТРС. К 2024 г. их планируется отключить, хотя их сигналы, в числе прочего, используются для обеспечения безопасности и обороноспособности страны.
Нужны ж и приемники СВ/ДВ.
Я вот вообще не очень понимаю почему нельзя встроенную в мобилки систему которая в США для оповещения используется задействовать в России? Там какая то особая авторизация и любой оператор сотовой связи к которому мобилка подключена - не может ее использовать? Хорошо ну а хотя бы cell broadcast? Ладно если это сложно - активно рекламировать установку приложения МЧС + договорится с ВК и Яндексом чтобы показывали баннер по геотаргетингу (причем НЕ как рекламу, именно отдельного формата чтобы его случайно адблок не накрыл)
ЧС - это электричества нет, мобильных станций нет, ФМ радио не работает. Вот наваливает паника, которая наносит больше ущерба чем само ЧС.
Если бы было СВ/ДВ, то приступов паники не было. Люди бы знали куда эвакуироваться.
СВ приёмник есть практически в каждом автомобиле, в портативных приёмниках этот диапазон также почти всегда есть.
Китайцы выпускают хорошие и доступные всеволновые приёмники (в некоторых даже есть ДВ, но без доработок они почти ничего на ДВ не принимают).
Но "умные" люди посчитали, что ДВ/СВ/КВ вещание - слишком дорого и никому не нужно, вещание прекратили а антенны попилили.
Да кто его слушает?
И в чём сложность в телеэфир пустить оповещение? Всё же на цифре и под одним вещателем по всей стране.
Какой телеэфир ,если передающая станция уничтожена?
Радиус действия современного телепередатчика цифрового ТВ около 20 км.
Какой телеэфир ,если передающая станция уничтожена?
У нас в области 42 района и 103 передатчика. Все 103 уничтожили?
Во многих местах ловятся по два из них.
И сколько ловилось в Судже?
После объявления ЧП с местной вышки ещё неделю ловилось, т.е. один минимум. именно столько времени потребовалось ВСУ, чтобы дойди до центра Суджи.
Я ещё так прикинул — родители АМ приём, наверняка включить не смогут, у тёщи даже машины нет. Жена хз, проверю, но, тоже, думаю, не сможет )
Толку от оповещения на СВ - минимум.
Проработали т.к. не было цели гасить электроподстанции - можно было повлиять на работу газопровода, вокруг денег которого и крутятся эти события.
Погасло быстро электричество как в Крымске, в Крыму или при наводнение на Урале в этом году и никаких работающих станций в округе нет.
Люди живут при ЧС в авто - в каждом авто есть телевизор чтобы получить сообщения?
Карманный АМ/ФМ радиоприемник вполне может найтись. В автомобиле он всегда в штатной магнитоле.
Наконец на дорогах РФ чуть в сторону Урала начинаются зоны неуверенного приема или вообще отсутствие. СВ и КВ в РФ нет. Только Иран, Китай в эфире.
В автомобиле он всегда в штатной магнитоле.
Включить АМ смогут, дай бог, процентов 10
Карманный АМ/ФМ радиоприемник вполне может найтись.
Может найтись, а может и нет. У к компу подключен ресивер, там есть приёмник, а рамочная антенна для АМ попадалась летом или на балконе, или в гараже, и в случае ЧС я её точно искать не буду.
Люди живут при ЧС в авто - в каждом авто есть телевизор чтобы получить сообщения?
Люди не живут в машинах в мирное время, а начинают там жить после того, как узнали о ЧС.
Сигналы точного времени регулярно слышу на 10000кГц и 15000кГц, приём хороший.
Вроде передатчик в Новосибирской области, RTA
Чип дешевле не получится?
Вряд ли, так как надо будет отбить отдельный дизайн и производство этих узконаправленных и мало востребованных чипов, при том, что далеко не факт, что вычисление координат занимает какой-то ощутимый транзисторный бюджет по сравнению с обработкой сигнала необходимой для его приема.
узконаправленных и мало востребованных чипов
Почему, кстати, невостребованных? Нормальных стационарных, не умных, не подключенных ни к каким сетям электронных часов - еще достаточно много выпускаются. В них такой тоже можно ставить.
Если такие часы поставить в спальню или повесить на стенку внутри дома, спутниковый приемник точного времени ловить не будет. Вряд ли такую ограниченную фичу удастся продать. К тому же для этих целей уже существуют модули, принимающие сигналы точного времени от наземных радиостанций. Стоят 170 рублей на Али, в часах стоили бы еще дешевле, но особо их в бытовые часы не ставят.
ринимающие сигналы точного времени от наземных радиостанций.
Во... стоимость чипа, что именно оно ловит и почему бы в условную колонку не поставить чтобы с NTP не связываться? Там у меня в вопросе второй пункт про это был.
и почему бы в условную колонку не поставить чтобы с NTP не связываться?
Колонка в любом случае работает от сети, поэтому ставить туда отдельный приемник, пусть даже за 100 рублей посчитали излишним, ведь в сети есть NTP. То что кто-то может накосячить и положить почти всю инфраструктуру просто не учли, да и косяк максимально на ровном месте, такие часто недооценивают.
GPS/GNSS?
В том числе. Но спутниковое вещание тоже запросто могут отключить, на более или менее продолжительное время, поэтому к приёмнику всё равно нужны автономные часы.
Но спутниковое вещание тоже запросто могут отключить
Его нельзя запросто отключить, а ведь кроме gps, есть и другие gnss, тот же ГЛОНАСС. Тем более что сейчас чистый gps-модуль днем с огнем не сыщешь, все они за сравнительно небольшую цену умеют несколько систем gnss.
Относительно просто его спуфить локально, но это совсем другая проблема, чем отключение gps с той стороны
Я как раз имел в виду спуфинг.
Разницы-то нет, с какой стороны дёрнуть рубильник.
Бей своих, чтобы чужие боялись? Прекрасно
Достаточно потенциальной возможности обстрела (что актуально для любого крупного датацентра) и, как следствие, работы РЭБ.
При таком развитии событий очевидно что не до колонки с Алисой будет дело, там скорее всего ЦОДы будут уже в труху либо страдать от энергетических отключений, либо переориентированы под иные нужды, а без ответной серверной части колонка от Яндекса бесполезна.
Так одно давно уже тогось, развилось. Сейчас по России по официальной статистике МО РФ прилетает несколько десятков БПЛА самолётного типа в сутки, в основном они сбиваются объектовыми ПВО и РЭБ. Поэтому в промзонах в основном сейчас ГНСС не работают. Думаю, что и ЦОДы Яндекса являются одними из фактических целей, и сами по себе, и как часть инфраструктуры, где они стоят.
Так что уже прямо сейчас есть такие большие зоны, где никогда или время от времени нет спутниковой навигации.
Более интересно что будет если будут санкции Российского правительства за предоставлению времени гражданам недружественных стран. У кучи серверов(особенно ру-сегмента) ж российские администраторы.
С учетом как обычно Роскомнадзор работает....
Представляю диалоги с улиц будущего за океаном:
- Вы время не подскажите?
- Паспорт покажите пожалуйста, а то у вас такой акцент, как бы санкции не нарушить
Им даже не требуется точное время. Им требуется чтобы их часы не сильно расходились друг с другом (для взаимодействия друг с другом)
На такой случай можно сделать локальную синхронизацию колонок.
UPD: уже предложили.
Вы выссказываете очень правильные аргументы. Для ситуации завода и промышленного производства.
Но интернет изначально, в своём фундаменте строился на несколько (или существенно :) более анархических принципах. И использование в продакшн КАКОЙ-ТО чужой инфраструктуры и каких-то опен-соурс компонентов - это де-факто общепринятая практика. Это несколько понижает надёжность системы, но критически улучшает параметр time-to-market (время вывода на рынок нового изделия).
Когда заказчик один - государство и он согласен подождать лет 10 готового изделия (и оплачивать все эти 10 лет работы коллективов разработчиков) - то да, надо каждую мелочь продумывать и свою службу метрологии содержать.
А в этих ваших интернетах - либо надо БЫСТРО запустить продажи своей идеи, либо она уже будет не особо кому-либо нужна. Ибо все уже у конкурентов купят. (См историю про Вася и Петю).
И просто дешевле иногда устранять последствия провалов.
Яндекс готов на себя взять устранение всех возможных последствий провалов при использовании своих изделий? Сомневаюсь. И в возможных будущих судебных процессах этот аргумент про time-to-market будет выглядеть бледно.
Всё таки у дедушки Ляо и у компании, претендующей на место где-то около государственной монополии в IT, и на уровне федерального законодательства пропихивающей обязательную установку своих поделий на вычислительную технику, должен быть разный подход к организации работ.
Вы как будто не в России живёте. Какие нафиг судебные процессы?
Вот если бы Яндекс-станции положили не общедоступный пул, а сервера "той или иной уполномоченной организации", как вы предлагали ранее - могли бы и судебные процессы возникнуть. А сейчас-то кто и на кого в суд подаст?
Яндекс готов на себя взять устранение всех возможных последствий провалов
Я же говорю - на более анархичных принципах :)
Если кто-то считает, что эти провалы нанесли лично ему материальный (или моральный) ущерб и готов доказать свою позицию в суде - то он в рамках частного обвинения обращается в суд.
А юристы компании-разработчика - финансово оценивают риски такого развития событий.
А в этих ваших интернетах - либо надо БЫСТРО запустить продажи своей идеи, либо она уже будет не особо кому-либо нужна. Ибо все уже у конкурентов купят. (См историю про Вася и Петю).
В этих наших интернетах есть готовый ntp клиент (аж целых 3 по-моему). Который правильно написан и не создаёт нагрузку. Но Yandex, почему-то, написал свой.
Уточнение: Яндекс написал не NTP-клиента, а SNTP-клиента — примитивную state-less опрашивалку сервера без самостоятельного вычисления коррекции хода часов (позволяющего ограничиваться 4 запросами в час для поддержания миллисекундной точности, или даже 1 запроса раз в несколько часов при менее высоких требованиях к точности).
Пардон, но Интернет изначально строился как раз не на таких принципах, а людьми ответственными. Коммерциализацию и time-to-market в него начали тащить с начала 90-х - и всё и покатилось по наклонной.
Ничего, скоро за вот эти "у конкурентов быстрее купят" стрелять начнут.
Метролог нужен только если бы они действительно использовали собственные эталоны. В чём нет необходимости, потому что колонке не нужна такая точность. Тут другая ситуация. Колонка была по сути экспериментальным продуктом, поэтому использовали ntp пул чтобы сократить расходы на инфраструктуру и разработку. И почему не переехали на собственную инфраструктуру, когда проект оказался успешным — вопрос хороший.
так в статье же и ответ: потому что забыли, ибо работало хорошо и не отсвечивало
Это понятно, золотое правило "работает — не трогай". Просто когда используется открытая инфраструктура — это дополнительная точка отказа. Если используется своя, можно сбалансировать нагрузку, выделить сервера, чтобы было время решить проблему. Тут же всё пришлось делать сообществу пока Яндекс не выкатил хотфикс.
Яндекс, респект что не стали молчать и довольно оперативно всё порешали.
Добавлю. Тоже работаю в фирме, намного, намного меньше Яндекса, которая делает ответственные вещи для жд и метро с огромными показателями надёжности и безопасности (занимаюсь только ПО). И тут вопрос, а вы готовы тратить время и деньги на разработку такого прибора с учётом, что затраты на обеспечение надёжности идут по экспоненте. И сколько по итогу он будет стоить. Или же вы предпочтёте сначала проверить, выстрелит этот продукт или нет, возможно откусить кусочек рынка, а потом уже допиливать. И готовы ли вы, как потребитель, переплачивать за супер надёжный продукт, но который стоит как крыло самолёта.
Ну и скажу вещь, которая некоторым может показаться отвратительной, но которая есть в любом учебнике по функциональной безопасности. Если затраты на покрытие возможного ущерба за время эксплуатации прибора меньше, чем затраты на обеспечение этого уровня безопасности, нет необходимости его реализовывать :)
Яндекс.Станция это бытовой прибор вроде чайника, а не АСУТП сталелитейного завода. Какие метрологи, о чём вы?
Яндекс, у вас есть главный метролог? Он согласовывал ТУ на колонку, имеющую функцию часов?
А на неё вообще ТУ имеются ?
На мой взгляд все эти поделки a-la "яндекс колонка" - чистый самопал сделанный на аутсуорсе за три дня и три копейки.
Я протестую, не нужно заднее число чтобы понять что алгоритм "долбимся раз в минуту, а если не получилось, то каждые 5 секунд" - полная дичь. Где exponential backoff?
так это он и есть xD, просто основание экспоненты < 1
Зашёл сюда написать этот комментарий, а он уже написан :D
Я где-то слышал, что в Яндексе работают только лучшие их лучших, и собес у них без знания всех четырех томов Кнута не пройти. ;)
Так Кнут вообще не про то
Что не мешает Яндексу периодически бить рекорды по оподливливанию. То у них данные миллионов клиентов утекут, то их научатся кидать на их Станции каким-то непроходимо тупым способом, то теперь вот сами ботнет сделали...
Наглядная иллюстрация, что все сложные собесы никак от идиотизма не защищают.
Прочтения https://www.ntppool.org/ru/vendors.html хватило бы для того, чтобы быть умным до, а не после. Этому же помогло бы изучение алгоритмов ntpd и chrony с попыткой, почему сделано так, а не иначе. Тем более, что относительно недавний баг в systemd-timesyncd как бы намекает, что можно легко облажаться.
Ну, тут пул тоже отчасти виноват. То, что правила пользования пулом pool.ntp.org следует искать на сайте ntppool.org - вот вообще неочевидно, и найти эту информацию на том же ntp.org не так-то просто.
Скажу больше, правила искать надо не на pool.ntp.org, а на www.pool.ntp.org, потому что pool.ntp.org разрешается в рандомный ntp сервер и браузером не откроется в большинстве случаев, или же откроет какой-нибудь рандомный сайт, на котором запущен NTP-сервер и включен в пул.
Отчасти поэтому ntppool.org и появился, потому что WWW вбивать в адресную строку моветон уже лет 10 как
«Никто», ага. Не надо нормализовывать некачественное отношение к работе.
но в реальной жизни никто не будет думать о выделении отдельных серверов времени под экспериментальную железку
Зато вместо использования готового клиента, строить свой высокотехнологичный велосипед - это пожалуйста =)
Каким задним? Не надо оправдывать рукожопов, которые ни правил использования сервисов не читали, и на чужих ошибках не учатся:
Есть раздел для вендоров, там чтива на пару-тройку минут и для самых упёртых уже есть упоминания подобных инцедентов:
A couple of examples in the past years are Flawed Routers Flood University of Wisconsin Internet Time Server in 2003 and the D-Link misconfiguration incident in 2006.
В 2018 году была статья на Хабре - Интернет убыточных вещей, про то что очень плохо использовать чужой NTP сервер для собственных умных вещей.
Похоже, что в Яндексе эту статью не читали.
Вводный фрагмент этой статьи
Почти два года назад, в понедельник 16 января 2017 года, в нашу систему баг-репортов BitFolk поступил интересный тикет от постороннего лица. Отправитель представился как ведущий инженер-программист компании NetThings UK Ltd.
Тема: запрос NTP на IP 85.119.80.232
Привет,
Это может показаться странным, но мне нужно настроить сервер NTP по IP-адресу 85.119.80.232.
Что такого особенного в адресе 85.119.80.232? Это IP-адрес одного из NTP-серверов для обслуживания наших клиентов. За несколько недель до этого тикета сервер также был частью проекта NTP Pool.
Здесь важное слово «был». В конце декабря 2016 года я вывел NTP-серверы BitFolk из общественного пула и заблокировал их для посторонних.
Я так поступил, потому что из-за бага Snapchat NTP на них пошёл необычно большой трафик. На самом деле это не вызвало каких-то огромных проблем, просто такой объём трафика выталкивал полезную информацию из базы сохранения сетевого потока Jump фиксированного размера, а я не хотел разбираться с этим во время праздников, поэтому просто отключил публичный доступ к сервису.
PS Яндекс платил за услугу NTP или нет?
Предполагалось, что коммерческие компании будут обращаться в отдельную «зону вендоров». Они перечисляют проекту небольшой взнос — и получают зону DNS, выделенную для их продукта, так что администраторам пула проще направлять трафик.
PPS Оказалось в Wiki есть статья с такими достижениями компаний в разные годы - NTP server misuse and abuse.
PS Яндекс платил за услугу NTP или нет?
кмк, второе
Flawed Routers Flood University of Wisconsin Internet Time Server
- Netgear Cooperating with University on a Resolution -
Этот канон (2003-2005) рекомендую к чтению наряду с "What Every Computer Scientist Should Know About Floating-Point Arithmetic".
https://web.archive.org/web/20060410200249/http://www.cs.wisc.edu/~plonka/netgear-sntp/
Надо бы обновить Wiki
Это главный вопрос. Отдельная зона в таких случаях позволяет потушить зону вендора, а не весь пул. За это кто-то должен быть наказан.
Знал бы где упадёшь - соломки бы подстелил.
Профессионализм показывается не тем, что компания или человек не допускает ошибок, а тем, как на свои ошибки реагирует.
Согласен полность, это либо экономия либо воровсво. Хуже воровства только простота, что не допустимо в сложных системах )))
Думаете увидим yandex.pool.ntp.org или ya.pool.ntp.org или alisa.pool.ntp.org ?
Добавим второй вопрос, из-за чего не договорились об собсвенном пуле, как у убунты есть свой ubuntu.pool.ntp.org
О таком мало кто заботится. Возьмите какой-нибудь домашний роутер, скажем, TP-Link или ASUS - их по миру немало натыкано, но во всех из коробки будет прописан адрес pool.ntp.org (или региональный типа ru.pool.ntp.org), но своего пула не заводят.
С роутерами другая история - их по всему миру продают, невозможно предсказать где именно он будет работать. Арендовать серверы по всему миру физически невозможно, а запрашивать в условном Зимбабве время с сервера в Тайване = создать нагрузку на сеть даже больше, чем если просто взять её у локального поставщика. Тем более обычно роутеры не запрашивают время раз в 5 секунд.
Деньги.
Как работник корпорации с 2+млн сотрудников, могу сказать, что несмотря на то, что отсутствие своих серверов усложняет многие внутренние процедуру сертификации - тем не менее и днс и нтп - внешние, ибо надо на них выделять бюджет.
А с точки зрения менеджмента - зачем, если все работает.
Скорее всего это было в результате ленивого чтения Хабра и такого же типа блогов. Как они сами указывают в статье - это не покрыто тестами.
Сколько ещё такого кода может, внезапно (как любит писать Максим в ЛОРе), создать на ровном месте аварийную ситуацию?
Как в моей практике это было с BIND4, хорошо что меня в своё время буквально ткнул носом в проблему AI (https://uic.vsu.ru/archive/5let/andy.html), в то время старший администратор ВЦ ВГУ, опорной точки сети RBNet.
Из личного опыта, нахожусь по счету на 4 линии техподдержки, пока проблема дойдет до меня она немного помаринуется на остальных трех, если действительно проблема есть и клиент не может починить сам, то я её увижу через неделю +/-2 дня.
То есть на первых трех линиях проблема маринуется по три дня примерно??? В нормальных сапортах первые два линии отрабатывают за пару часов, третья - сутки.
Ну в нормальных да, а Яндекс тут при чём)
На первой линии, по моей памяти, проблема дольше часа - это факап. На второй - сутки-двое. На третьей - неделя-другая. С четвёртой линией в штате как-то не сталкивался - в моей практике это либо вендор, либо подрядчик (да, с малазийцами был прикольный опыт, но это оффтоп)... даже не представляю, сколько может такое времени занять.
в той теме о коллапсе пула вчера отписывался сотрудник поддержки с заявлением в духе " колонки ведут себя нормально, просто им нужно очень точное время иначе будильник может зазвонить не вовремя". Конечно, на него слегка накинулись :)
А мне интересно, откуда взялся график? Его собирали "на всякую случку" или был повод ранее? Если первое, то нужно просматривать результаты мониторинга и отлавливать аномалии по всем собираемым показателям, при чем и на тестовых средах, что наиболее правильно, и при раскатке на фокусных группах особенно. А если второе, то нужно еще и сделать оргвыводы.
Планируете ли использовать multicast (наверно уже по IPv6?) для синхронизации устройств внутри локальных сетей?
плюс в карму Яндекса за то что сознались сами, а не дождались пока тыкнут носом
P.S. Всё жду когда таки СДЭК выкатит своё подробное расследование летнего инцидента. Но наверно не дождусь..
Возможно, вероятность реакции будет больше, если в комментарии упомянуть @Marat25, представителя СДЭК. Тогда ему придёт уведомление.
про это уже неоднократно тыкалось носом, но ответа от яндекса так не было..
почему яндекс станция принимает опцию 42 с dhcp и работает с локальным ntp сервером, но при этом не прекращает спам на ntp в Интернете?
почему обращение к ntp серверам идёт с частотой в 90 секунд?
почему яндекс станция так же берёт на себя функции ntp relay для "других клиентов или станций?", за день в списке dst-address почти полсотни ip адресов провайдеров по всей РФ.
почему имея дома разношёрстный зоопарк умный устройств, проблемы вызывает лишь яндекс, впервые именно для яндекс станции пришлось создать правило фаервола разрешающие только трафик на yandex cloud и блокирующее всё остальное..
А как быть с их спамерским yandex.net, причём через его скрипты завязано протаскивание всевозможной рекламы с их rbt-yandex?
Причём они на него завязали и выдачу результатов поиска, то есть необходимо на шлюзах ставить прокси с анализаторами потока, чтобы всякие телевизоры и обычные браузеры избавить от Р-Е-К-Л-А-М-Ы!!!
я думаю эффективнее будет вот так:
Яндекс
Тыкнули носом в оригинальном посте раз 10.
Всё жду когда таки СДЭК выкатит своё подробное расследование летнего инцидента.
Тоже самое, и судя по плюсам - нас таких много)
Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете.
Домашнее задание - подберите эквивалентное предложение из двух слов.
Положили весь рунет и это не самый высокий приоритет. А что тогда высокий? Майкрософт багу с апдейтом винды починила за 4 часа.
ну это уже не первый раз, если вспомнить, например, апдейтер яндекс диска, который делал rmdir C:\
Не самый высокий приоритет был когда редкие технические продвинутые пользователи попадали на первую линию поддержки и писали «а у меня что-то станция часто запросы делает, это ок?».
Из текста, когда багу всё-таки обнаружили, её почти сразу пофиксили (пока ещё не осознавая масштабы проблемы) и медленно выкатывали (релизный цикл видимо порядка недели), а когда на хабре написали про большой факап всея рунета и популярно объяснили масштаб беды, предприняли альтернативные, но более рискованные меры.
ИМХО, это вполне себе высокий приоритет — в воскресенье применять правку конфига катить на 100% устройств — учитывая что дождаться обычной выктаки фикса оставалось всего около трёх дней.
Я бы лично настаивал на том чтобы докатить по стандартному флоу и без доп.рисков, нежели тратить свой выходной на то чтобы найти и придумать альтернативу, собрать фикс, выкатить, а утром понедельника рисковать увидеть новости в духе «Алисы по всей России перестали показывать время, миллионы будильников не сработали». Чай ещё три дня ддоса погоды рунету не сделают.
Чай ещё три дня ддоса погоды рунету не сделают.
Действительно, а всего-то нужно было настроить пару тройку своих NTP серверов.
Проблема не в будильниках, и не в ддосе рунета, проблема что, кто-то вообще не следил за нагрузкой создаваемой Алисой на не свои сервисы.
Это не техническая проблема, а управленческая, причина называется максимизация прибыли минимизация убытков. Вот беда, всплыло там где не ждали, такая большая компания и не может позволить NTP сервера себе который может позволить любой админ, с интернет каналом 100 мегабит.
Есть более заметный и известный пример, когда прибыль компания забирает себе, а издержки (инфраструктура, страховые случаи) перекладывает на общество -- Самокаты яндекса
Действительно, а всего-то нужно было настроить пару тройку своих NTP серверов.
Вот тоже об этом подумал. Им наверняка ничего не стоит воткнуть по старенькому серваку в каждом дата-центре и пускай работают.
Да даже просто админу в офисе на любом приличном компе поставить какую-нибудь ubuntu server и подключить к свободному белому ip.
Не могу понять, в той статье предлагался способ поднять свой ntp сервер засчет покупки хостинга и развертывания нужного софта. Яндекс сам по сути предоставляет хостинговые услуги, и неужели не могли сами поднять ntp сервер по той инструкции?...
Да никто об этом не думал просто. Сделали когда-то давно, потом забыли, ведь работает - не трогай, всегда есть более приоритетные задачи. А тут вот оно напомнило о себе.
Но конечно, как обычно в комментарии набегают теперь тысячи умных людей с их послезнанием и "задним умом все крепки", и считают что все было очевидно и предсказуемо с самого начала, а все случившаяся исключительно злая воля яндекса.
Ну речь вообще не об этом шла. Ниже в комментах тоже недоумевают на этот же счет: когда стало ясно что сервера вылетают, то был поднят клич, чтобы спасти ситуацию и предлагалось вложиться баблом и помочь (пишут что таймвеб сделали это и поучаствовали своими серверами). В этот момент яндекс не захотели вложиться баблом, а пытались устранить свой же косяк. Меня просто это и смущает, ведь улучшить ситуацию на тот момент можно было бы по той инструкции про которую в самом начале статьи написали сами же яндекс
В качестве временного решения, можно было бы просто поднять NTP виртуалки в yandex.cloud. Timeweb это сделал в течение дня. Кстати, можете сказать им слова благодарности за то, что они "подставили плечо")
Яндекс в это время устранял причину проблемы, снижая тем самым нагрузку.
Как бы там ни было, если одним из итогов этого неприятного события станет то, что Яндекс полноценно войдет в пул, думаю данная "встряска" сделает зону RU гораздо более стабильной и защищенной от подобных инцидентов в будущем.
Яндекс в это время устранял причину проблемы, снижая тем самым нагрузку.
В яндексе далеко не одна команда. Исправление проблемы - это два действия:
1. Быстрое тушение огня, чтобы справиться с последствиями.
2. Исправление причин проблемы в спокойном режиме.
Если огонь быстро не потушить, то устранять причину придется в огне. Что, собственно, у них и получилось.
Можно было бы сделать простую вещь - пока одна команда работает над исправлением, попросить другую команду поднять 50 виртуалок с NTP серверами. Это бы не исправило причину проблемы, но разгрузило бы сервера в рунете. И можно спокойно работать над релизом. Виртуалки потом можно было бы потушить.
Но там сделали по другому. Пока NTP серверы рунета испытывали DDoS, там в мыле трудились над релизом и не тушили огонь. Они сами пишут об этом.
К 20 ноября мы нашли ошибку, внесли исправление в код и начали готовить новый релиз.
В выходные 23–24 ноября ситуация с NTP‑серверами обостряется: доступными остаются лишь четыре сервера.
Хотя задним умом - все гении. Но я не увидел в статье, что они об этом задумались.
Но я не увидел в статье, что они об этом задумались
Потому что эта статья – просто пиар. У Яндекса ясно видна тактика реагирования на такие инциденты: они признают что-либо только когда комьюнити основательно вываляло их в грязи, и каждый раз что-нибудь обещают. Ненапряжное и невозможное для контроля.
Типа «проведём работу с персоналом», «улучшим тесты», «развернём сервера» – новости из будущего, короче.
До очередной NTP-bomb, BIND4 и прочих...
Весь исходный код и протоколы TCP/IP (IPv4) и сопутствующих сервисов не предполагал, исходно, глобального распространения и какой-либо защиты, в лучшем случае от дурака, это просто обычный концепт, который стал основополагающим скелетом текущего состояния цивилизации.
Иногда временные решения носят такой разрушительный характер, что для их исправления требуется замена IT систем. (цитата с vc.ru)
Весь исходный код и протоколы TCP/IP (IPv4) и сопутствующих сервисов не предполагал, исходно, глобального распространения и какой-либо защиты, в лучшем случае от дурака, это просто обычный концепт, который стал основополагающим скелетом текущего состояния цивилизации.
Скорее предполагал другое состояние цивилизации.
Он не являлся временным, наоборот, большая заслуга авторов в том, что он смог продолжить работу в условиях, на которые не рассчитывался - т.е. дураков + бизнеса.
Что, не помогли алгособесы от ошибки, грохнувшей NTP сервера в рунете?
Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики
Большинство опытных разработчиков, которые работу работают, а не з*****т аглоритмы, знают, что метрики должны быть на все генерирующие трафик (читай все io операции) компоненты.
Поэтому мы запланировали выделить ресурсы в общий пул NTP‑серверов.
Ну тут плюс конечно. А еще свои метеостанции раскидайте по стране, так как ваша яндекс.погода тоже держится за счет станций сообщества.
P.S. Минусите карму, мне пофиг. Всем слабо высказаться и признать, а мне нет, устал уже от этого цирка.
метрики должны быть на все генерирующие трафик (читай все io операции) компоненты.
К слову, в статье есть график с подписью «динамика числа отправляемых колонками NTP-запросов». Вопрос тут в том, почему на него никто не обратил внимание, но в статье пишут что банально уведомления не были настроены.
Не понятно как получили график. Возможно нарисовали постфактум.
То что алерты не были настроены, к сожалению это распространенная проблема. И на это так же часто обращают внимание опытные разработчики, так как в работе уже сталкивались с отсутствием алертов.
В подкорке уже срабатывает звоночек - тут не плохо было бы повесить уведомление.
Я лично такие вопросы на каждом дейлике поднимаю и выделяю отдельное время на метрики и алерты (читай задача).
Совсем смешная ситуация когда на алерты не обращают внимание, потому что их много))) С таким тоже сталкивался.
Тестов нет
Уведомлений нет
Сервера заиспользовали чужие
Дежурной команды нет
@
Не прокатило
@
Мы многому научились, гайз
Кажется, это именно оно. Крупная компания заложилась в своём проекте на инфраструктуру, NTP серверов, поддерживаемую кем-то другим и сама не озаботилась вовремя о поддержке этой инфраструктуры.
Уже вспомнили предыдущее https://habr.com/ru/articles/434422/ там в итоге всё умерло, правда.
маленькая индикомания яндекс не смогла позволить купить себе пару штук ntp серверов, пришлось ддосить публичные
У меня роутер по DHCP отдает NTP сервер(опция 42), что мешает Вам внедрить в DHCP клиент станции. чтение и использование этой опции, в корпоративных сетях да и дома у многих своя страта s2 используйте NTP которые развернуты внутри локалок
Потом вы поставите на своем NTP сервере 27 ноября 2013 года, и спросите - "Алиса, курс доллара!". А она вам - "35". И будут претензии ). А ведь можно еще что-то и посерьезнее политически-дискредитирующее спросить!
Сервер не должен полагаться на время клиента
В таком случаи она просто замолкнет, тк SSL/TLS сертификаты имеют свое время жизни, Алиса ответит "ой, что то с интернетом" НО опять же возвращаясь к своей инфраструктуре, за ней в компаниях следят как и дома, по умолчанию опция 42 и NTP server в локалке не работает, его просто нет......
У меня из-за NTP сервера провайдера TOTP отвалился, пришлось переключаться.
Выдавал неправильное время.
То есть он разъехался на больше минуты и потерял связность с другими серверами?!
Да, причём недавно, но раньше инцидента, поэтому скорее всего не связано.
Тут региональный провайдер, может подняли когда-то для галочки и не следят.
О, была у меня история. Сетка машин на 60, примерно. И kerberos. Как раз тогда в России отменили то-ли летнее, то-ли зимнее время. А обновления временных зон на клиентские машины не накатились.
Пользователи уже знают, что если время стоит сильно не правильно - пускать в систему не будет. Время поменялось, встало правильное по Гринвичу, но не правильное визуально. Пользователи его поменяли руками в биосе. ("Ну мало ли что случилось"). А потом были массовые вопли "нас не пускает, а время правильное!"
Добавлю причину почему обновления не накатились - потому что аккуратно перед выходом законопроекта о переходе на вечное зимнее время с вечного "летнего" закончился срок поддержки Windows XP :-)
Тоже мне проблема. 2021-ый год, обновляем SSL сертификат для сайта, сотрудник на удалёнке получает ошибку про неправильное время. Разборки показали, что все эти годы в компьютере стоял неверный часовой пояс, а чтобы время было правильное - часы сдвинуты на час назад. Ну и сертификат оказался в будущем. Удивились, что за столько лет у сотрудника оказалась первый раз подобная ситуация.
нормальная у вас там обстановка, пользователи в биос сами ходят..
это как замок на дверь крутой повесить и окно рядом открытое оставить
Ну университетская кафедра, чего вы хотели? Пароли по идее должны стоять, но стоят далеко не везде и не всегда (севшие батарейки, потом батарейку поменяли, пароль поставить забыли. Я бороться пытался, но квалифицированных рук тупо не хватало уже тогда). А на современных материнках, когда дежурного питания нет, батарейку высаживает довольно быстро. Это в сочетании с "всё должно быть полностью обесточено когда не используется" и самыми дешёвыми батарейками приводит к тому, что батарейки живут максимум год-полтора.
Средние пользователи естественно не ходят, но лаборантский состав ходил.
"Жалоб было мало, действующий регламент поддержки не был рассчитан на подобные ситуации, поэтому обращения рассматривали не в самом высоком приоритете." - ваш звонок очень важен нет для нас , пожалуйста, оставайтесь на линии....
Вспоминается мой недавний багрепорт одну сервису за который я деньги плачу вида: не встает на новом устройстве, пишет api-сервер недоступен, в логах adguard-home - запрос в серверу такому то а там nxdomain. Ответ на 90% состоит из описаний как поставить VPN (сервис в значительной мере ориентирован на Россию и блокируется Роскомнадзором, из сторов их турнули)(в письме было прямо указано что VPN на роутере стоит) в разные местах и единственное полезное - ссылка на бета-версию приложения, это помогло.
root cause не баг, отсутсвие тестов, выделенных серверов и тд, а писать свой NTP клиент при наличии как минимум 2 отлаженных опенсорсных.
Думаю все IOT-компании вокруг посмотрят на этот инцидент, сделают выводы и поймут... насколько же это круто иметь под рукой собственный ботнет.
«Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью»
А что, если это и есть злой умысел? Эвона как все бросились сервера и баги обсуждать. А вдруг РКН или нечто такое же попросило\заставило\подкупило Яшу как раз для того, чтобы проверить на прочность рунет? Зачем? Я не знаю, самое простое обьяснение - это как злодеи в фильмах, вот им обязательно людям делать пакости, день без злодеяний - зря прожитый. Только это не в фильмах а уже тут. Зачем холопам знать точное время? Еще сговорятся и соберутся, а это низя. А может быть, этой таинственной и злой организации как раз и нужен под рукой ботнет?
/теории_заговора_off
Благодаря ему на запрос пользователя отвечает только одна, ближайшая колонка, а не из соседней комнаты.
Вы сравниваете до какой колонки звук дошел быстрее, та и отвечает?
Тут вот в чем проблема, сообществу "ссут" в глаза прямо проясняют первых строк.
Поэтому мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.
@slavashel не подозреват что у меня домашний роутер который отдален, от М9 выдает stratum 2 точности, и 100 мегабит из 500 я отдаю в пул.
https://www.ntppool.org/a/vgdnet
Из его слов получается яндекс чуть бедней чем я так как не может себе позволить, настроить NTP и разместить их у себя, и продолжит пользоваться общесвенным пулом, без выделения зоны.
Объясните, пожалуйста, дилетанту: а почему бюджетные наручные часы уходят на несколько секунд в год, а эти ваши устройства (а также RTC в материнках практически любого производителя) требуют такой вот частой синхронизации? Какие-то [censored] Эффективные Манагеры ради экономии в 0.000001 бакса не дают Гениальным Инженеграм использовать [censored] кварцевые резонаторы?
Потому что у ваших часов одна функция: показывать время. И направлена она на удовлетворение 1 потребности 1 человека: владельца часов. А эти колонки не только музыка для пользователя. Это ещё источник рекламы, денег с рекламы, и огромный распределённый ботнет при желании. За одну ночь можно раскатать обновление с "новым функционалом" на весь зоопарк этих колонок. Вопросы о том "какой будет функционал" и "нужен ли он пользователю" - не ставятся в принципе. Как и вариант "отказаться от обновлений" вне рамках доступного. То есть пользователи приобретают за свои деньги девайс, который будет вести себя как захочет Яндекс. Если Яндекс захочет то отключит все колонки и они просто перестанут работать. А захочет - будет майнить на них биткойны, слушать и записывать окружение, шпионить, транслировать рекламу или координировать звуком окружающие устройства имеющие голосовое и звуковое управление, спамить в NTP или взламывать Пентагон... Да что угодно в общем, у пользователя только 2 доступных режима: вкл и выкл. И всё. Повлиять пользователю на прием "обновленного функционала" не предоставляется. Или пользуйтесь "как есть" или не пользуйтесь. И это не только колонки Яндекса имеют такую политику.
Это еще не все. Обратите внимание, эта махарайка обновляется удаленно. У нее значит, есть загрузчик, ОС, апдейтер и система защиты, которую можно взломать. В подобных поделках всегда множество дыр, пример: Apple. Данный прецедент с NTP показывает, что отлаживали систему ну так... по регламенту.
Это вам не микротики (в которых тоже дырки есть). В микротиках копается огромное количество специалистов по безопасности и вылизывают там все. Здесь не так.
Что это значит, друзья? А это значит, что у нас потенциальный ботнет чудовищного размера.
Что значит ЕСЛИ ЗАХОЧЕТ "слушать и записывать окружение, шпионить, транслировать рекламу". А сейчас этого нет???
Вы ответили не на мой вопрос. Повторяю: почему в той колонке (а также в материнках) часы такие неточные? Напоминаю, на матплатах компьютеров/серверов/ноутов/... как бы настоящие аппаратные часы с батарейкой.
Потому что это ведёт к удорожанию, которое ощутимо при большой партии. Я помню как мне рассказывали, что некоторые фирмы не ставят защиту от переполюсовки на прибор за несколько миллионов ради экономии. Так что я вообще не удивлён.
Плюс, точности rtc, и уж тем более кварца, для позиционирования источника звука не хватит. Нужно синхронизироваться скажем, раз в полчаса (обычно этого достаточно), тут, видимо для большей точности, поставили 5 минут.
Ну и ещё, у алисы под капотом довольно небольшая плата, по размеру сопоставимая со смартфоном (именно со смартфоном, а не его платой). Причём на этой плате разведено сразу всё, от проца до усилителей, поэтому всё лишнее там исключено. Если разводку делали инженеры Яндекса, мне ничего не остаётся кроме как похвалить их за добротную работу.
Если разводку делали инженеры Яндекса, мне ничего не остаётся кроме как похвалить их за добротную работу
Вот тут Яндекс хвалился https://habr.com/ru/companies/yandex/articles/584214/
Пришлось перестраивать работу на ходу и разрабатывать ревизии, то есть варианты устройства с альтернативным набором компонентов. Казалось бы, здесь нет ничего сложного, но наш процесс разработки подразумевает тщательное тестирование выбранных деталей.
А тут как сложно было сделать станции подсветку - это очень важно :) https://habr.com/ru/companies/yandex/articles/668660/
Стандартной для кварцевых часов является точность в пределах ±20 секунд в месяц, а лучшие из наручных кварцевых часов показывают результат ± 5 секунд в год.
Я думаю что у часов компа точность примерно такая-же, что там что там недорогой "кварц". Как выше отметили - у часов "показывать время" это основная задача и всё-таки подстраивать руками всё равно приходится. У рядового десктопа точность кварца и хода часов не так критична т.к. автоматически подстроить проще. Ну и прям миллисекундная точность на компах не нужна, просто процесс синхронизации довольно простой, поэтому скорее тут руководствуются мыслью "чё бы не подсчитать drift и не стабилизироваться?"
Обычные компьютерные часы уходят где-то на миллисекунду в час. Это и есть несколько секунд за год. Инженеры Яндекса, очевидно, не в курсе.
Да бросьте, объяснили же про алгоритм контрактивации.
Скорость звука в воздухе при н.у. примерно 345 м/с. Разница в 1 м (типичное внутрикомнатное расстояние) во времени прихода голоса на 2 разных устройства составит примерно 3 мс.
Типичная точность хода потребительских RTC составляет, навскидку, 10ppm. Таким образом, эти 3 мс рассинхронизации набегают за примерно 5 минут. Всё вроде складно.
Можно было бы, кстати, не полагаться на публичную инфраструктуру ntp-пула. А вместо этого синхронизировать смещения часов колонок друг относительно друга. И для этого даже не придётся в интернет ходить, т.к. раположенные в одном помещении устройства скорее всего будут подключены к одному общему сегменту локалки. Это даже точнее будет и можно не стесняться и синхронизироваться до микросекундной точности, а это уже позволит различать дистанцию с миллиметровой точностью :-)
Думаю, ваше первое предположение о триангуляции звука через ntp неработоспособно. Я бы точно не стал забиваться на то, что два произвольных сервера из пула в любой момент дадут показания времени, совпадающие с точностью до 3 мс.
Это не так работает. Было здесь занимательное чтиво про синхронизацию времени, дедушку Калмана и прочие свистелки-перделки, придуманные сумрачными инженерами.
Если резюмировать, то да, каждая пара показаний от двух наугад выбранных ntp-серверов действительно не будет совпадать с требуемой точностью. Но если применить сумрачные технологии, то всё получится с любой наперёд заданной точностью, но не точнее хода локальных часов.
во времени прихода голоса на 2 разных устройства составит примерно 3 мс
С публичного NTP-пула разбег точности времени будет сопоставимым. Да и речь не об этом, а о кварце когда NTP недоступен.
Так я и возражаю против этого тезиса.
Когда NTP недоступен, кварц перестаёт давать приемлемую точность примерно через 5 минут. Ну или через час, если поставить крутой кварц. Ну или через пол дня, если это будет 0.1ppm с термокомпенсаций.
NTP всё равно нужен.
У колонок же есть связь между собой. Они же в одной локалке находятся? Ну нашли друг-друга, увязались вместе и синхронизируются. В чём проблема-то?
Такая синхронизация имеет разные edge кейсы, которые пришлось бы прорабатывать, имея на руках только абстрактные жалобы от пользователей, и не имея возможности посмотреть непосредственно на объекте, что произошло.
Например, колонки подключены к разным роутерам, или на роутере включена изоляция wireless клиентов, или в локалке есть какие-то ограничения по мультикасту.
Логично, что в яндексе решили не париться.
Например, колонки подключены к разным роутерам, или на роутере включена изоляция wireless клиентов, или в локалке есть какие-то ограничения по мультикасту.
Это как раз проверяется просто - спросили сервер - видит ли он ещё колонки в этой локалке на этом аккаунте и попробовали синхронизироваться/связаться. Не смогли - ну значит не судьба, будем отдельно.
Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
кварц перестаёт давать приемлемую точность примерно через 5 минут
Точность у кварца особо не меняется и нам не очень важна – мы её можем программно компенсировать в разумных пределах опираясь на NTP например. Тут стабильность важнее.
У НИСТа есть отчётик про наручные часы из 2008, там даже для дешманских детских часиков кратковременная стабильность 10^-8. Так что имхо хватит больше чем на 5 минут даже без термостата.
Так что NTP и с кварцем всё равно нужен, но вряд ли раз в 5 минут.
Типичная точность хода потребительских RTC составляет, навскидку, 10ppm
Это паспортная типовая, в реальности там всё сложнее. На неё накладывается ещё пуллинг (уход частоты из-за неточного согласования нагрузочной ёмкости — а оно всегда неточное, если вы прецизионной подгонкой не занимались), потом ещё уход по температуре (а если мы берём умную колонку, то у неё довольно большой диапазон реальных рабочих температур из-за нагрева при работе на большой громкости)...
Но в целом 10 ppm можно брать за значение, примерно в которое вы с кварцем с паспортными 10 ppm и попадёте.
Я возможно дурак и чего-то не понимаю, но с какой целью кто-то будет ставить две умных колонки в одной комнате, и настолько близко друг к другу, чтобы понадобилось прям такое точное позиционирование источника звука? Мне как-то казалось что обычный сценарий использования когда они стоят все же на расстоянии побольше метра, и наверное можно тупо по децибелам определять к какой колонке пользователь обращается, не? Зачем яндекс вообще начал городить вычисление через скорость звука, я правда не понимаю.
Можно было бы, кстати, не полагаться на публичную инфраструктуру ntp-пула. А вместо этого синхронизировать смещения часов колонок друг относительно друга.
Для этого даже специальный отдельный протокол придуман: PTP - Precision Time Protocol
Обычно на порядок-два больше. Миллисекунда в час - это 0.3 ppm. Среднестатические кварцы - 5-20 ppm.
Разные компьютеры ведут себя по разному. Отклонение часов в том числе может зависеть от нагрузки или специфики использования (сервер терминалов например). Аварийное отключение также может привести к более значительным скачкам (в своей практике сталкивался с 40 секундами и более).
Заявленная точность ширпотребных кварцевых часов "±15 seconds a month" (на примере Casio G-Shock).
О_о на "электронике" и то в ГОД уходило время максимум на 3 секунды. И то, достаточно было раз или два задать корректировку (уже забыл как, но помню что не слишком сложно, нужно только определить в какую сторону и насколько ушли показания от эталона в течение какого-то интервала, и часы сами потом корректировали свой ход).
В статье это объясняется, на точное время завязана например, функция определения того, какой из ваших умных колонок надлежит ответить на ваш голос.
Ну и криптография тоже завязана на время: попробуйте на компьютере открутить время на недельку взад, а потом зайти на Хабр. Как раз недавно одному пользователю я исправлял последствия его, пользователя, просчёта с синхронизацией времени: этот феерический человек загнал свой роутер в замкнутый круг "в качестве DNS-сервера на роутере указан локальный адрес, недоступный, пока не поднят VPN-туннель; туннель после перезагрузки роутера не поднимается из-за сбитого времени; время невозможно синхронизировать, так как без рабочего DNS не удаётся отрезолвить домен NTP-сервера" - ну и всё, приплыли.
Ну для криптографии плюс минус пара секунд не роляет. А вот для всяких стереопар и мультирумов сотня миллисекунд уже будет заметна
Почти на порядок жёстче требования на самом деле.
В кино допустимый разбег между картинкой и звуком порядка 35 мс. В аудио между двумя каналами — надо где-то вдвое меньше, чтобы не начали появляться заметные на слух «псевдостереоэффекты».
где-то тут Яндекс уже писал что стереопары находят друг друга и синхронизируются друг с другом по отдельному ими разработанному протоколу.
Для криптографии в сети (TLS), кроме времени когда сертификаты меняются - даже неделя не очень критична.
Для kerberos-а - да, нужна точность порядка ±5 минут в разные стороны. (точнее - не более 10 минут разницы между сервером и клиентами). Это с настройками по умолчанию.
Для TOTP - интервал обновления ключа порядка минуты, но по идее правильная реализация будет проверять соседние интервалы тоже.
В ваших часах есть батарейка, от которой они и работают, у них нет других вариантов, кроме как иметь точное время автономно. На материнских платах есть батарейка (когда-то давно раньше - аккумулятор), от которой будут работать часы на них даже если компьютер полностью обесточен, что при обычном сценарии использования бывает редко. И есть дополнительно источник дежурного напряжения относительно приличной мощности, но это уже другая история. Пока синхронизация времени через интернет не была массово доступной, был смысл ставить более точные кварцы (даже с подстройкой частоты попадались, а ещё "гробики" от Dallas со встроенной батарейкой были хороши, пока она не кончится и не понадобится пилить чтобы подключить внешнюю). Сейчас, мне кажется, производители не заморачиваются проверкой - проблема не будет заметной у большинства пользователей, даже если время уйдёт, NTP его поправит. Но это в мире ПК, где совместимость и традиции. В мире интернета вещей всё не так (Буква S в аббревиатуре IoT обозначает безопасность). Во множестве устройств IoT никакой батарейки для часов (или отдельных часов для режима микропотребления) нет совсем, они запускаются с какой-то дефолтной датой, и полностью зависят от наличия сети и NTP - без них точного времени не будет, неоткуда взять. Потому что батарейка неудобна в пайке, и на больших тиражах это будет заметно, потому что устройство без доступа к сети не имеет смысла и неработоспособно, потому, что точное время не нужно устройству, потому что производитель не захотел тратить на это время и ещё 100500 причин. Такая же штука и с Яндекс - станциями, там нет батарейки - с одной стороны, нечего менять и нечему дохнуть со временем, с другой - без сети времени не будет, совсем. Именно поэтому, только загрузившись, станция начинает активно это время синхронизировать. Может быть в самой большой, с экраном, что-то есть, не смотрел, а в Max и более маленьких - нету. И не факт, что надо.
Может быть в самой большой, с экраном, что-то есть, не смотрел, а в Max и более маленьких - нету
Выделенный RTC есть в колонках с Zigbee, он питается от ионистора с запасом на пару суток. Но это не для точности счёта времени, а для быстрого его восстановления при перезагрузке (в т.ч. после отключения света), чтобы у вас завязанный на Zigbee умный дом продолжал корректно сценарии отрабатывать.
Для точности счёта выделенный RTC не очень нужен, центральный процессор вполне себе справляется, причём по большей части аппаратно (его основной кварц → делитель → счётчик). Уход времени у него сравнимый с RTC с 10 ppm кристаллом.
Потому что батарейка неудобна в пайке, и на больших тиражах это будет заметно, потому что устройство без доступа к сети не имеет смысла и неработоспособно, потому, что точное время не нужно устройству, потому что производитель не захотел тратить на это время и ещё 100500 причин.
Уже лет 20 есть ионисторы. По характеристикам - среднее между батарейкой и конденсатором. Паяются как конденсатор. Ёмкости для поддержания работы часов хватит минимум на неделю-другую после выключения. Скорее всего больше, мне лень считать (там ёмкости порядка единиц фарад).
Типичный хороший часовой кварц имеет паспортную погрешность ±10 ppm (кварц чуть проще — ±20 ppm, кварц заметно дороже — ±5 ppm; если вам надо ещё точнее, это уже не кварцы, а радикально более дорогие готовые генераторы). Это при 25 °С. Поверх этого есть дрейф по температуре и дрейф по нагрузочной ёмкости (т.н. «пуллинг» — pulling), которая в свою очередь есть некая комбинация из паразитной ёмкости дорожек платы, паразитной ёмкости входов чипа и паспортной ёмкости нагрузочных конденсаторов (у которых тоже есть погрешность).
Влияние каждого из этих паразитных факторов — до единиц ppm.
10 ppm — это 0,864 секунды в сутки, 26 секунд в месяц, больше 5 минут в год.
Более высокую точность гарантированно имеют только очень небюджетные часы, в которых много сил и денег было вложено в получение погрешности порядка 1 ppm. Если вы такую точность получаете в бюджетных часах — вам очень повезло с конкретным экземпляром.
Граждане помнят советские часы "Электроника" на дряных советских кварцах, но с цифровой подстройкой хода, которые давали точность 3-5 секунд за год. Для достижения этой точности их нужно было настроить по паспорту и потом ещё стараться всегда носить на руке чтобы у них не плавала сильно температура в течении этого времени
Удивительно что такая опция, казалось бы, фактически бесплатная в кремнии (размажется на больших тиражах) - но вроде как и не встречается в часах зарубежных фирм.
Вот сейчас подумалось, ведь есть часы с автоматической радиоподстройкой времени. Такую подгонку можно было вообще сделать автоматической. Хотя наверное в таких часах это не особенно что-то меняет. Ну, может, снизить регулярность автоподстройки…
Потому что там у них кварцы такой точности были, что не было смысла напрягать потребителя каким-то выставлением погрешности в скрытом меню
Сейчас все смартчасы, по факту, являются с автоподстройкой от часов сматртелефона.
Были часы, которые синхронизировались по радио на 433Мгц от адаптера на ПК
Сейчас все смартчасы, по факту, являются с автоподстройкой от часов сматртелефона.
Это не то, речь про частичную компенсацию ухода ущербных кварцев силами микросхем в часах. А так, есть и не очень «смарт» часы с блютуз, подстраивающие своё время с помощью смартфона. Даже у тех же Casio
Были часы, которые синхронизировались по радио на 433Мгц от адаптера на ПК
Есть и «не смарт» подстраивающиеся от радиовышек, те же Casio их маркируют как Multiband и wave ceptor. Без всяких адаптеров дома. Но эта рация опция применима не везде
Там, наверно, всё-таки такой точности не было. "Сигналы точного времени" по радио передавали, я с них цифровую подстройку корректировал. Вот сейчас беру время через интернет, так оказалось, что сигналы по радио несколько менее точны. Я, когда срочную во флоте служил, по правилам должен был бегать с секундомером для установки часов на катере в соответствии с заданными параметрами, так почти сразу стал по своим часам "Электроника" (с ЦПХ) устанавливать, только перед проверкой всё же время проверял. И сейчас у меня есть реле с ЦПХ (вырубает питание в случае задымления и некоторых потребителей в случае отклонений питающего напряжения, но не это важно), так я так же, как на "Электронике" действую: не корректирую время, а корректирую в том или ином направлении подстройку. Точное время беру своим скриптом со сторонних серверов. Если правильно помню, он должен по onload страницы синхронизироваться только.
Была, проверял лично
У меня такие рассуждения: насколько помню, точность ЦПХ задавалась до одной десятой в сутки. Тогда получается, что в стационарных условиях по всем остальным параметрам (чего, конечно же нет на практике) уход за 10 дней может составлять до одной секунды, или, если возьмём средний уход за год (а здесь, наверно, подходом дискретной математики всё же можно воспользоваться), то порядка ±18 секунд. То есть ваш результат лучше, чем в среднем по выборке. Вам повезло. Но, может, кто-то поправит, если я где в рассуждениях ошибся.
Вот сейчас беру время через интернет, так оказалось, что сигналы по радио несколько менее точны.
Потому что сейчас радио идёт в цифре. Кодировка-раскодировка-буферизация и прощай точность.
PS На Сочи-Автодроме смотрел Формулу-1 и хотел с телефона в наушнике слушать комментарий Попова через интернет вещание. Задержка была больше одного круга, около двух минут.
У наручных часов условия лучше - колебания температуры меньше
А синхронизация и проверка времени и параметров между колонками в одной локальной сети будет работать, дополнительно? А также синхронизация со смартфоном пользователя/роутером/Яндекс_ТВ_Станцией, при недоступности внешних источников?
Спасибо.
Где-то на хабре видел статью про то, как яндекс станция ntp-спамом ложила роутер у человека на работе, почему проблема не была решена еще тогда?
Наверное потому, что такие одиночные случаи всегда в низком приоритете, и всегда есть более важные задачи. Блин, ну все задающие такие вопросы как дети, прямо слово. Вы будто никогда не работали в компаниях и проектах больше чем на пару человек, где все очень медленно, огромный бесконечный бэклог с проблемами, менеджеры при этом постоянно накидывают срочные новые бизнесовые фичи, и до проблем какой-то пары гиков у команды руки дойдут примерно никогда. Пока вот гром не грянет.
Это сейчас очевидно что проблема была серьезная, а тогда было не очевидно. Мелкий перерасход трафика у пары человек, отложим на запланированный через пять лет крупный рефакторинг сетевого стека, а пока давай-давай новую рекламу прикручивай (или чем там колонка занимается, не в курсе, принципиально против подобных устройств).
Но число генерируемых нами NTP‑запросов исторически никогда не входило в метрики, требующие валидации
Как-то неубедительно звучит. IoT-устройство при тестировании подключается к сети через монитор трафика. Монитор создает отчет о всех типах запросов которые генерирует устройство в течении суток. Отчет сравнивается с отчетом по предыдущей версии прошивки. По отчету сразу должно быть видно что структура запросов изменилась по сравнению с предыдущей прошивкой. Сложно проглядеть что частота каких-то запросов в новой прошивке резко выросла.
Вопрос к знатокам:
Никогда не заморачивался мануалами, добавил alias синхронизации времени и.
Код:
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:22:28 ntpdate[9664]: adjust time server 195.186.4.100 offset -0.322929 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:26:06 ntpdate[9732]: adjust time server 185.175.56.95 offset -0.221902 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:26:43 ntpdate[9822]: adjust time server 217.14.146.53 offset -0.208654 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:29:42 ntpdate[9986]: adjust time server 80.50.102.206 offset -0.140448 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:29:53 ntpdate[10007]: adjust time server 62.173.141.123 offset -0.134949 sec
┌─[user@DH]─[~]
└──╼❕sudo ntpdate ntp0.ntp-servers.net
27 Nov 12:30:05 ntpdate[10027]: adjust time server 192.33.214.47 offset -0.122601 secТакая синхронизация времени с разбросом - это нормально?
ntpdate двигает время скачком в отличии от ntpd и chrony, которые его плавно сдвигают (в случае незначительного отклонения) + сами коррелируют интервал синхронизации, а также позволяют использовать несколько ntp серверов выбирая из доступных по своим алгоритмам более предпочтительный в данный момент времени.
Не понятно, что значит "скачком/плавно". Вопрос про синхронизацию времени с низким качеством: сотни миллисекунд погрешность достигать может, это много.
сотни миллисекунд погрешность достигать может, это много.
А в каких сценариях нужна такая точность? Даже в пределах секунды сертификат сайта определится корректно, дата и время изменения документов будет достоверна, информация в логах будет отражать действительность, товарищи "полиционеры" записи с разных камер наблюдения снимут без проблем.
"скачком/плавно"
да, тут я отошел от сути вопроса, но раз уж затронул эту тему, то ntpdate время выставляет сразу, резко (т.е. скачком), а ntpd и chrony ускоряют и замедляют ход часов между интервалами синхронизации с целью постепенно наверстать отставание либо устранить опережение эталона (скачка нет, если отклонение незначительное, если значительное, то работают также как ntpdate при первичной синхронизации).
ntpdate по расписанию в целом имеет право на жизнь, если нет возможности использовать что-то более специализированное для синхронизации времени.
Это нормально. man ntpdate, man adjtime до просветления.
Вкратце, ntpdate увидел небольшое расхождение и пытается "плавно" свести его на нет. Этот процесс вы и наблюдаете
Интересно, а DNS серверами в колонках Yandex тоже публичными пользуются, а не своими?
Подобные обращения мы получали и раньше, но причиной всегда были сетевые ограничения на стороне пользователя (например, работодатель мог ограничивать запросы со стороны колонки в корпоративной сети)
То есть, о тенденции ухудшать ситуацию в сети в случае проблем дополнительной нагрузкой, Яндексу было давно известно.
Например, алгоритм контрактивации требователен к точности внутренних часов. Благодаря ему на запрос пользователя отвечает только одна, ближайшая колонка, а не из соседней комнаты. Поэтому нам нужно обновлять время на них несколько раз за день.
И это решается тем, что каждая колонка индивидуально ходит в Сеть за точным временем? Причем с интервалом, явно взятым с потолка - ой, одна минута это оказывается плохо, давайте сделаем пять часов.
Почему колонки в одной физической локации не синхронизируются между собой? Может, не такие уж они и умные?
Почему программисту (and I use this term loosely) вообще не пришла в голову мысль, что один запрос в минуту умножить на один миллион устройств равно дохрена?
Да, а эти запросы раз в пять часов хотя бы догадались разнести по времени, или весь миллион ваших колонок опять одновременно ломится на несчастные NTP-сервера? А то я бы не удивился...
Правильно ли понимаю, если в сети только одна колонка, то она все равно часто синхронизирует время?
Может стоит добавить условие, если только одна колонка, то синхронизировать один раз в день, например?
Достаточно оперативно сработано, учитывая масштаб деплоя и неочевидность косяка :D
Яндексу, очевидно, нужно получать сигналы точного времени самостоятельно. GPS, ой, простите, ГЛОНАСС-приёмники в ЦОДах, объединённые в единый пул, спасут от подобных проблем. К тому же можно юзать свой домен для своих же устройств: pool.ntp.ya.ru, почему нет? А если ещё и колонки домохозяйства научатся в иерархию и одну будут назначать мастером, ой, простите, основной, а остальные - ведомыми, то ведомые могут синхриться с основной, а та - с ntp-серверами,, тем самым кратно уменьшая число запросов на ntp-серверы. И даже в случае рассинхрона с сетью вопрос "кто услышал быстрее" будет решен правильно, т.к. все синхрятся с одного локального (пусть и неправильного) источника.
Так или иначе без разницы. Если рассинхрон есть и большой, то распознавание работать не будет. Если рассинхрон маленький, то локально это будет нивелироваться. Но это неслабое такое усложнение ПО устройства.
Возможно это плохая идея. Существуют точки доступа где клиенты НЕ могут общаться между собой (вообще все или которые помечены как IoT). Например у TP-Link Deco часть железа так умеет - https://www.tp-link.com/ru/support/faq/3968/ и подается это как фича для безопасности, оно Яндексу надо такое детектировать и разбираться почему между колонками в одной сети нету связи?
А не надо разбираться почему.
Ну так Яндекс похоже решил таких случаев избежать в принципе, не устраивая иерархию и прочее. Потому что альтернатива то какая? Сказать пользователю - ой что-то колонки в одной сети не могут общаться между собой ты пользователь поправь то не знаю что бы могли? На следующей день будет статья на Пикабу про то что колонки сговориваються с целью захвата мира -:), а работать все равно ничего не будет потому что совсем не факт что пользователь который WiFi настраивал и который цепляет колонки - это один и тот же пользователь и даже если один и тот же - будут вопросы в техподдержку вида "я же правильно понимаю что вы мне предлагаете отключить функции безопасности домашней сети (почему безопасности - а производитель так сказал) чтобы ваш хлам работал?". Это если функционал вообще отключаемый. И привет лишние затраты на техподдержку и возвраты (и покупка Марусь и прочих Капсул)
Например, алгоритм контрактивации требователен к точности внутренних часов. Благодаря ему на запрос пользователя отвечает только одна, ближайшая колонка, а не из соседней комнаты.
У меня часто отвечают сразу 3 колонки, правда, они на разных аккаунтах сидят. Это баг или фича?
а зачем вам три колонки на трёх аккаунтах в одном помещении?
А вот так сложилось у человека. Как получилось три - вопрос интересный, а вот две - да хотя бы парень с девушкой съехались.
И как только они пытаются дружить не только телами, но и колонками - тут же выясняется, что весь Умный дом построен так, что полноценно им может пользоваться один человек. Неполноценно - разные люди при условии, что что все устройства привязаны к одному аккаунту. Устройства, привязанные к разным аккаунтам, между собой не могут взаимодействовать никак, и ведут себя так, как будто устройств других аккаунтов в помещении нет: например, включают разную музыку, если оба слышат команду. Нельзя настроить мультирум, нельзя управлять одним устройством через другое (например, телевизором через колонку).
Частичная же полноценность заключается в том, что права администратора дома может иметь только один человек, и только он может добавить новые устройства. А ещё "гость" не может, например, запустить музыку на колонке в приложении Музыки.
тут же выясняется, что весь Умный дом построен так, что полноценно им может пользоваться одинчеловек.
Так это ещё профессор Савельев давным-давно отметил, что умный дом - инструмент демонстрации доминантности. Типа, когда Билл Гейтс входит в комнату, где уже есть другой член его семьи, то температура в комнате меняется под Билла, чтобы не забывали, кто альфа-самец.
Как получилось три - вопрос интересный
родитель №1, родитель №2 и их ребёнок-квадробер
У каждого ребенка в комнате по колонке со своим аккаунтом и у меня. Помещения разные, но откликаются часто все три колонки.
Теперь все знают, что никто в Яндексе не дампит и не анализирует траффик со своих станций.
И ничего, что какой-то игрушкой-балалайкой положили чуть-ли не критическую инфраструктуру? ;)
Вот так реально при реализации пустяковой бытовой функции создали фактически боевую ботнет-сеть? Это вообще баг был или... ?
Разумеется баг. Вы еще скажите что история с https://krebsonsecurity.com/2015/04/dont-be-fodder-for-chinas-great-cannon/ НЕ была багом.
У меня стойкое ощущение что Умный дом от Яндекса во внутренней иерархии компании находится где-то на уровне "и так сойдет". За последний год у меня регулярно отваливались сценарии без записи в логи, отваливалась связь с устройствами, отваливались даже колонки, отваливалась поддержка устройств.
При этом на пользователях успели уже потестить рекламу и багованную фичу с адаптивной громкостью Алисы. Ребят, может как-то серьезней? Всё-таки это не бесплатно всё.
https://www.vniiftri.ru/catalog/services/sinkhronizatsiya-vremeni-cherez-ntp-servera/
Атомные часы, рубидиевые спутники...
Эк вас пронесло...
Скрытый текст
Прекрасно, с NTP разобрались, а можно пользуясь случаем поинтересоваться зачем с завидной регулярностью опрашивается Cloudflare, Google, и множество всего вокруг...
Чтобы в дальнейшем подобного не происходило, советую Яндексу раздуть штат HR, PR и прочих смежных отделов, а разработчикам запретить пить кофе больше одного раза в день! Для Гугла, Боинга, Нетфликса и пр. тоже совет есть - побольше Diversity, equity, and inclusion!
Ага, хорошо видно, что входящего (NTP + reflected ddos udp port unreachable) существенно больше, чем исходящего (только NTP). При этом корреляция налицо - то есть дудосят именно по адресам пула.
Входящего трафика всегда больше, даже сейчас. Хотя разница не в несколько раз. И к слову в зоне RU серверов уже больше 300. Хотя до Германии конечно еще далеко
"Даже сейчас" - это когда? Алисы к ддосу отношения ни имеют - они увеличивали количество легитимного трафика. А ддос как был, так и остался - это хорошо видно в банальном tcpdump'е.
Даже сейчас это когда трафика почти нет (с 400 мегабит упал до 4х). Может там и ДДОС я не разбирал пакеты. Но тогда он какой то тухленький. Был уверен что вся проблема только из-за Яндекса была.
Хотя, я же установил правила iptables которые были рекомендованы в первой статье. Возможно они ДДОС слегка режут.
Подтверждаю странное обилие icmp port unreachable, но сомневаюсь в DDoS, скорее уж, очередное рукожопие.
Отловил с десяток icmp port unreachable и посмотрел, что происходит. На первый взгляд, вполне нормальные ntp-клиенты с вполне нормальными интервалами между запросами, которые почем-то не принимают ответ.
Выглядит так, будто они забыли, что слали запрос и его надо бы принять.
Не удивлюсь, если начитались соседней ветки и не вникая в суть, навтыкали где попало notrack или же conntrack_udp_timeout в 0 поставили.
Другой вариант, что за NAT кто-то одновременно долбится куда-то, переполняя statefull nat, так что потом пакет с ответом либо неизвестно кому слать, либо шлёт не тому, кто спрашивал.
нет, icmp были и до этой и до предыдущей статьи. У меня было около 25% пакетов это icmp port unreachable (кстати они содержат в себе и исходный пакет ntp-ответа что увеличивает объём входящего).
Часть запросов приходит из за NAT с одинаковыми source ip или кривые ntp-клиенты шлют запросы очень часто (типа как Алиса раньше), где-то может быть и дудосы. Часть пакетов приходит от транзитных узлов, как будто "защищающих" того куда сервер ответил (но по идее защита тупо дропает без icmp так что непонятно). В демонах ntp-серверов есть рейтлимитер, ограничивающий ответы на слишком частые запросы с одного ip. Поэтому демон сервера отвечает не всем, дропая часть ответов. Уже поэтому исходящий pps меньше входящего.
В комментариях к предыдущему посту есть правила для iptables (и там-же ниже объяснения их работы) чтобы банить на некоторое время присылающих icmp type 3 + рейтлимитить тех кто шлёт слишком много запросов прямо в iptables, не допуская до ntp-демона.
Пока гром не грянет, Яндекс свой NTP не поднимет...
Не понял, почему сервера должны быть размещены в точках обмена трафиком. Приложения, использующие NTP, умеют учитывать RTT. Главное, чтобы это время было константным в целях уменьшения джиттера
Приложения, использующие NTP, умеют учитывать RTT.
Но умеет ли это их самопальный NTP-клиент, который не реализует даже экспоненциальную выдержку запросов?
вопрос необходимой точности синхронизации - точки обмена трафиком обладают обычно максимальной связанностью и как следствие наиболее оптимальны по предсказуемости доступности и задержкам..... что позволяет получать ту точность более простыми методами дающими меньшую ошибку....
и Это сейчас устройств пока что меньше одного на человека уже в 25-году получим скорее всего что-то близкое к одному устройству на каждого, а к 26 - 3-5 устройств на человека... это по сути уже Экспонента...
На сегодня проблема актуальна, видимо до 100% исправление пока не докатилось, работает хотфикс
Пользуясь случаем, @slavashel
1. Могли бы подсказать, что там такое шлет алиса на scbh.yandex.net это второй по популярности домен в статистике небольшого домохозяйства.
2. Могли бы объяснить, какие есть причины люто-бешено спамить запросами буквально каждую секунду на report.appmetrica.yandex.net в том случае если этот домен блокируется фильтрами?
Нельзя ли успокоить колонки и не спамить DNS запросами, если явно выражено желание не передавать "репорты аппметрики"? А предложить "попробуй через 10 минут"?
К слову базовый AdGuard DNS filter - блокирует report.appmetrica.yandex.net но это не повод устраивать шторм в домашней сети
, какие есть причины люто-бешено спамить запросами буквально каждую секунду на report.appmetrica.yandex.net в том случае если этот домен блокируется фильтрами?
Видимо действуют по принципу - На 74357181-й попытке- сервер согласился, что у него пароль "Мао Цзедун" и вообще ведь не может быть намеренной блокировки такого важного ресурса, а значит сломалось что то и надо попробовать еще раз.
И вот такое смотришь и думаешь - прям точно нет никакой opensource - замены смартколонкам хоть как то рабочей и удобной? Пусть без части продвинутого функционала? ну там - https://heywillow.io/ например?
TLDR: мы написали говнокод, когда были стартапом (скорее всего, когда уже не были), который никто потом не переписал нормально. А потом какой-то мега-сеньёр-восьмидесятого-уровня-умеющий-переворачивать-красночёрные-деревья-на-салфетке перепутал секунды и миллисекунды, поэтому мы стали опрашивать NTP раз в 5 секунд, а не раз в 5 часов. Тестов у нас, конечно же, нет, мы только спрашиваем о них лохов-джунов на собеседованиях. Свои публичные сервера NTP мы тоже не подняли, потому что мы нищеброды или нам лень. Или пох...й, этот момент нужно уточнить в PR-отделе.
Это показывает, как уязвим протокол и пуллы к ddos-у. Систему можно нагнуть, а страдать будут энтузиасты, на которых всё и держится.
Не это показывает какое рас##во в яндексе. https://habr.com/ru/companies/yandex/articles/861538/#comment_27606352
А так конечно все ошибаются, но так глупо и убого не все оправдываются, а так как яндекс один из лидеров отрасли на него ориентируются, вот ему и приходитится тут "терпеть".
А коменты это стена плача.
Ботнетом даже в несколько десятков тысяч устройств, у каждого из которых 100мбит/с канал можно заддосить что угодно.
Как то не задумывался даже что Яндекс может обновлять прошивку девайса удаленно без (я так понимаю) уведомления пользователя. А что еще вы можете с ней сделать?
Поэтому у меня в доме никогда не будет таких устройств. Польза сомнительна, зато компании типа яндекса всегда в курсе какого цвета трусики у вашей жены.
компании типа яндекса всегда в курсе какого цвета трусики у вашей жены
Лично меня больше всего смущает даже не столько то, что они могут прослушивать мои разговоры ради того чтобы впаривать мне контекстную рекламу (хотя это тоже), сколько то, что я за это еще и должен платить из своего кармана, так как колонка работает по подписке.
А как вы себе представляете запрос пользователя тут - где его запрашивать? голосом запрашивать чтоли или через приложение на телефоне? Допустим пользователь говорит нет то что делать? не давать работать дальше - так привет жалобы что перестало работать? заткнутся и работать? привет жалобы про проблемы из-за колонок если будут ну и бэк менять...сложно.
А допустим пользователь решить спросить техподдержку то что техподдержке делать?(с учетом что спросит явно не один пользователь).
Кстати а как быть если обновление требует перезапуска и уже перезапуск может стать проблемой? Вспоминается вот мои купленные умные "розетки" (не яндекс - яндекс мерять потребление штатными образом не умеет), там по умолчанию стоит автообновление ночью. Все бы ничего но в процессе перезапуска эти розетка снимает на некоторое время питание (почему - кстати вопрос) а подключены они у меня "после" UPS'а а перезапуск стойки по питанию мне совсем не нравится. Именно поэтому - автообновление отключено (там есть галочка, если бы ее не было - был бы вопрос поддержке как это устройство заставить работать в оффлайне, если никак - возврат с формулировкой вида "не работает, выключается самопроизвольно")
А как вы себе представляете запрос пользователя тут - где его запрашивать?
В смартфоне например? У меня ее на самом деле нет, но есть у жены. Она управляет ей со смарта. Там и запрашивать согласие на обновление, не? А еще колонка как бы умеет спрашивать сама. Может спросить, а заодно рассказать что обновится в новой прошивке, если пользователь попросит об этом.
Допустим пользователь говорит нет то что делать? не давать работать дальше
Почему не давать работать, она же как то работала до обновления?
Я как бы не против в целом то обновлений - но по моему пользователь должен быть хотя бы быть спрошен об этом, ну или минимально - уведомлен. И да, я не параноик, если что, но мы ж понимаем что девайс умеющий слушать происходящее вокруг и имеющий механизм silent-обновления - это потенциально весьма небезопасно. Там ребята NTP по нормальному реализовать не могут...
Предлагаю прочитать пользовательское соглашение. Уверен, там найдется много интересного.
Да и вообще, все устройства сейчас скорее передаются в использование на самообеспечение, чем продаются. Телефоны, автомобили, умные колонки. Не мы ими владеем, а они нашими данными, с нашего же согласия.
P.S. Кстати, интересно, на каком этапе пользователь принимает соглашение, когда покупает колонку? У меня таких устройств нету, поэтому даже не представляю.
А что еще вы можете с ней сделать?
Надо проверить, из чего сделан аккумулятор.
Поблагодарили тех, кто обратил внимание на проблему, но не поблагодарили тех, кто свои сервера добавил в пул для стабилизации ситуации…
Как раз помню недавно слив красных флагов из Яндекса и то и про отношение к сотрудникам из отрасли 'робототехника' , как раз с серверами нтп и проблемой времени сталкивались много раз, но видно не один из специалистов через красные флаги не пробился. Увы и ах, советские деды с заводов как оказалось на голову выше.
Работа со временем является одной из самых не простых задач в практике разработчика. Там много нюансов, про которые узнаешь только набив шишки или переняв опыт более опытных коллег.
У молодых как правило этого опыта нет, с чем сталкиваюсь на практике: напрочь забивают на часовые пояса, касяки с unixtime и прочие приколы. Например они не знают что часовой пояс в зависимости от года может отличаться.
Это постоянно порождает баги, которые очень просто выявляются в unit тестах, но у нас их нет! Так как молодежи не принято писать тесты, ибо за них это делает QA. Привет компании на букву S.
https://www.youtube.com/watch?v=-5wpm-gesOY
вот этот видос каждый, кто хочет связаться с временем, должен под конспект изучить.
А что за отношение к робототехникам? В Яндексе есть соответствующий отдел, значит отношение должно быть, как минимум, неплохим?
Выходит Яндекс провели нагрузочное тестирование инфраструктуры NTP рунета.
Ага, и американская компания Cloudflare его закерила, приняв 50 % нагрузки RU региона в период пика двумя своими NTP серверами, до того как тему осветили на Хабре.
Отличный индикатор того, чего стоят идеи о "суверенном чебурнете". Если бы его успели построить -- NTP бы в нем лёг.
Вот что хабр животворящий делает!
Интересно, если я напишу статью о том, как у одного банка торчат сорсы одного продукта голой жопой в интернеты, и банки успешно игнорирует мои обращения, они быстро починят всё?...)
Имхо, лучше написать с нового аккаунта "анонимно". Вдруг менеджеры банка прикроют свою ж.. и обвинят в взломе.
Да я всё же надеюсь получить ответ от банка, чтобы нормально им сообщить, подождать как положено несколько месяцев, а потом рассказать об этом общественности... Но что-то они видимо совсем не жаждят узнать подробностей таким путём.
"-А давайте мы выпустим коммерческое устройство и завалим запросами бесплатные чужие сервисы.
-А двайте!"
...
"Проклятые жадные капиталисты не хотят делать сервисы бесплатными и делают все API и запросы платными! Ах они проклятые капиталисты!"
NTP сервера поднимают не для того, чтобы ваш миллион колонок заваливал их запросами без необходимости. Если вам нужно каждые 5 часов получать точное время - поднимайте свои сервера и обращайтесь к ним, а не паразитируйте на чужой благотворительности.
Меня больше забавляет их желание высосать прибыль из всего чего только можно. Особенно это показательно в я.еде с их сервисным сбором на работу сервиса. Интересно, а под 30% от суммы заказа они себе забираю на какие цели? Не для работы сервиса?))
Выставлять цену - это как раз их право. Не важно как называется надбавка и сколько этих надбавок - только пользователь решает устраивает его цена или нет.
А вот когда они паразитируют на чужих ресурсах - это проблема. И проблема, в том числе, для честных пользователей, который в итоге лишаются ресурса, которым честно пользовались и не злоупотребляли.
То что они имеют право выставлять свою цену -- это да, я как пользователь сам решу устроит меня финальная цена или нет. Меня напрягает то, что они указывают мол, столько то мы возьмем за доставку с вас, столько то вы заплатите за то, чтобы сервис работал, но почему-то не указывают то, что они возьмут ещё 20-30% от суммы заказа! Недосказанность какая-то получается :)
Ну а паразитирование на чужих ресурсах... Ну, так этим все занимаются. Точнее, это даже сложно назвать паразитированием, т.к. серверы NTP публичные, и вроде бы их не запрещено использовать в коммерческих целях. А то так можно ещё натянуть то, что они паразитируют на опенсорсных решениях... Но тут в защиту яндекса я могу сказать что у них хорошие вещи есть, например общедоступный mirror.yandex.ru :)
Эти 20-30% - это их договоренность с поставщиком. Почему должны указывать?
Они не обязаны этого делать.
Но вы просто представьте, как было бы прекрасно, если такие вот капиталисты были бы полностью открыты перед своими клиентами, и рассказывали им, что мол мы не только с вас берем 5% на работу сервиса, но ещё и с поставщика берем!)
А еще сколько наценка на продукты, аренда здания, зарплата повара, аренда земли на которой вырастили огурец, стоимость полива, наценка водоканала, зарплата техника установившего насос в водонапорной башне, стоимость медной обмотки в насосе, зарплата шахтера добывшего медную руду, стоимость вагонетки на которой эту руду вывозили из шахты...
Совершенно не понимаю зачем вам эта информация о 30% и что вы с ней собираетесь делать.
Ну как минимум, значит локальная доставка дешевле на эти 30%. И я бы заказал в локальной доставке.
Если она есть вообще.
Если она нормально работает.
И еще много если.
Опять же, зачем вам знать об этих 30% чтобы посмотреть есть локальная доставка или нет?
Ну кстати да, не так давно думал о том, что надо бы заказать вкусненького. В итоге, увидал что в я.еде блюдо стоит ~750р, немного офигел, пошел посмотреть что там по своей доставке, нашел оффлайн меню заведения, где то же самое блюдо уже стоило 500р (но своей доставки не было).
В целом, для себя решил что позвонить и сделать заказ для самовывоза и прогуляться пол километра будет гораздо дешевле, чем заказывать в я.еде за 750р+199р доставка+59р работа сервиса...
Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.
Ай какие молодцы. Вы, как вендор, это обязаны были сделать изначально
If you are distributing an appliance, operating system or other kind of software using the NTP Pool, you need to setup a "vendor zone".
NTP is a service typically running quietly in the background. When servers are chosen they will typically remain in the configuration "forever". If the client traffic causes trouble for the server it is extremely difficult to mitigate if not carefully planned for in advance.
A couple of examples in the past years are Flawed Routers Flood University of Wisconsin Internet Time Server in 2003 and the D-Link misconfiguration incident in 2006.
You must get approval from the server operator before you hardcode any IP addresses or hostnames. This is easy to get if your own organization runs the NTP servers you are planning to use. In most other cases you will not get it.
Do not use the standard pool.ntp.org names as a default configuration in your system. The NTP Pool can offer services for you, but it must be setup in advance (see below).
Но почему-то не сделали. Не хотите рассказать почему?
А как часто мы читаем такие правила? Очень многие только лишь из этой дискуссии узнали, что для вендоров есть какие-то требования, связанные с использованием pool.ntp.org.
Кроме того, нужно учесть, что Яндекс делает определённые общественно полезные вещи, например, существует https://mirror.yandex.ru/ - то есть, Яндекс уменьшает трафик на серверы ряда дистрибутивов Linux, предоставляя своё зеркало. И наверняка этим Яндекс вложился гораздо больше, чем использовал трафика на сервера NTP.
Ну я вот, ещё до добавления сервера в пул почитал правила, например.
И по его использованию тоже почитал, а то вдруг не стоит китайские камеры на него натравливать, даже раз в 10 часов. Ну я, в целом и не использую, если роутер умеет быть NTP сервером. Все камеры натравлены на него, а на роутере, как правило какой-то клон ntpd, который умеет оценивать точность хода часов и снижать запросы к внешним серверам до минимума.
Чтение правил - дело полезное, за это плюс в карму :-) Но в целом, подозреваю, многие просто не интересовались, откуда вообще берутся сервера NTP, по крайней мере лично я не знал, что эта система зависит от энтузиастов, поднимающих свои сервера точного времени, и что их не так уж и много (даже сейчас их меньше 300 на всю страну, причём это уже после того, как возникла проблема и многие подключились, чтобы исправить последствия).
Большинство пользователей ntppool юзать не будут. Они купят гаджет, ноут, планшет, компьютер (нужное подчеркнуть) и будут пользоваться. За них все уже сделали вендоры, не постеснявшиеся развернуть свои кластеры NTP-серверов для своих же клиентов с запасом прочности (time.google.com, time.apple.com, time.windows.com). Давно прошли времена Windows XP, которая синхронизировала время 1 раз в неделю. НЕДЕЛЮ, КАРЛ! А тот же time.windows.com банально просто мог быть недоступен. 2.android.pool.ntp.org еще даже гуглится, хотя вряд ли вы его увидите в логах сетевых подключений в конце 2024.
Но суть дела меняется, когда речь заходит о технических специалистах, знающих что такое ntpd, и для чего они собираются его использовать, что реестр Windows дает значительные больший полет для фантазии чем, одна строчка с выбором «сервера времени» в интерфейсе ОС. И вот уже этим специалистам вопрос о чтении правил можно задать вполне обоснованно.
з.ы. Зону RU положили не "многие". Зону RU положил "узкий круг ограниченных людей".
Яндекс уменьшает трафик на серверы ряда дистрибутивов Linux, предоставляя своё зеркало. И наверняка этим Яндекс вложился гораздо больше, чем использовал трафика на сервера NTP.
А как это между собой связано?
Скандалы, интриги, расследования. Спасибо за интересное раскрытие дела)
Жирный плюсик в карму :)
А почему яндекс не использует свой же ntp.yandex.ru?
На графике нет 10% падения трафика. Возможно, что сразу раскатали как только стали отваливатся сервисы колонки, зависящие от времени.
Ну с этим разобрались, теперь давайте разбираться вот с этими запросами. Сразу говорю эти запросы у меня блокируются уже около года и претензий к работе Станции мини нет, делаю вывод - они нафиг не нужны.
И да это запросы именно от Яндекс Станции мини, я проверял
В статье описано, что высокая точность по времени - это обязательное условие для выполнения бизнес-требования, чтобы активация/контрактивация происходила на ближайшей/удаленной станции.
Но если у большинства пользователей - одна колонка, то им такая высокая точность не нужна.
Там же не просто так слово «например» :) Это один из примеров.
В статье попахивает художественным вымыслом маркетологов. Для синхронизации колонок намного легче и точнее будет использование громкости. Предвкушая вопрос, а как чувствительность микрофонов разных версий железяк калибровать - пишем в инструкцию, что если вы купили доп колонку, то ставим все колонки в кружок, а посередине кладём телефон с какой-нибудь записью. И на мой взгляд, проблемы вообще нет - должна отвечать одна и такая, чтобы было слышно, а не ближайшая. На самом деле, так и происходит, никто не будет проверять, находясь где-то между двумя, что ответила ближайшая. Так что нужно попросить @slavashelуточнить, зачем все-таки вам точное время :)
Тут есть ещё нюанс. В попытках борьбы с этим DDoS часть альтернативно одарённых администраторов вместо того чтобы резать исходящие запросы, начала резать входящие ответы от ntp-серверов. В результате чего, вполне нормальные ntp-клиенты мечутся по всему пулу, пытаясь узнать точное время. Ntp-серверы время им отдают, но до клиентов это время не доходит, например, около 48% ответов моего сервера реджектятся с icmp unreachable. Сколько просто дропается, мне неизвестно.
Было бы справедливо, если бы после этого Yandex взял на себя разборки с такими провайдерами. Думаю, Yandex'у будет проще преодолевать первые линии поддержки провайдеров, чем конечным пользователям. А технический инструмент для выявления таких ситуаций Yandex практически есть - это их собственный ботнет.
То есть Яндекс на халяву присосался к чужим серверам и дудосил их до усрачки, пока они в протест просто не отключились все, лишь бы не тратить ресурсы своих серверов на обеспечение критической инфраструктуры своим платным облачным колонкам.
П.с. создание высоточных часов с заданным отклонением никогда не было проблемой ч просто стоит денег как в разработке, так и в реализации в железе. Очень эффективный менеджмент.
П.п.с. если бы пул нтп был чуточку больше, о халявщиках могли бы и не узнать, а если бы был ещё меньше, то начали бы убивать глобальные нтп серваки, спровоцировав международные разборки.
П.п.с. если бы пул нтп был чуточку больше, о халявщиках могли бы и не узнать, а если бы был ещё меньше, то начали бы убивать глобальные нтп серваки, спровоцировав международные разборки.
Да 11 числа этот "инцидент" уже вышел в публичную плоскость но помогло это мало У Яндекса "всё штатно" было 11 ноября
https://t.me/nag_public/713756
https://habr.com/ru/companies/yandex/articles/762678/ - забавно, но примерно год назад от Яндекса же была обширная статья про то, как правильно делать ретраи.
Судя по тому, что произошло с NTP - до воплощения это так и не дошло?
Спасибо за статью, это весьма поучительный опыт.
Если же ответ до устройства по каким‑то причинам не доходил (или колонка была перезагружена), клиент перезапрашивал информацию с других серверов каждые пять секунд до тех пор, пока не узнавал время.
Это простой алгоритм, но, если я правильно понимаю, RFC 4330, на который ссылается ntp.org, так делать не рекомендует.
1. A client MUST NOT under any conditions use a poll interval less than 15 seconds.
2. A client SHOULD increase the poll interval using exponential backoff as performance permits and especially if the server does not respond within a reasonable time.
Наверное введение экспоненциальной задержки уменьшило бы масштаб проблемы.
На самом деле не очень понятно, зачем понадобилось писать свой клиент, вместо использования какого-нибудь opensource, который точно соответствует RFC.
Яндекс ,а не лучше ли вместо NTP считать как быстро волна звука доходит до колонки и отвечать на той, где волна дошла быстрее? Зачем сложности с NTP?
У меня дома есть монитор трафика, который показывает, сколько раз какие устройства стучатся во внешнюю сеть. И я был удивлен, когда узнал, что две колонки от Яндекса отправляют по 1 миллиону запросов на сайт ru.pool.ntp.org за 15 дней. Периодически они отправляли разные типы запросов в 1 секунду, периодически отправляли один и тот же запрос до 5 раз в секунду.
Сейчас количество запросов не уменьшились, но запросы стали обращаться к другим доменам: scbh.yandex.net и clck.yandex.net.
Так что абсолютно не удивительно, что возникли такие проблемы, если это был такой коллективный дудос со всех колонок, то я вообще удивлен, что pool не упал с ошибкой без возможности поднятия.
Скрытый текст
Хотелось бы получить комментарии от Яндекс, почему их станция опрашивает ntp-сервера, а когда к ней от них приходит ответ, она плюёт в них ICMP Unreachable?
Лог под спойлером:
Скрытый текст
23:06:33.926112 IP (tos 0xc0, ttl 64, id 2976, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 188.246.226.6: ICMP 192.168.64.191 udp port 47341 unreachable, length 84
IP (tos 0x20, ttl 55, id 27708, offset 0, flags [DF], proto UDP (17), length 76)
188.246.226.6.123 > 192.168.64.191.47341: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -26
Root Delay: 0.001358, Root dispersion: 0.000808, Reference-ID: 0xc2bea801
Reference Timestamp: 3942143640.222680021 (2024-12-02T15:54:00Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942144393.901440913 (2024-12-02T16:06:33Z)
Transmit Timestamp: 3942144393.901446344 (2024-12-02T16:06:33Z)
Originator - Receive Timestamp: 3942144393.901440913 (2024-12-02T16:06:33Z)
Originator - Transmit Timestamp: 3942144393.901446344 (2024-12-02T16:06:33Z)
23:06:33.940059 IP (tos 0xc0, ttl 64, id 39983, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 51.250.107.88: ICMP 192.168.64.191 udp port 58025 unreachable, length 84
IP (tos 0x20, ttl 50, id 14286, offset 0, flags [DF], proto UDP (17), length 76)
51.250.107.88.123 > 192.168.64.191.58025: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 3 (8s), precision -25
Root Delay: 0.008804, Root dispersion: 0.001739, Reference-ID: 0x596dfb1a
Reference Timestamp: 3942142980.958716723 (2024-12-02T15:43:00Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942144393.908478485 (2024-12-02T16:06:33Z)
Transmit Timestamp: 3942144393.908500012 (2024-12-02T16:06:33Z)
Originator - Receive Timestamp: 3942144393.908478485 (2024-12-02T16:06:33Z)
Originator - Transmit Timestamp: 3942144393.908500012 (2024-12-02T16:06:33Z)
23:06:33.963512 IP (tos 0xc0, ttl 64, id 53983, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 193.35.49.242: ICMP 192.168.64.191 udp port 39065 unreachable, length 84
IP (tos 0x20, ttl 54, id 34404, offset 0, flags [DF], proto UDP (17), length 76)
193.35.49.242.123 > 192.168.64.191.39065: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -20
Root Delay: 0.070693, Root dispersion: 0.049606, Reference-ID: 0xc0248f82
Reference Timestamp: 3942143946.000000000 (2024-12-02T15:59:06Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942144393.914796999 (2024-12-02T16:06:33Z)
Transmit Timestamp: 3942144393.914819999 (2024-12-02T16:06:33Z)
Originator - Receive Timestamp: 3942144393.914796999 (2024-12-02T16:06:33Z)
Originator - Transmit Timestamp: 3942144393.914819999 (2024-12-02T16:06:33Z)
04:06:34.270928 IP (tos 0xc0, ttl 64, id 2133, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 79.137.192.63: ICMP 192.168.64.191 udp port 54580 unreachable, length 84
IP (tos 0x20, ttl 54, id 24305, offset 0, flags [DF], proto UDP (17), length 76)
79.137.192.63.123 > 192.168.64.191.54580: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 3 (8s), precision -26
Root Delay: 0.003509, Root dispersion: 0.000839, Reference-ID: 0x596dfb1a
Reference Timestamp: 3942162088.402888024 (2024-12-02T21:01:28Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942162394.244022989 (2024-12-02T21:06:34Z)
Transmit Timestamp: 3942162394.244032805 (2024-12-02T21:06:34Z)
Originator - Receive Timestamp: 3942162394.244022989 (2024-12-02T21:06:34Z)
Originator - Transmit Timestamp: 3942162394.244032805 (2024-12-02T21:06:34Z)
04:06:34.274762 IP (tos 0xc0, ttl 64, id 49358, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 45.92.177.52: ICMP 192.168.64.191 udp port 45240 unreachable, length 84
IP (tos 0x20, ttl 55, id 17452, offset 0, flags [DF], proto UDP (17), length 76)
45.92.177.52.123 > 192.168.64.191.45240: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -26
Root Delay: 0.001449, Root dispersion: 0.000366, Reference-ID: 0xc2bea801
Reference Timestamp: 3942162116.701414259 (2024-12-02T21:01:56Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942162394.238994932 (2024-12-02T21:06:34Z)
Transmit Timestamp: 3942162394.239001284 (2024-12-02T21:06:34Z)
Originator - Receive Timestamp: 3942162394.238994932 (2024-12-02T21:06:34Z)
Originator - Transmit Timestamp: 3942162394.239001284 (2024-12-02T21:06:34Z)
04:06:34.276807 IP (tos 0xc0, ttl 64, id 17876, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 91.206.16.3: ICMP 192.168.64.191 udp port 52495 unreachable, length 84
IP (tos 0x20, ttl 53, id 58800, offset 0, flags [DF], proto UDP (17), length 76)
91.206.16.3.123 > 192.168.64.191.52495: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 0 (1s), precision -26
Root Delay: 0.000030, Root dispersion: 0.000030, Reference-ID: GPS^@
Reference Timestamp: 3942162393.346687264 (2024-12-02T21:06:33Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942162394.232296948 (2024-12-02T21:06:34Z)
Transmit Timestamp: 3942162394.232302361 (2024-12-02T21:06:34Z)
Originator - Receive Timestamp: 3942162394.232296948 (2024-12-02T21:06:34Z)
Originator - Transmit Timestamp: 3942162394.232302361 (2024-12-02T21:06:34Z)
09:06:34.973246 IP (tos 0xc0, ttl 64, id 45597, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 62.173.141.123: ICMP 192.168.64.191 udp port 53383 unreachable, length 84
IP (tos 0x20, ttl 56, id 26853, offset 0, flags [DF], proto UDP (17), length 76)
62.173.141.123.123 > 192.168.64.191.53383: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 2 (4s), precision -25
Root Delay: 0.014083, Root dispersion: 0.002807, Reference-ID: 0x4e9e102b
Reference Timestamp: 3942179951.103150354 (2024-12-03T01:59:11Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942180394.919304466 (2024-12-03T02:06:34Z)
Transmit Timestamp: 3942180394.919325697 (2024-12-03T02:06:34Z)
Originator - Receive Timestamp: 3942180394.919304466 (2024-12-03T02:06:34Z)
Originator - Transmit Timestamp: 3942180394.919325697 (2024-12-03T02:06:34Z)
09:06:35.005469 IP (tos 0xc0, ttl 64, id 58174, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 188.225.9.167: ICMP 192.168.64.191 udp port 42463 unreachable, length 84
IP (tos 0x20, ttl 55, id 10623, offset 0, flags [DF], proto UDP (17), length 76)
188.225.9.167.123 > 192.168.64.191.42463: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -25
Root Delay: 0.010833, Root dispersion: 0.000259, Reference-ID: 0x596dfb15
Reference Timestamp: 3942180217.190864693 (2024-12-03T02:03:37Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942180394.922968779 (2024-12-03T02:06:34Z)
Transmit Timestamp: 3942180394.922994778 (2024-12-03T02:06:34Z)
Originator - Receive Timestamp: 3942180394.922968779 (2024-12-03T02:06:34Z)
Originator - Transmit Timestamp: 3942180394.922994778 (2024-12-03T02:06:34Z)
09:06:35.011502 IP (tos 0xc0, ttl 64, id 26096, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 151.0.2.54: ICMP 192.168.64.191 udp port 33538 unreachable, length 84
IP (tos 0x20, ttl 55, id 13070, offset 0, flags [DF], proto UDP (17), length 76)
151.0.2.54.123 > 192.168.64.191.33538: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -25
Root Delay: 0.025955, Root dispersion: 0.001037, Reference-ID: 0x596dfb1a
Reference Timestamp: 3942179791.738304313 (2024-12-03T01:56:31Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942180394.928560089 (2024-12-03T02:06:34Z)
Transmit Timestamp: 3942180394.928595615 (2024-12-03T02:06:34Z)
Originator - Receive Timestamp: 394
А можно поподробнее, где там написано, почему они не воспринимают ответ на запрос, и не просто игнорируют ответ, а еще и оправляют в ответ ICMP port unreachable? Если что, это происходит уже на свежей прошивке, с увеличенным до 600 секунд периодом запроса.
Может быть надо в комментах там спросить? И насколько я помню эту статью, увеличенный до 600 секунд период обновления, это хотфикс или даже скорее хак , который они сделали чтоб хоть чуть чуть смягчить сложившуюся ситуацию.
P.S. Интересно, а какой из минусов ваш? :)
сегодня в 01:55
-1 Неконструктивное общение. Личная неприязнь
вчера в 23:01
-1 Грубое общение. Неконструктивное общение
Просто предыдущий комментарий был неделю назад, и навряд ли эти оценки связаны с ним ;)
Может быть надо в комментах там спросить?
Так вот и спрашиваю "там", так как ваша ссылка именно сюда и ведёт:
https://habr.com/ru/companies/yandex/articles/861538/
Вот и решение загадки, "Shit happens". Я думал, что отвечаю на комментарий к статье "Сетевой тролль по имени яндекс-алиса", перепутал вкладки с этой статьей (возможно была открыта дублирующая вкладка с этой статьёй). Поэтому и ответил односложно, фактически приведя только ссылку, без всякой эмоциональной нагрузки, просто на обсуждение возможно связанной ситуации.
Но вместо простого ответа "Вы ошиблись, ваша ссылка указывает именно на эту статью где мы сейчас находимся!", после которого я посыпал бы голову пеплом и извинился за свои глаза с -7,5 с астигматизмом, вы решили выплеснуть на меня свою боль и гнев, как будто бы я тот самый накосячивший сотрудник компании Яндекс. Только почему вы так решили? "Shit happens"? Так это случается со всеми, от этого никто не застрахован. Ни Вы, ни я. Это жизнь. Без всякой эмоциональной нагрузки.
есть уверенность что это именно станция? Дамп снят непосредственно с линка станции? Если нет, это вполне может быть и поведение роутера, а станция внутри за натом ответа так и не получила. Избавиться от этих ICMP на сверере тоже хочется :)
Уверенность есть. Судя по трафику от станции, RFC дальше формата пакета они вообще не читали. Под катом более детальный лог:
Скрытый текст
09:19:17.323183 IP (tos 0x0, ttl 64, id 32563, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.50036 > 195.35.71.4.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 17.415011173 (1900-01-01T00:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -17.415011173
Originator - Transmit Timestamp: -17.415011173
09:19:17.325956 IP (tos 0x20, ttl 58, id 41229, offset 0, flags [DF], proto UDP (17), length 76)
195.35.71.4.123 > 192.168.64.191.50036: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 4 (16s), precision -24
Root Delay: 0.000015, Root dispersion: 0.000015, Reference-ID: GPS0
Reference Timestamp: 3942353954.471630904 (2024-12-05T02:19:14Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942353957.324513870 (2024-12-05T02:19:17Z)
Transmit Timestamp: 3942353957.324536927 (2024-12-05T02:19:17Z)
Originator - Receive Timestamp: 3942353957.324513870 (2024-12-05T02:19:17Z)
Originator - Transmit Timestamp: 3942353957.324536927 (2024-12-05T02:19:17Z)
09:19:17.411028 IP (tos 0x0, ttl 64, id 32565, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.50036 > 195.35.71.4.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 17.420375756 (1900-01-01T00:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -17.420375756
Originator - Transmit Timestamp: -17.420375756
09:19:17.413154 IP (tos 0x20, ttl 58, id 41238, offset 0, flags [DF], proto UDP (17), length 76)
195.35.71.4.123 > 192.168.64.191.50036: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 4 (16s), precision -24
Root Delay: 0.000015, Root dispersion: 0.000015, Reference-ID: GPS0
Reference Timestamp: 3942353954.471630904 (2024-12-05T02:19:14Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942353957.411740924 (2024-12-05T02:19:17Z)
Transmit Timestamp: 3942353957.411759268 (2024-12-05T02:19:17Z)
Originator - Receive Timestamp: 3942353957.411740924 (2024-12-05T02:19:17Z)
Originator - Transmit Timestamp: 3942353957.411759268 (2024-12-05T02:19:17Z)
09:19:17.421226 IP (tos 0x0, ttl 64, id 32567, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.50036 > 195.35.71.4.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 17.513490423 (1900-01-01T00:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -17.513490423
Originator - Transmit Timestamp: -17.513490423
09:19:17.423275 IP (tos 0x20, ttl 58, id 41239, offset 0, flags [DF], proto UDP (17), length 76)
195.35.71.4.123 > 192.168.64.191.50036: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 4 (16s), precision -24
Root Delay: 0.000015, Root dispersion: 0.000015, Reference-ID: GPS0
Reference Timestamp: 3942353954.471630904 (2024-12-05T02:19:14Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942353957.421950871 (2024-12-05T02:19:17Z)
Transmit Timestamp: 3942353957.421971004 (2024-12-05T02:19:17Z)
Originator - Receive Timestamp: 3942353957.421950871 (2024-12-05T02:19:17Z)
Originator - Transmit Timestamp: 3942353957.421971004 (2024-12-05T02:19:17Z)
09:19:17.425252 IP (tos 0x0, ttl 64, id 32568, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.50036 > 195.35.71.4.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 17.517025173 (1900-01-01T00:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -17.517025173
Originator - Transmit Timestamp: -17.517025173
09:19:17.427357 IP (tos 0x20, ttl 58, id 41240, offset 0, flags [DF], proto UDP (17), length 76)
195.35.71.4.123 > 192.168.64.191.50036: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 4 (16s), precision -24
Root Delay: 0.000015, Root dispersion: 0.000015, Reference-ID: GPS0
Reference Timestamp: 3942353954.471630904 (2024-12-05T02:19:14Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942353957.425995252 (2024-12-05T02:19:17Z)
Transmit Timestamp: 3942353957.426016141 (2024-12-05T02:19:17Z)
Originator - Receive Timestamp: 3942353957.425995252 (2024-12-05T02:19:17Z)
Originator - Transmit Timestamp: 3942353957.426016141 (2024-12-05T02:19:17Z)
09:19:17.511293 IP (tos 0x0, ttl 64, id 32569, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.50036 > 195.35.71.4.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 17.521868923 (1900-01-01T00:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -17.521868923
Originator - Transmit Timestamp: -17.521868923
09:19:17.513454 IP (tos 0x20, ttl 58, id 41257, offset 0, flags [DF], proto UDP (17), length 76)
195.35.71.4.123 > 192.168.64.191.50036: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 4 (16s), precision -24
Root Delay: 0.000015, Root dispersion: 0.000015, Reference-ID: GPS0
Reference Timestamp: 3942353954.471630904 (2024-12-05T02:19:14Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942353957.512013175 (2024-12-05T02:19:17Z)
Transmit Timestamp: 3942353957.512031272 (2024-12-05T02:19:17Z)
Originator - Receive Timestamp: 3942353957.512013175 (2024-12-05T02:19:17Z)
Originator - Transmit Timestamp: 3942353957.512031272 (2024-12-05T02:19:17Z)
09:19:17.614896 IP (tos 0x0, ttl 64, id 32576, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.50036 > 195.35.71.4.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 17.624096673 (1900-01-01T00:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -17.624096673
Originator - Transmit Timestamp: -17.624096673
09:19:17.617294 IP (tos 0x20, ttl 58, id 41276, offset 0, flags [DF], proto UDP (17), length 76)
195.35.71.4.123 > 192.168.64.191.50036: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 4 (16s), precision -24
Root Delay: 0.000015, Root dispersion: 0.000015, Reference-ID: GPS0
Reference Timestamp: 3942353954.471630904 (2024-12-05T02:19:14Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942353957.615951857 (2024-12-05T02:19:17Z)
Transmit Timestamp: 3942353957.615969961 (2024-12-05T02:19:17Z)
Originator - Receive Timestamp: 3942353957.615951857 (2024-12-05T02:19:17Z)
Originator - Transmit Timestamp: 3942353957.615969961 (2024-12-05T02:19:17Z)
09:19:17.715271 IP (tos 0xc0, ttl 64, id 9694, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 195.35.71.4: ICMP 192.168.64.191 udp port 50036 unreachable, length 84
IP (tos 0x20, ttl 58, id 41276, offset 0, flags [DF], proto UDP (17), length 76)
195.35.71.4.123 > 192.168.64.191.50036: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 1 (primary reference), poll 4 (16s), precision -24
Root Delay: 0.000015, Root dispersion: 0.000015, Reference-ID: GPS0
Reference Timestamp: 3942353954.471630904 (2024-12-05T02:19:14Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942353957.615951857 (2024-12-05T02:19:17Z)
Transmit Timestamp: 3942353957.615969961 (2024-12-05T02:19:17Z)
Originator - Receive Timestamp: 3942353957.615951857 (2024-12-05T02:19:17Z)
Originator - Transmit Timestamp: 3942353957.615969961 (2024-12-05T02:19:17Z)
14:19:17.935170 IP (tos 0x0, ttl 64, id 22115, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.53949 > 212.113.99.6.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 18017.822856922 (1900-01-01T05:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -18017.822856922
Originator - Transmit Timestamp: -18017.822856922
14:19:17.935605 IP (tos 0x0, ttl 64, id 31554, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.58720 > 162.159.200.123.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 18017.823073005 (1900-01-01T05:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -18017.823073005
Originator - Transmit Timestamp: -18017.823073005
14:19:17.935635 IP (tos 0x0, ttl 64, id 13489, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.43318 > 185.209.85.222.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 18017.823187464 (1900-01-01T05:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -18017.823187464
Originator - Transmit Timestamp: -18017.823187464
14:19:17.935951 IP (tos 0x0, ttl 64, id 33063, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.43332 > 5.178.87.94.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 18017.823271922 (1900-01-01T05:00:17Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -18017.823271922
Originator - Transmit Timestamp: -18017.823271922
14:19:17.979383 IP (tos 0x20, ttl 56, id 53584, offset 0, flags [DF], proto UDP (17), length 76)
5.178.87.94.123 > 192.168.64.191.43332: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -26
Root Delay: 0.001174, Root dispersion: 0.000503, Reference-ID: 0xc2bea801
Reference Timestamp: 3942371517.579242356 (2024-12-05T07:11:57Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942371957.956741811 (2024-12-05T07:19:17Z)
Transmit Timestamp: 3942371957.956749275 (2024-12-05T07:19:17Z)
Originator - Receive Timestamp: 3942371957.956741811 (2024-12-05T07:19:17Z)
Originator - Transmit Timestamp: 3942371957.956749275 (2024-12-05T07:19:17Z)
14:19:17.984834 IP (tos 0x20, ttl 54, id 40206, offset 0, flags [DF], proto UDP (17), length 76)
185.209.85.222.123 > 192.168.64.191.43318: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -25
Root Delay: 0.003082, Root dispersion: 0.000473, Reference-ID: 0x596dfb17
Reference Timestamp: 3942371722.637936447 (2024-12-05T07:15:22Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942371957.960024664 (2024-12-05T07:19:17Z)
Transmit Timestamp: 3942371957.960514295 (2024-12-05T07:19:17Z)
Originator - Receive Timestamp: 3942371957.960024664 (2024-12-05T07:19:17Z)
Originator - Transmit Timestamp: 3942371957.960514295 (2024-12-05T07:19:17Z)
14:19:17.985983 IP (tos 0xc0, ttl 64, id 15223, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 185.209.85.222: ICMP 192.168.64.191 udp port 43318 unreachable, length 84
IP (tos 0x20, ttl 54, id 40206, offset 0, flags [DF], proto UDP (17), length 76)
185.209.85.222.123 > 192.168.64.191.43318: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -25
Root Delay: 0.003082, Root dispersion: 0.000473, Reference-ID: 0x596dfb17
Reference Timestamp: 3942371722.637936447 (2024-12-05T07:15:22Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942371957.960024664 (2024-12-05T07:19:17Z)
Transmit Timestamp: 3942371957.960514295 (2024-12-05T07:19:17Z)
Originator - Receive Timestamp: 3942371957.960024664 (2024-12-05T07:19:17Z)
Originator - Transmit Timestamp: 3942371957.960514295 (2024-12-05T07:19:17Z)
14:19:17.987429 IP (tos 0x20, ttl 56, id 53719, offset 0, flags [DF], proto UDP (17), length 76)
162.159.200.123.123 > 192.168.64.191.58720: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 3 (secondary reference), poll 0 (1s), precision -26
Root Delay: 0.019302, Root dispersion: 0.000213, Reference-ID: 0x0a88086f
Reference Timestamp: 3942371956.147274201 (2024-12-05T07:19:16Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942371957.960021172 (2024-12-05T07:19:17Z)
Transmit Timestamp: 3942371957.960091119 (2024-12-05T07:19:17Z)
Originator - Receive Timestamp: 3942371957.960021172 (2024-12-05T07:19:17Z)
Originator - Transmit Timestamp: 3942371957.960091119 (2024-12-05T07:19:17Z)
14:19:17.987705 IP (tos 0x20, ttl 54, id 10570, offset 0, flags [DF], proto UDP (17), length 76)
212.113.99.6.123 > 192.168.64.191.53949: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -23
Root Delay: 0.005172, Root dispersion: 0.026794, Reference-ID: 0x596dfb18
Reference Timestamp: 3942371298.169826073 (2024-12-05T07:08:18Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942371957.961497345 (2024-12-05T07:19:17Z)
Transmit Timestamp: 3942371957.961577041 (2024-12-05T07:19:17Z)
Originator - Receive Timestamp: 3942371957.961497345 (2024-12-05T07:19:17Z)
Originator - Transmit Timestamp: 3942371957.961577041 (2024-12-05T07:19:17Z)
14:19:17.989257 IP (tos 0xc0, ttl 64, id 37255, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 162.159.200.123: ICMP 192.168.64.191 udp port 58720 unreachable, length 84
IP (tos 0x20, ttl 56, id 53719, offset 0, flags [DF], proto UDP (17), length 76)
162.159.200.123.123 > 192.168.64.191.58720: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 3 (secondary reference), poll 0 (1s), precision -26
Root Delay: 0.019302, Root dispersion: 0.000213, Reference-ID: 0x0a88086f
Reference Timestamp: 3942371956.147274201 (2024-12-05T07:19:16Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942371957.960021172 (2024-12-05T07:19:17Z)
Transmit Timestamp: 3942371957.960091119 (2024-12-05T07:19:17Z)
Originator - Receive Timestamp: 3942371957.960021172 (2024-12-05T07:19:17Z)
Originator - Transmit Timestamp: 3942371957.960091119 (2024-12-05T07:19:17Z)
14:19:17.995232 IP (tos 0xc0, ttl 64, id 9049, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 212.113.99.6: ICMP 192.168.64.191 udp port 53949 unreachable, length 84
IP (tos 0x20, ttl 54, id 10570, offset 0, flags [DF], proto UDP (17), length 76)
212.113.99.6.123 > 192.168.64.191.53949: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -23
Root Delay: 0.005172, Root dispersion: 0.026794, Reference-ID: 0x596dfb18
Reference Timestamp: 3942371298.169826073 (2024-12-05T07:08:18Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3942371957.961497345 (2024-12-05T07:19:17Z)
Transmit Timestamp: 3942371957.961577041 (2024-12-05T07:19:17Z)
Originator - Receive Timestamp: 3942371957.961497345 (2024-12-05T07:19:17Z)
Originator - Transmit Timestamp: 3942371957.961577041 (2024-12-05T07:19:17Z)
Суда по анализу трафика на моём NTP-сервере, обилие ICMP не только от точек доступа. Соотношение ICMP/NTP-ответов растёт днём - вряд ли кто-то станции ночью выключает. Плюс, ICMP иногда прилетают с адресов CGNAT провайдеров - вряд ли кто-то точки там размещает. Таким образом, выглядит это как определённое рукожопие от провайдеров и администраторов конторских сетей - где-то псевдоинтеллектуальный фаервол воспринял это как атаку и начал резать ответы, вместо запросов, где-то администраторы такое же придумали в ручном режиме, где-то могли подрезать размеры таблиц statefull nat для NTP, чтобы NTP их не выжирал, и клиенты хоть как-то жили.
Таким образом, выглядит это как определённое рукожопие от провайдеров и администраторов конторских сетей - где-то псевдоинтеллектуальный фаервол воспринял это как атаку и начал резать ответы, вместо запросов, где-то администраторы такое же придумали в ручном режиме, где-то могли подрезать размеры таблиц statefull nat для NTP, чтобы NTP их не выжирал, и клиенты хоть как-то жили.
я примерно такого мнения. Насчёт фаерволов и правил, написанных администраторами я думаю что они бы делали просто молчаливый дроп, реджектить с icmp всякий флуд ни к чему. С другой стороны я видел множество весьма странно себя ведущих soho роутеров и уже ничему не удивлюсь. Встречаются экземпляры которые услышав броадкастовый arp reqeuest с адресом не из своей подсети начинают валить в ответ icmp redirect O_o.
Серые/CGNAT и RFC6890 можно смело дропать, отвечать на них не надо (исключение - серые внутри своего провайдера и локалки, да и то можно с ограничениями по ttl).
Надо учитывать что роутинг/форвардинг работает по dst и далеко не все фильтруют src. Поэтому запрос с серым src может прилететь с другого конца шарика. А ответ улетит куда-то к ближайшему по роутингу хосту с таким Ip и будет его "заваливать незапрошенным мусором" на который он тоже может прислать icmp unreach. Поэтому лучше сразу их дропать и не пытаться эти запросы обрабатывать сервером и слать ответы.
Вопрос как в iptables залезть внутрь icmp чтобы считать оттуда какой host unreach (icmp source и указанный в нём host unreach могут отличаться если пакет прибили где-то на транзите) чтобы его тоже добавить в блок и не отвечать некоторое время.
Про чтение ntp'шного rfc - писатели не читатели :) Их клиент по описанию похож на sntp и там может быть что угодно. Я вот rfc тоже не читал. На деле криво заполненные поля запроса это не сказать что прям беда-беда. В то-же время некоторые сервера типа ntpsec могут просто дропать не-RFC'шно сформированные запросы. Значит будут колоночки тупить. Штош.
Для чистоты эксперимента надо всё-же разобраться кто шлёт эти icmp - сама колонка или нет. Пока неясно.
Серые/CGNAT и RFC6890 можно смело дропать
Я имел ввиду, что в ряде случаев транзитный хост с серым IP генерирует ICMP сообщения.
очень мало ICMP в которых src ip не совпадает с указанным в icmp айпишником недостижимого хоста. Тех в которых они совпадают процентов 90 а то и все 99. Может быть иногда волнами прилетает несовпадающие (как пул отресолвит кому-то ip моего сервера) но всё-же их мало.
А вот запросов с special purpose адресов хватает. Я у себя смотрел дампы (и сейчас перепроверил). Например дампим два варианта
icmp and net 100.64.0.0/10
port 123 and net 100.64.0.0/10
за минуту мне не пришло ни одного icmp из этой сетки и под сотню запросов на 123 порт. Отвечаем, наш ответ улетает куда-то по роутингу и часто на такой ответ мы получаем icmp о закрытом порте, например. Это одна из причин получения лишних icmp на сервер. Малая часть icmp, на которую мы можем напрямую повлиять со стороны сервера, просто отсекая запросы из таких подсетей.
Ждём когда Яндекс поднимет свои сервера и озаботится проблемой icmp :-)
Ещё помониторили трафик с Яндекс-станции. Стойкое ощущение, что она выплёвывает пачку запросов, как только набирает нужное ей количество ответов, закрывает сокеты, в итоге оставшиеся ответы "бьются в закрытую дверь", вызывая ICMP port unreachable.
похожее поведение у какого-то популярного dns-клиента-сервера в soho роутерах. Кажется это dnsmasq но это не точно. Там прямо в мануале написано что для скорости ресолва (клиет же не может подождать дополнительные 10мс!!!!) он шлёт запрос сразу ко всем серверам которые знает и довольствуется первым ответом, закрывая сокет. Соотв-но на все остальные пришедшие от днсов ответы линух роутера шлёт icmp port unreach. И авторы не считают это чем-то плохим. Лавров.жпг, как говорится.
Прошло уже больше месяца, так что возникает вопрос о прогресе по этим пунктам:
Поэтому мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.
Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.
Или, это были пустые обещания, Яндекс? Кстати, RTT не является ключевым фактором качества, ключевым фактором является симметрия время пути "туда" и времени "пути" обратно, но для задачи синхронизации двух колонок между собой и это излишне.
Что точно не поменялось, так это потребительское отношение к чужим ресурсам при сетевом обмене с ntp-серверами - свинью за стол, она и лапы на стол. Во время каждого сеанса синхронизации времени станция выплевывает пачку запросов, получив первый ответ, закрывает сокеты. Когда приходят другие ответы, в сторону ntp-серверов летит ICMP port unreachable. То есть, станции не только нагружают каналы ntp-серверов ненужными запросами, но ещё и ICMP-пакетами. Пример сетевого обмена:
Скрытый текст
08:24:37.633530 IP (tos 0x0, ttl 64, id 11245, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.60798 > 62.84.117.189.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 126023.845817840 (1900-01-02T11:00:23Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -126023.845817840
Originator - Transmit Timestamp: -126023.845817840
08:24:37.637385 IP (tos 0x0, ttl 64, id 34051, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.47442 > 92.241.12.152.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 126023.845995632 (1900-01-02T11:00:23Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -126023.845995632
Originator - Transmit Timestamp: -126023.845995632
08:24:37.637435 IP (tos 0x0, ttl 64, id 6631, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.46613 > 188.246.226.6.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 126023.846080173 (1900-01-02T11:00:23Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -126023.846080173
Originator - Transmit Timestamp: -126023.846080173
08:24:37.637639 IP (tos 0x0, ttl 64, id 5520, offset 0, flags [DF], proto UDP (17), length 76)
192.168.64.191.42357 > 51.250.35.68.123: [udp sum ok] NTPv4, Client, length 48
Leap indicator: clock unsynchronized (192), Stratum 0 (unspecified), poll 0 (1s), precision 0
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 126023.846172548 (1900-01-02T11:00:23Z)
Receive Timestamp: 0.000000000
Transmit Timestamp: 0.000000000
Originator - Receive Timestamp: -126023.846172548
Originator - Transmit Timestamp: -126023.846172548
08:24:37.678737 IP (tos 0x20, ttl 55, id 59717, offset 0, flags [DF], proto UDP (17), length 76)
188.246.226.6.123 > 192.168.64.191.46613: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -26
Root Delay: 0.008728, Root dispersion: 0.000762, Reference-ID: 0xc2bea801
Reference Timestamp: 3944078157.922822256 (2024-12-25T01:15:57Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3944078677.658072665 (2024-12-25T01:24:37Z)
Transmit Timestamp: 3944078677.658089284 (2024-12-25T01:24:37Z)
Originator - Receive Timestamp: 3944078677.658072665 (2024-12-25T01:24:37Z)
Originator - Transmit Timestamp: 3944078677.658089284 (2024-12-25T01:24:37Z)
08:24:37.687451 IP (tos 0x20, ttl 50, id 4932, offset 0, flags [DF], proto UDP (17), length 76)
62.84.117.189.123 > 192.168.64.191.60798: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 3 (8s), precision -25
Root Delay: 0.003372, Root dispersion: 0.000854, Reference-ID: 0xc2bea801
Reference Timestamp: 3944077884.143902239 (2024-12-25T01:11:24Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3944078677.660416851 (2024-12-25T01:24:37Z)
Transmit Timestamp: 3944078677.660432980 (2024-12-25T01:24:37Z)
Originator - Receive Timestamp: 3944078677.660416851 (2024-12-25T01:24:37Z)
Originator - Transmit Timestamp: 3944078677.660432980 (2024-12-25T01:24:37Z)
08:24:37.688818 IP (tos 0xc0, ttl 64, id 14942, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 62.84.117.189: ICMP 192.168.64.191 udp port 60798 unreachable, length 84
IP (tos 0x20, ttl 50, id 4932, offset 0, flags [DF], proto UDP (17), length 76)
62.84.117.189.123 > 192.168.64.191.60798: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 3 (8s), precision -25
Root Delay: 0.003372, Root dispersion: 0.000854, Reference-ID: 0xc2bea801
Reference Timestamp: 3944077884.143902239 (2024-12-25T01:11:24Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3944078677.660416851 (2024-12-25T01:24:37Z)
Transmit Timestamp: 3944078677.660432980 (2024-12-25T01:24:37Z)
Originator - Receive Timestamp: 3944078677.660416851 (2024-12-25T01:24:37Z)
Originator - Transmit Timestamp: 3944078677.660432980 (2024-12-25T01:24:37Z)
08:24:37.692423 IP (tos 0x20, ttl 50, id 49186, offset 0, flags [DF], proto UDP (17), length 76)
51.250.35.68.123 > 192.168.64.191.42357: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 3 (8s), precision -25
Root Delay: 0.003265, Root dispersion: 0.001708, Reference-ID: 0xc2bea801
Reference Timestamp: 3944077716.389392936 (2024-12-25T01:08:36Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3944078677.665503793 (2024-12-25T01:24:37Z)
Transmit Timestamp: 3944078677.665526109 (2024-12-25T01:24:37Z)
Originator - Receive Timestamp: 3944078677.665503793 (2024-12-25T01:24:37Z)
Originator - Transmit Timestamp: 3944078677.665526109 (2024-12-25T01:24:37Z)
08:24:37.693588 IP (tos 0xc0, ttl 64, id 42458, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 51.250.35.68: ICMP 192.168.64.191 udp port 42357 unreachable, length 84
IP (tos 0x20, ttl 50, id 49186, offset 0, flags [DF], proto UDP (17), length 76)
51.250.35.68.123 > 192.168.64.191.42357: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 2 (secondary reference), poll 3 (8s), precision -25
Root Delay: 0.003265, Root dispersion: 0.001708, Reference-ID: 0xc2bea801
Reference Timestamp: 3944077716.389392936 (2024-12-25T01:08:36Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3944078677.665503793 (2024-12-25T01:24:37Z)
Transmit Timestamp: 3944078677.665526109 (2024-12-25T01:24:37Z)
Originator - Receive Timestamp: 3944078677.665503793 (2024-12-25T01:24:37Z)
Originator - Transmit Timestamp: 3944078677.665526109 (2024-12-25T01:24:37Z)
08:24:37.695263 IP (tos 0x20, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 76)
92.241.12.152.123 > 192.168.64.191.47442: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 3 (secondary reference), poll 3 (8s), precision -19
Root Delay: 0.012222, Root dispersion: 0.037429, Reference-ID: 0x55154e17
Reference Timestamp: 3944077832.123561299 (2024-12-25T01:10:32Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3944078677.666431533 (2024-12-25T01:24:37Z)
Transmit Timestamp: 3944078677.666788163 (2024-12-25T01:24:37Z)
Originator - Receive Timestamp: 3944078677.666431533 (2024-12-25T01:24:37Z)
Originator - Transmit Timestamp: 3944078677.666788163 (2024-12-25T01:24:37Z)
08:24:37.696348 IP (tos 0xc0, ttl 64, id 20792, offset 0, flags [none], proto ICMP (1), length 104)
192.168.64.191 > 92.241.12.152: ICMP 192.168.64.191 udp port 47442 unreachable, length 84
IP (tos 0x20, ttl 54, id 0, offset 0, flags [DF], proto UDP (17), length 76)
92.241.12.152.123 > 192.168.64.191.47442: [udp sum ok] NTPv4, Server, length 48
Leap indicator: (0), Stratum 3 (secondary reference), poll 3 (8s), precision -19
Root Delay: 0.012222, Root dispersion: 0.037429, Reference-ID: 0x55154e17
Reference Timestamp: 3944077832.123561299 (2024-12-25T01:10:32Z)
Originator Timestamp: 0.000000000
Receive Timestamp: 3944078677.666431533 (2024-12-25T01:24:37Z)
Transmit Timestamp: 3944078677.666788163 (2024-12-25T01:24:37Z)
Originator - Receive Timestamp: 3944078677.666431533 (2024-12-25T01:24:37Z)
Originator - Transmit Timestamp: 3944078677.666788163 (2024-12-25T01:24:37Z)
Это приводит к тому, что около 25 % ответов ntp-серверов сопровождаются сообщениями ICMP port unreachable - не малая прибавка к траффику.
Кроме того, некоторые особо параноидальные провайдеры и их псевдоинтеллектуальные фаерволы расценивают такое поведение станций как атаку извне и начинают резать все ответы ntp-серверов их клиентам, оставляя вообще всех их клиентов без точного времени.
Об инциденте с NTP-серверами