Проблема не в использовании какого-либо типа эталонной реализации (например, stratum 0/1). Это не то, о чем просят, и в этом нет необходимости. NTP имеет многоуровневую структуру. Функциональность (которая уже обсуждалась) заключается в том, чтобы шлюз предоставлял NTP для локальной сети, одновременно синхронизируясь с вышестоящими NTP-серверами. Так работают все остальные решения для шлюзов. Обоснование этому уже было предоставлено несколькими людьми в нескольких тредах. Нет необходимости, чтобы шлюз был NTP-сервером stratum-1 со своим собственным эталонным clock. Речь идет лишь о том, чтобы ntpd можно было настраивать, как это было на USG, что аналогично тому, как это делают все остальные (включая edgerouters). Если вам нужен собственный stratum-1 со своим эталонным clock, у вас уже есть (или должно быть) выделенное устройство. Тем не менее, не рекомендуется, чтобы этот stratum-1 напрямую предоставлял время клиентам: для этого следует использовать NTP-серверы stratum-2, и именно здесь служба NTP-сервера на UniFi gateway может быть полезна (в качестве этого stratum-2). Никто не говорит, что вам нельзя предоставить свой собственный, и для тех, кому это действительно необходимо, это уже реализовано. Запрос заключается в том, чтобы избежать необходимости в этом для сред, где такая потребность уже отсутствует.

Может, это прозвучало как ерунда, но я действительно имел в виду это. Согласен, у большинства сторонних роутеров есть NTP Server Service. Хотя обычно у них нет электроники, способной самостоятельно поддерживать синхронизацию, и они обращаются в интернет, чтобы убедиться, что время остается синхронизированным. Это было бы невозможно, учитывая комментарий о запрете подключения устройств к внешнему миру. Так что в этом случае вам нужно будет создать свой собственный сервер-эталон локально, что, как сказал @kanewolf, относительно просто на Pi.

@GeorgeCZzz Ничто не мешает тебе собрать собственный NTP-сервер и использовать его как источник для всех NTP-клиентов в твоей сети.

У меня уже давно USG, а когда они перевели URL-адреса обновлений с http на https, я вообще не знал, что это NTP-сервер, не говорю, что это не так, просто не помню, да и всегда выбирал свой собственный NTP-сервер. Настройки, которые я упоминал выше, и их вариации в предыдущих версиях UNA всегда указывали Unifi устройствам, где находится NTP-сервер. Изначально он вообще не был настроен, и AP и другие устройства просто работали свободно (и тогда это не было проблемой). Это привело к сбоям в обновлениях людей во время перехода с http на https для URL-адреса обновления (кажется, это было где-то с версии 3 на 4 UNA), потому что правильное время было частью установления безопасного соединения с удаленным HTTPS-сервером. Поэтому вам нужно установить, как указано выше, чтобы направить Unifi устройства к NTP-серверу на ваш выбор, если автоматическая опция не работает. Клиенты, подключающиеся, также могут быть направлены к NTP-серверу на ваш выбор, если вы используете UX в качестве DHCP-сервера: Настройки -> Сети -> Ваша сеть -> Управление службой DHCP -> NTP-сервер (Выберите и укажите IP-адрес NTP-сервера на ваш выбор).

@FrankNicklin, эта настройка настраивает NTP-клиент для устройств UniFi, и это то же самое, что отметил @nuttersrest выше. Она не настраивает UniFi Gateway в качестве NTP-сервера. Из обсуждения, на которое я дал ссылку выше, UI подтвердили, что NTP-сервер был удалён из UDM (первый шлюз после USG), и, как многие обнаружили, он так и не вернулся. Для тех, кто использовал USG в качестве NTP-сервера для всей своей инфраструктуры, потребуется альтернативный метод при переходе на более новый UniFi Gateway.

Функциональность NTP-сервера была удалена в шлюзах после USG в пользовательском интерфейсе. Объяснений не предоставили, хотя это была очень востребованная функция, которую хотели вернуть. К сожалению, при переходе с USG, если вы использовали его для NTP-сервисов, вам придется искать альтернативное решение. Это одна из тем, но запросы на добавление NTP-сервера можно найти во многих других: PSA: UDM не будет выступать в качестве NTP-сервера.