Всегда удивляло, зачем люди используют термины, значение которых не до конца понимают, например, "покрылись коррозией". Коррозия - это процесс, а покрыться они могли продуктами коррозии. В некоторых случаях могут ничем не покрываться, но корродировать
Что снесёт крышу демону и увеличит время синхронизации в итоге. А некоторым версиям systemd-timesycd в некоторых ситуациях такое действие сносило крышу так, что они, фактически, устривали DoS атаку на ntp-серверы.
Прошло уже больше месяца, так что возникает вопрос о прогресе по этим пунктам:
Поэтому мы запланировали выделить ресурсы в общий пул NTP‑серверов. Это займёт некоторое время, потому что наши дата‑центры удалены от основных точек обмена трафиком, а для NTP‑серверов RTT (Round Trip Time) это — ключевой фактор качества. Мы установим и запустим мощности на основных точках обмена трафиком.
Для наших устройств мы заведём именную зону в соответствии с гайдлайнами проекта NTPPool.org для бо́льшей прозрачности. Генерируемый ими трафик будет локализован на наших NTP‑серверах, если мы продолжим полагаться на публичную инфраструктуру проекта.
Или, это были пустые обещания, Яндекс? Кстати, RTT не является ключевым фактором качества, ключевым фактором является симметрия время пути "туда" и времени "пути" обратно, но для задачи синхронизации двух колонок между собой и это излишне.
Что точно не поменялось, так это потребительское отношение к чужим ресурсам при сетевом обмене с ntp-серверами - свинью за стол, она и лапы на стол. Во время каждого сеанса синхронизации времени станция выплевывает пачку запросов, получив первый ответ, закрывает сокеты. Когда приходят другие ответы, в сторону ntp-серверов летит ICMP port unreachable. То есть, станции не только нагружают каналы ntp-серверов ненужными запросами, но ещё и ICMP-пакетами. Пример сетевого обмена:
Это приводит к тому, что около 25 % ответов ntp-серверов сопровождаются сообщениями ICMP port unreachable - не малая прибавка к траффику.
Кроме того, некоторые особо параноидальные провайдеры и их псевдоинтеллектуальные фаерволы расценивают такое поведение станций как атаку извне и начинают резать все ответы ntp-серверов их клиентам, оставляя вообще всех их клиентов без точного времени.
Ещё помониторили трафик с Яндекс-станции. Стойкое ощущение, что она выплёвывает пачку запросов, как только набирает нужное ей количество ответов, закрывает сокеты, в итоге оставшиеся ответы "бьются в закрытую дверь", вызывая ICMP port unreachable.
Суда по анализу трафика на моём NTP-сервере, обилие ICMP не только от точек доступа. Соотношение ICMP/NTP-ответов растёт днём - вряд ли кто-то станции ночью выключает. Плюс, ICMP иногда прилетают с адресов CGNAT провайдеров - вряд ли кто-то точки там размещает. Таким образом, выглядит это как определённое рукожопие от провайдеров и администраторов конторских сетей - где-то псевдоинтеллектуальный фаервол воспринял это как атаку и начал резать ответы, вместо запросов, где-то администраторы такое же придумали в ручном режиме, где-то могли подрезать размеры таблиц statefull nat для NTP, чтобы NTP их не выжирал, и клиенты хоть как-то жили.
А можно поподробнее, где там написано, почему они не воспринимают ответ на запрос, и не просто игнорируют ответ, а еще и оправляют в ответ ICMP port unreachable? Если что, это происходит уже на свежей прошивке, с увеличенным до 600 секунд периодом запроса.
Хотелось бы получить комментарии от Яндекс, почему их станция опрашивает ntp-сервера, а когда к ней от них приходит ответ, она плюёт в них ICMP Unreachable?
Тут есть ещё нюанс. В попытках борьбы с этим DDoS часть альтернативно одарённых администраторов вместо того чтобы резать исходящие запросы, начала резать входящие ответы от ntp-серверов. В результате чего, вполне нормальные ntp-клиенты мечутся по всему пулу, пытаясь узнать точное время. Ntp-серверы время им отдают, но до клиентов это время не доходит, например, около 48% ответов моего сервера реджектятся с icmp unreachable. Сколько просто дропается, мне неизвестно.
Было бы справедливо, если бы после этого Yandex взял на себя разборки с такими провайдерами. Думаю, Yandex'у будет проще преодолевать первые линии поддержки провайдеров, чем конечным пользователям. А технический инструмент для выявления таких ситуаций Yandex практически есть - это их собственный ботнет.
отчего так много icmp port unreachable? Я писал в теме на ntppool что 25% трафика приходящего на мой сервер это icmp
Сейчас наблюдаю у себя, что 47% ответов моего ntp-сервера приводят к icmp port unreachable. На спуфинг не особо похоже, вряд ли спуферы стали бы с такой дотошностью имитировать поведение клиента. Так что, скорее "ковровые блокировки ntp-протокола". Когда станции DDoSили, могли на скорую руку, например, наконфигурировать statefull NAT таким образом, что сейчас он просто не знает куда кидать ответ и кидает его кому попало, а тот честно говорит - это не мое (icmp port unreachable)
Ну, так советы типа nf_conntrack_udp_timeout_stream=0 встречаются в этих ваших интернетах с 2016 года. Особенно, в контексте "пытаюсь завернуть исходящий udp трафик на самого себя".
Подтверждаю странное обилие icmp port unreachable, но сомневаюсь в DDoS, скорее уж, очередное рукожопие.
Отловил с десяток icmp port unreachable и посмотрел, что происходит. На первый взгляд, вполне нормальные ntp-клиенты с вполне нормальными интервалами между запросами, которые почем-то не принимают ответ.
Выглядит так, будто они забыли, что слали запрос и его надо бы принять.
Не удивлюсь, если начитались соседней ветки и не вникая в суть, навтыкали где попало notrack или же conntrack_udp_timeout в 0 поставили.
Другой вариант, что за NAT кто-то одновременно долбится куда-то, переполняя statefull nat, так что потом пакет с ответом либо неизвестно кому слать, либо шлёт не тому, кто спрашивал.
Это нормально. man ntpdate, man adjtime до просветления. Вкратце, ntpdate увидел небольшое расхождение и пытается "плавно" свести его на нет. Этот процесс вы и наблюдаете
Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
Подобные обращения мы получали и раньше, но причиной всегда были сетевые ограничения на стороне пользователя (например, работодатель мог ограничивать запросы со стороны колонки в корпоративной сети)
То есть, о тенденции ухудшать ситуацию в сети в случае проблем дополнительной нагрузкой, Яндексу было давно известно.
На первом фото с эргономикой полный П. На втором полуполный. Вангую, что этим держателем никто пользоваться не будет.
Всегда удивляло, зачем люди используют термины, значение которых не до конца понимают, например, "покрылись коррозией". Коррозия - это процесс, а покрыться они могли продуктами коррозии. В некоторых случаях могут ничем не покрываться, но корродировать
Что снесёт крышу демону и увеличит время синхронизации в итоге. А некоторым версиям systemd-timesycd в некоторых ситуациях такое действие сносило крышу так, что они, фактически, устривали DoS атаку на ntp-серверы.
DISM - сторонний инструмент?
Прошло уже больше месяца, так что возникает вопрос о прогресе по этим пунктам:
Или, это были пустые обещания, Яндекс? Кстати, RTT не является ключевым фактором качества, ключевым фактором является симметрия время пути "туда" и времени "пути" обратно, но для задачи синхронизации двух колонок между собой и это излишне.
Что точно не поменялось, так это потребительское отношение к чужим ресурсам при сетевом обмене с ntp-серверами - свинью за стол, она и лапы на стол. Во время каждого сеанса синхронизации времени станция выплевывает пачку запросов, получив первый ответ, закрывает сокеты. Когда приходят другие ответы, в сторону ntp-серверов летит ICMP port unreachable. То есть, станции не только нагружают каналы ntp-серверов ненужными запросами, но ещё и ICMP-пакетами. Пример сетевого обмена:
Скрытый текст
Это приводит к тому, что около 25 % ответов ntp-серверов сопровождаются сообщениями ICMP port unreachable - не малая прибавка к траффику.
Кроме того, некоторые особо параноидальные провайдеры и их псевдоинтеллектуальные фаерволы расценивают такое поведение станций как атаку извне и начинают резать все ответы ntp-серверов их клиентам, оставляя вообще всех их клиентов без точного времени.
Количество серверов теперь радует глаз. Но, мне кажется, что зоне ru.pool.ntp.org не хватает серверов мониторинга.
Ещё помониторили трафик с Яндекс-станции. Стойкое ощущение, что она выплёвывает пачку запросов, как только набирает нужное ей количество ответов, закрывает сокеты, в итоге оставшиеся ответы "бьются в закрытую дверь", вызывая ICMP port unreachable.
Я имел ввиду, что в ряде случаев транзитный хост с серым IP генерирует ICMP сообщения.
Уверенность есть. Судя по трафику от станции, RFC дальше формата пакета они вообще не читали. Под катом более детальный лог:
Скрытый текст
Суда по анализу трафика на моём NTP-сервере, обилие ICMP не только от точек доступа. Соотношение ICMP/NTP-ответов растёт днём - вряд ли кто-то станции ночью выключает. Плюс, ICMP иногда прилетают с адресов CGNAT провайдеров - вряд ли кто-то точки там размещает. Таким образом, выглядит это как определённое рукожопие от провайдеров и администраторов конторских сетей - где-то псевдоинтеллектуальный фаервол воспринял это как атаку и начал резать ответы, вместо запросов, где-то администраторы такое же придумали в ручном режиме, где-то могли подрезать размеры таблиц statefull nat для NTP, чтобы NTP их не выжирал, и клиенты хоть как-то жили.
Так вот и спрашиваю "там", так как ваша ссылка именно сюда и ведёт:
А можно поподробнее, где там написано, почему они не воспринимают ответ на запрос, и не просто игнорируют ответ, а еще и оправляют в ответ ICMP port unreachable? Если что, это происходит уже на свежей прошивке, с увеличенным до 600 секунд периодом запроса.
Хотелось бы получить комментарии от Яндекс, почему их станция опрашивает ntp-сервера, а когда к ней от них приходит ответ, она плюёт в них ICMP Unreachable?
Лог под спойлером:
Скрытый текст
Тут есть ещё нюанс. В попытках борьбы с этим DDoS часть альтернативно одарённых администраторов вместо того чтобы резать исходящие запросы, начала резать входящие ответы от ntp-серверов. В результате чего, вполне нормальные ntp-клиенты мечутся по всему пулу, пытаясь узнать точное время. Ntp-серверы время им отдают, но до клиентов это время не доходит, например, около 48% ответов моего сервера реджектятся с icmp unreachable. Сколько просто дропается, мне неизвестно.
Было бы справедливо, если бы после этого Yandex взял на себя разборки с такими провайдерами. Думаю, Yandex'у будет проще преодолевать первые линии поддержки провайдеров, чем конечным пользователям. А технический инструмент для выявления таких ситуаций Yandex практически есть - это их собственный ботнет.
Сейчас наблюдаю у себя, что 47% ответов моего ntp-сервера приводят к icmp port unreachable. На спуфинг не особо похоже, вряд ли спуферы стали бы с такой дотошностью имитировать поведение клиента. Так что, скорее "ковровые блокировки ntp-протокола". Когда станции DDoSили, могли на скорую руку, например, наконфигурировать statefull NAT таким образом, что сейчас он просто не знает куда кидать ответ и кидает его кому попало, а тот честно говорит - это не мое (icmp port unreachable)
Ну, так советы типа nf_conntrack_udp_timeout_stream=0 встречаются в этих ваших интернетах с 2016 года. Особенно, в контексте "пытаюсь завернуть исходящий udp трафик на самого себя".
Ну, да, очень оперативно. Больше месяца ru.pool.ntp.org лежал под DDoS.
Подтверждаю странное обилие icmp port unreachable, но сомневаюсь в DDoS, скорее уж, очередное рукожопие.
Отловил с десяток icmp port unreachable и посмотрел, что происходит. На первый взгляд, вполне нормальные ntp-клиенты с вполне нормальными интервалами между запросами, которые почем-то не принимают ответ.
Выглядит так, будто они забыли, что слали запрос и его надо бы принять.
Не удивлюсь, если начитались соседней ветки и не вникая в суть, навтыкали где попало notrack или же conntrack_udp_timeout в 0 поставили.
Другой вариант, что за NAT кто-то одновременно долбится куда-то, переполняя statefull nat, так что потом пакет с ответом либо неизвестно кому слать, либо шлёт не тому, кто спрашивал.
Это нормально. man ntpdate, man adjtime до просветления.
Вкратце, ntpdate увидел небольшое расхождение и пытается "плавно" свести его на нет. Этот процесс вы и наблюдаете
Не нужен, достаточно разумного протокола (немного модифицированного SNTP), по которому эти две станции обменяются сообщениями о событии и вычислят текущее расхождение часов между ними.
То есть, о тенденции ухудшать ситуацию в сети в случае проблем дополнительной нагрузкой, Яндексу было давно известно.