У меня дома широкополосный интернет Airtel (ISP). Этот же интернет-провайдер является и моим провайдером мобильной связи. У меня есть маршрутизатор DIR 615, подключенный к широкополосному интернету Airtel, настольный компьютер и ноутбук с Windows 10.
Когда я подключен к Airtel Broadband, оба компьютера с Windows 10 не могут синхронизировать время с различными NTP-серверами в Интернете. Возвращается Time Out. Я перепробовал более 10–12 NTP-серверов. Однако другие устройства, такие как моя Linux VM, а также маршрутизатор DIR 615, способны правильно синхронизировать время на том же широкополосном соединении с теми же NTP-серверами. Однако, когда я переключаюсь на VPN на Windows 10 и обхожу ISP, компьютер с Windows 10 успешно синхронизирует время с различными NTP-серверами.
Кроме того, когда я использую сторонние приложения, такие как Nistime32bit.exe, они успешно синхронизируют время с серверами NTP на одном ПК с Windows 10 на Airtel Broadband. Я пробовал как на портах TCP 13, так и на портах UDP 123. Теперь, когда я являюсь мобильной точкой доступа Airtel, оба ПК с Windows 10 синхронизируют время правильно, не выдавая никаких ошибок тайм-аута. Трудно поверить, что интернет-провайдер блокирует исходящие порты, поскольку маршрутизатор и виртуальная машина Linux корректно синхронизируются в одной сети и даже сторонние приложения на ПК с Windows 10. Однако ПК с Windows 10 со встроенным процессом Windows 10 выдают ошибку. Трудно поверить, что проблема связана с обеими ОС Windows 10, поскольку они корректно синхронизируются на мобильной точке доступа. Служба W32time работает нормально на обоих ПК.
Я обратился за помощью к интернет-провайдеру, но они не отреагировали.
Кто-нибудь знает, что на самом деле здесь происходит? Что еще я могу попробовать устранить и где может быть проблема? Я проверил Event Viewer, там куча событий, но ничего значимого не найдено.
Брандмауэр полностью отключен как на маршрутизаторе, так и в Windows 10. Тот же результат, если я обойду маршрутизатор и создам прямое PPPoE-подключение от своего ПК к интернет-провайдеру.
Отредактируйте после просмотра комментариев и ответа.
Я пробовал несколько серверов, включая несколько, расположенных в моей стране, но поведение было одинаковым. Широкополосный доступ - сбой, VPN - успех, мобильная точка доступа - успех. Маршрутизатор на широкополосном доступе - успех, Linux VM на широкополосном доступе - успех.
Спасибо @user1686 за подробный ответ. Это было недостающее звено в головоломке.
Все интернет-провайдеры в моей стране работают и ведут себя одинаково. Они все блокируют входящие порты ниже 1024. У меня было впечатление, что для синхронизации NTP это клиент-сервер, но я не знал о симметричном 123 < -- > 123 в Windows, так что даже входящий 123 имеет значение.
Я сейчас проверил, что мой интернет-провайдер действительно блокирует входящий UDP 123, отправляя магические пакеты для удаленного запуска моего ПК. Когда я отправляю его, скажем, на UDP 4000 (маршрутизированный на UDP 9 в маршрутизаторе), через мой мобильный Интернет на широкополосный публичный IP, он просыпается, но на UDP 123 (маршрутизированный на UDP 9) он не работает. Я также использовал небольшую утилиту SimplePort Tester (PCWinTech.com), чтобы перепроверить, что входящий UDP 123 действительно недоступен.
Я попробовал синхронизировать время на своей виртуальной машине Windows XP, предполагая, что она может использовать старый NTPv3, но она даже не смогла синхронизировать время на широкополосном соединении. Так что, похоже, даже XP в те дни использовала 123 < -- > 123.
Я уговорю своего интернет-провайдера открыть входящий UDP 123 хотя бы на некоторое время для тестирования, но шансы, что они вообще рассмотрят мою просьбу, крайне малы!
решение1
Большинство клиентов NTP и SNTP работают в режиме "Клиент/Сервер". Это то же самое, что и другие клиенты UDP — компьютер отправляет запрос NTP с эфемерного порта на порт NTP сервера 123, получает ответ с порта 123 на этот эфемерный порт. Скорее всего, именно так ведет себя ваш клиент Linux NTP.
Однако встроенный в Windows клиент NTP использует «симметричный» режим, в котором он отправляет пакетыиз местного порта 123на порт 123 сервера. Ответы также поступают с удаленного порта 123 на локальный порт 123.
(Такое симметричное использование портов в некоторой степени уникально для NTP и чаще встречается в одноранговых ситуациях, когда два сервера NTP синхронизируются друг с другом. Я не уверен, почему Windows делает это, но это может быть связано с тем, что Windows Server может выступать в качестве настоящего сервера NTP в рамках функциональности AD DC.)
Но проблема с «симметричным» режимом в том, чток сетевому брандмауэру,эти входящие ответы на ваш порт 123 совершенно неотличимы 1 от входящихЗапросык порту 123.
Многие интернет-провайдеры развертывают сетевые брандмауэры для блокировки определенных "рискованных" протоколов, например, тех, которые легко использовать для усиления DDoS, и NTP, к сожалению, один из них. Поэтому в качестве меры предосторожности интернет-провайдер может блокировать все UDP-пакеты, входящие на порт 123 его клиентов, ошибочно полагая, что это только мешает клиентам запускать сервер NTP.
В качестве альтернативы, интернет-провайдер может делать это, предполагая, что у всех клиентов есть персональные маршрутизаторы с NAT, и многие маршрутизаторы фактически переназначают локальный порт исходящих пакетов – так что даже если компьютер отправляет пакет 123→123, маршрутизатор может перевести его в 61473→123, и проблема не возникнет. Однако не все маршрутизаторы делают такое переназначение (этот тип NAT часто в конечном итоге мешает играм).
Предложения:
Если ваш маршрутизатор позволяет выбирать между «Конусным NAT» и «Симметричным NAT», попробуйте переключиться на последний и посмотрите, поможет ли это (и нет, этот термин на самом деле вообще не имеет ничего общего с симметричным NTP).
В противном случае вам, возможно, придется продолжать использовать сторонние NTP-клиенты, которые работают в режиме клиента и не имеют этой проблемы.
Есть МайкрософтСтатья базы знанийоб указании того, какой режим использовать, но хотя это влияет на биты режима в заголовке NTP, это ненетна самом деле заставляют Windows использовать другой исходный порт. К сожалению.
(NTPv3 указал, что исходный порт долженнет(В клиентском режиме это может быть 123, но NTPv4 больше не запрещает этого, поэтому, возможно, Windows успешно использует 123→123 независимо от того, какие флаги режима указаны в заголовке NTP.)
1 Межсетевой экран с отслеживанием состояния, такой как на вашем домашнем маршрутизаторе,можетотличать запросы от ответов, отслеживая ранее увиденные исходящие пакеты. Но хотя межсетевые экраны с отслеживанием состояния обычны на небольших сетевых границах, я подозреваю, что их нелегко масштабировать до уровня «всего провайдера», поскольку просмотр состояния для каждого пакета означает снижение производительности. Поэтому если провайдер управляетбез гражданствабрандмауэр, утверждение по-прежнему верно – два вида пакетов NTP становятся неразличимыми в симметричном режиме.