Я не могу синхронизировать часы в Windows 10.
При запросе синхронизации в панели управления или при выполнении этого действия w32tm /resyncмой компьютер отправляет несколько пакетов NTPv3 на pool.ntp.org(я вручную настраиваю этот сервер, но неважно, какой именно сервер я использую) и не получает ответа.
Однако если я w32tm /monitor /computers:pool.ntp.orgэто сделаю, то это сработает, и я смогу увидеть в Wireshark, что мой компьютер отправляет пакеты NTPv1 и получает ответ.
Однако, если я подключаю свой компьютер к мобильной точке доступа моего телефона, синхронизация времени работает с NTPv3. Кроме того, другой компьютер Linux в той же сети, что и мой Windows 10, может синхронизироваться без проблем (и я вижу, что он использует NTPv4).
Я пытался:
- Перезапуск службы времени Windows
- Сброс службы времени Windows
- Открытие порта 123 в брандмауэре маршрутизатора
- Изменение настроек DNS (я использую DNS-over-TLS)
и не заставили его работать.
Мой маршрутизатор использует конфигурацию двойного NAT (т. е. Интернет - Другой маршрутизатор, который я не контролирую - Мой маршрутизатор - Мой ПК), что может вызывать проблемы с NTP, но тогда я не понимаю, как мой ноутбук с Linux может синхронизироваться.
Редактировать 1:
Пакет NTP с ответом
Пакет NTP без ответа
решение1
Как обсуждалось в комментариях,разницазаключается в том, что служба W32time в Windows использует номера портов NTP в «симметричном» режиме, где оба адресатаи источникНомера портов — 123, даже если он ведет себя как обычный клиент и не настроен на работу в качестве симметричного однорангового узла (такая возможность у него есть).
Это означает, что межсетевые экраны без сохранения состояния не имеют возможности отличать входящие ответы от входящих запросов, поскольку и те, и другие поступают «на» порт 123, и если у интернет-провайдера есть фильтр, который не позволяет вам размещать NTP-сервер, он также не позволит вам использовать NTP-клиенты, работающие в этом режиме.
Программное обеспечение Linux NTP обычно придерживается спецификаций протокола и использует эфемерный исходный порт в режиме клиент/сервер, как и большинство других программ UDP (123→123 предназначено исключительно для симметричного режима). Аналогично w32tmработает инструмент, поскольку его опции монитора/полосовой диаграммы заставляют его генерировать собственные запросы NTP, используя обычный сокет, привязанный к эфемерному порту.
Если у вас есть система Linux или BSD, которая всегда подключена к сети, то вы можете использовать ее в качестве внутреннего сервера NTP (требуется совсем немного настроек, чтобы заставить, например, Chrony или ntpd работать в качестве сервера среднего качества).
Это также должно работать для WSL2, поскольку его часы ядра не привязаны строго к часам хоста (насколько я помню) — должна быть возможность запустить Chrony внутри WSL2 в качестве сервера NTP и просто указать ему не пытаться обновлять RTC.
Если у вас есть возможность использовать VPN-соединение для NTP, вы можете использовать VPN-подключение.
Сторонние клиенты Windows NTP также должны работать – особенно если локальный порт 123 уже занят W32time, так как тогда у них в любом случае нет выбора, кроме как использовать другой локальный порт. Например,NetTimeпохоже, это может сработать.
Сторонние клиенты для протоколов, которые не являются NTP, также могут работать, поскольку они не используют тот же порт UDP. Точность не такая хорошая, как у NTP, но может быть достаточно хорошей для ПК. Например, NIST публикует своиnistimeклиент, который может использовать NTP, а также старый протокол RFC-868.